A Zenity Labs (abre em nova aba) descreveu um cenário que cabe em uma frase e deveria incomodar quem opera agentes em produção por um bom tempo: um único agente de IA exposto publicamente no Amazon Bedrock AgentCore (abre em nova aba) era suficiente para sequestrar todos os agentes AgentCore da mesma conta AWS, na mesma região. Um prompt. Todos os agentes. A AWS corrigiu a falha e endureceu de forma significativa as permissões padrão atribuídas aos agentes, segundo o relato dos pesquisadores, que teve cobertura do The Decoder.
O que o AgentCore expõe, além do agente
Bedrock AgentCore é a camada gerenciada da AWS para executar agentes de IA, isto é, aplicações que combinam um modelo de linguagem com ferramentas, memória e capacidade de agir sobre recursos da nuvem. Agir exige identidade. No modelo da AWS, cada workload recebe credenciais temporárias, tokens de sessão de vida curta emitidos sob uma execution role, o papel do IAM que define o que aquele agente pode tocar. Essas credenciais são entregues por interfaces internas da AWS, desenhadas para serem alcançadas apenas pelo próprio workload.
Segundo a Zenity, a falha estava justamente aí. Os agentes conseguiam acessar uma interface interna de credenciais temporárias sem restrição nenhuma, e o que esse acesso permitia ia muito além do agente original: o comprometimento se estendia horizontalmente, alcançando todos os agentes AgentCore da mesma conta e região. O prompt era o veículo. A credencial, o alvo.
A divulgação pública não detalha qual endpoint exato estava envolvido, nem como o token saía do ambiente do agente de volta para o atacante. É tentador supor que se trate de algo análogo ao serviço de metadados de instância, cujo abuso tem história longa em nuvens públicas, com ataques de SSRF, a falsificação de requisições que fazem um servidor interno consultar endereços que deveria recusar. As informações disponíveis não permitem afirmar isso. O que está confirmado pela pesquisa é a combinação de dois fatos: uma interface interna de credenciais acessível sem restrição e um alcance que atravessava a conta.
Por que isso é mais grave que um prompt injection comum
Três propriedades separam esse caso de um prompt injection banal, aquele em que um texto malicioso induz o modelo a produzir conteúdo indesejado.
- O alvo não era a resposta do agente, e sim as credenciais que ele carregava para funcionar.
- O dano não ficava confinado ao agente atacado; ele contaminava todos os vizinhos de conta e região.
- Tudo indica que não exigia configuração exótica. A própria correção das permissões padrão pela AWS sugere que o comportamento permissivo era o estado de fábrica do serviço, não um desvio introduzido pelo cliente.
O terceiro ponto é o que mais incomoda. Prompt injection é um risco conhecido e, em geral, tratado como problema de conteúdo: o agente pode ser induzido a dizer bobagens ou revelar dados do contexto. Quando o modelo tem acesso a interfaces de identidade, a classe do problema muda. Deixa de ser manipulação discursiva e passa a ser escalada de privilégio, com as credenciais fazendo o papel que, em ataques tradicionais, caberia a um exploit de memória.
Há um nome consolidado para esse padrão na literatura de segurança: confused deputy, o delegado confuso. Um componente com privilégios elevados é induzido, por uma entrada de baixa confiança, a usar esses privilégios em benefício de terceiro. O agente de IA é, nesse quadro, um delegado que fala naturalmente com qualquer pessoa e carrega chaves de identidade. O ataque da Zenity não inventou essa categoria; apenas mostrou que ela também funciona em runtime gerenciado de nuvem.
O que a AWS corrigiu, e o que segue sem resposta
De acordo com os pesquisadores, a AWS aplicou correção na plataforma e endureceu as permissões padrão dos agentes. O alcance exato dessas mudanças, e a data precisa da correção, não constam das informações públicas usadas nesta análise. O mesmo vale para reconhecimento: nada indica recompensa ou créditos formais no programa de bug bounty da AWS, e a ausência de menção não permite concluir nem que houve, nem que não houve. Ceticismo aqui não é luxo; é o único estado epistêmico honesto diante do que foi divulgado.
O padrão se repetiu no SDK do mesmo produto
A falha relatada pela Zenity não é o único problema de credenciais já registrado no AgentCore. Pesquisa da BeyondTrust, reportada pela Infosecurity Magazine e repercutida pelo MSSP Alert em 6 de outubro de 2026, documentou duas vulnerabilidades críticas no SDK Python do serviço, rastreadas como CVE-2026-12530 e CVE-2026-16796, ambas no Code Interpreter helper, o componente usado para instalação de pacotes dentro do sandbox do agente.
| Pesquisa | Componente afetado | Vetor do ataque | Correção |
|---|---|---|---|
| Zenity Labs | Interface interna de credenciais temporárias | Prompt dirigido a um agente público | Correção na plataforma e permissões padrão endurecidas |
| BeyondTrust | SDK Python, Code Interpreter helper | Nomes de pacote maliciosos (CVE-2026-12530 e CVE-2026-16796) | Versões 1.6.1 e 1.18.1 do SDK |
A mecânica vale atenção. Na primeira falha, um nome de pacote construído com cuidado burlava a validação, que era feita por lista de bloqueio incompleta, e permitia executar comandos dentro do sandbox e ler credenciais temporárias. A AWS corrigiu na versão 1.6.1. A segunda apareceu logo depois: a sintaxe de extras do pip, aquela usada para instalar dependências opcionais de um pacote, contornou a validação atualizada. Correção na 1.18.1. A AWS atribuiu severidade entre 7.3 e 8.4 no CVSS, e o impacto real, como a própria cobertura observa, dependia das permissões concedidas à execution role afetada.
A recorrência é o dado estrutural. Uma validação por lista de bloqueio que, na prática, não bloqueava quase nada, em um produto cujo agente carrega credenciais e processa entrada hostil por definição. Duas pesquisas independentes, dois vetores distintos, um mesmo substrato: identidade privilegiada exposta a conteúdo não confiável.
O que fica para quem opera agentes
As lições são menos sobre o AgentCore e mais sobre a arquitetura de agentes em geral. A própria BeyondTrust recomenda limitar as permissões da execution role e monitorar a atividade do Code Interpreter, e as recomendações se aplicam a qualquer plataforma equivalente.
- Princípio do menor privilégio, aplicado ao agente. A execution role deve permitir apenas o que o agente precisa para sua função específica, nunca o que a conta permitiria. O impacto das duas falhas do SDK variou conforme essa escolha, e isso não é coincidência.
- Entrada de usuário como dado hostil. Um agente público aceita prompts de qualquer origem. Tratar essa entrada como confiável é uma decisão de projeto, não um pressuposto seguro.
- Preferir listas de permissão a listas de bloqueio. O caso do SDK mostra a validação por bloqueio falhando duas vezes, de formas diferentes, em intervalo curto.
- Monitorar o uso de identidade, não só o conteúdo. Consultas a interfaces de credenciais vindas de contexto de execução de agente são sinal de alerta por si mesmas.
Há também uma implicação de plataforma que merece registro. O cliente pode endurecer permissões, monitorar e filtrar, mas não controla as interfaces internas que o runtime gerenciado disponibiliza ao agente. Quando a falha está na camada do provedor, o modelo de responsabilidade compartilhada empurra para o cliente um risco que ele não consegue auditar diretamente. A correção da AWS atenuou o caso específico; a assimetria de visibilidade permanece.
A superfície de ataque de um agente nunca foi o modelo de linguagem. Sempre foi a identidade que alguém achou razoável entregar a ele.