Ordem de execução para quem tem agente em produção na AWS:
- Listar todo agente do AgentCore exposto à internet e verificar se ele tem ferramenta capaz de fazer requisição de saída. É a única pré-condição do ataque. Sem essa ferramenta, o prompt não chega ao serviço de metadados.
- Conferir se o agente usa o papel de execução padrão do serviço ou um papel próprio com escopo restrito ao que aquele agente precisa. O papel padrão era o amplificador, e foi reduzido pela AWS em 29 de setembro de 2026. Implantação anterior a essa data precisa ser verificada uma por uma.
- Confirmar que o IMDSv2 está exigido, e não apenas disponível. A AWS passou a usá-lo como padrão em 14 de fevereiro de 2026, para novas implantações. Nada indica migração automática do que já estava no ar.
- Auditar a memória de longo prazo dos agentes. É a parte da cadeia sem correção anunciada, e é a única que sobrevive ao encerramento da sessão: instrução plantada ali volta a valer na conversa seguinte, sem nova interação do atacante.
- Rotacionar segredo que esteve alcançável pelo papel padrão nessa janela, incluindo chave de API e token de OAuth de serviço de terceiro. Reduzir a permissão agora não invalida credencial que já saiu.
Não existe CVE atribuída e não há relato público de exploração. Isso significa que a verificação não vai cair na sua fila por boletim de fornecedor nem por scanner.
A cadeia, em quatro passos
O primeiro passo é o mais barato. O agente do AgentCore exposto à internet recebe um prompt pedindo que faça uma requisição ao endereço 169.254.169.254, o serviço de metadados da instância. O agente tem uma ferramenta de requisição de saída habilitada, porque quase todo agente útil tem, e a infraestrutura do AgentCore não barrava o caminho até aquele endereço. O resultado devolvido ao atacante são as credenciais temporárias do papel de execução da máquina que roda o agente. Em termos clássicos, é falsificação de requisição no lado do servidor, com o prompt no lugar do parâmetro de URL.
O segundo passo é onde a falha deixa de ser pontual. As credenciais obtidas pertenciam ao papel de execução padrão do serviço, e o escopo dele não terminava no agente que as usou: alcançava todos os agentes do AgentCore daquela conta naquela região. Um agente de atendimento público passou a ser porta de entrada para o inventário inteiro de agentes da organização, inclusive os internos.
O terceiro passo é movimentação lateral com API interna e fraqueza de enumeração. Com o papel em mão, os pesquisadores descobriram e invocaram agentes que não tinham autorização para acessar, leram conversas privadas e memórias de longo prazo de outros usuários e de outras sessões, baixaram as imagens de contêiner dos agentes para recuperar código-fonte e recolheram chaves de API, tokens de OAuth e outras credenciais a partir do Secrets Manager e de variáveis de ambiente, incluindo credenciais de serviços corporativos e de terceiros.
O quarto passo é o que transforma um incidente em presença permanente: plantar memória. A instrução gravada na memória de longo prazo do agente altera o comportamento dele nas interações seguintes e passa a enviar conversas futuras para destino sob controle do atacante. O usuário continua conversando com o que parece ser o agente confiável da empresa.
O papel padrão é o problema, não o prompt
Vale separar as duas coisas, porque elas pedem respostas diferentes. A injeção de prompt é a porta. O papel de execução excessivamente amplo é o tamanho do prédio atrás da porta.
Nenhuma defesa de prompt resolve o segundo problema. Filtro de entrada, instrução de sistema mais rígida e classificador de conteúdo reduzem a probabilidade de alguém conseguir fazer o agente emitir aquela requisição. Não alteram em nada o fato de que, se o agente emitir, a credencial devolvida vale para a conta e a região inteiras. O inverso também vale: com papel restrito ao que aquele agente específico precisa, o mesmo prompt bem-sucedido devolve uma credencial que não serve para quase nada.
É a mesma lição que o setor já aprendeu com conta de serviço em Kubernetes e com perfil de instância em EC2, aplicada a um serviço novo. A diferença desconfortável é que a identidade do agente é consumida por um componente que aceita instrução de desconhecido como entrada legítima de operação. Em qualquer outro contexto, isso se chama entrada não confiável e não se dá credencial a ela.
A resposta da AWS, e a janela de nove meses
A divulgação à AWS foi em 25 de dezembro de 2025. A resposta inicial foi classificar o comportamento como documentado e esperado, com o argumento de que um agente pode alcançar as credenciais do seu próprio papel de execução pelo serviço de metadados. A cobertura da imprensa especializada em 9 de outubro questionou se esse enquadramento cobria o cenário descrito, e a objeção é razoável: o que a pesquisa demonstrou não foi um agente alcançando a própria credencial, foi um agente alcançando a credencial que governa todos os outros.
As mudanças vieram em duas datas. Em 14 de fevereiro de 2026 o IMDSv2 passou a ser o padrão para novas implantações do AgentCore. Em 29 de setembro de 2026 as permissões do papel de execução padrão foram reduzidas de forma significativa, com a retirada da invocação cruzada entre agentes, da leitura de conversa e do acesso ao Secrets Manager. A Zenity confirmou em teste a redução e registrou a colaboração da AWS.
Duas observações sobre o que esse calendário deixa em aberto. A primeira é a janela: nove meses entre o relato e a redução final do papel. Todo agente implantado nesse intervalo nasceu com o papel amplo, e nada indica que implantações existentes tenham sido migradas automaticamente para o IMDSv2 nem reavaliadas. A segunda é o escopo da correção: a permissão de baixar imagem de contêiner do registro não aparece entre as retiradas, e não há correção anunciada para o envenenamento de memória pela criação de evento na memória do AgentCore, que é justamente a parte persistente da cadeia.
Nenhuma CVE, nenhum boletim, nenhuma fila
Não foi atribuída CVE e não há relato público de exploração em ambiente real. Isso tem uma consequência operacional que merece atenção de quem gerencia vulnerabilidade por processo: esse achado não vai aparecer em scanner, não vai gerar item em painel de conformidade e não vai entrar na fila de correção por boletim de fornecedor.
A classe inteira tende a se comportar assim. Falha de configuração padrão em serviço gerenciado de nuvem raramente recebe identificador, porque o provedor corrige do lado dele e o cliente não aplica atualização nenhuma. O problema é que a correção do provedor vale para o que será criado, e o passivo do cliente é o que já está rodando. Quem depende de CVE para saber o que verificar não tem como descobrir isso.
O recorte regional
A adoção de agente em produção na América Latina não é experimental. As pesquisas de setembro e outubro citadas nesta semana colocam a grande maioria das organizações com agente de IA já em operação e uma fração de um dígito com ferramenta de identidade feita para governá-los. Esse é exatamente o perfil que o AgentCorruption explora: agente no ar, papel de execução no padrão, ninguém com inventário.
Há um agravante local de contrato. Boa parte das implantações de agente no Brasil foi feita por integrador ou por consultoria, dentro da conta do cliente, com o papel que o tutorial do fornecedor sugere. Nesses casos o cliente não escolheu o papel padrão: ele herdou. E não tem no contrato a obrigação de o integrador revisar escopo de permissão quando o provedor muda o padrão, que é precisamente o que aconteceu em 29 de setembro.
A pergunta para esta semana é curta e não precisa de ferramenta nova para ser respondida: quantos agentes a organização tem expostos à internet, qual papel cada um assume e quem revisou esse papel depois de setembro. Em muitas empresas, as três respostas vão demorar mais que a correção.
Outros sinais do radar
- Persistência
A memória do agente é o único ponto da cadeia sem correção anunciada
O envenenamento de memória pela criação de evento na memória do AgentCore não aparece entre as correções descritas, e é a parte da cadeia que sobrevive ao fim da sessão. Instrução plantada ali altera o comportamento do agente nas conversas seguintes e pode desviar o conteúdo delas, sem nova ação do atacante. Para quem opera, isso muda o que significa conter o incidente: encerrar sessão, rotacionar credencial e reduzir permissão não remove o que está gravado na memória de longo prazo. É preciso inspecionar e limpar esse conteúdo, e hoje quase ninguém tem procedimento para isso.
- Imagem
A permissão de baixar imagem de contêiner não está entre as retiradas
A redução do papel de execução padrão em 29 de setembro retirou invocação cruzada de agentes, leitura de conversa e acesso ao Secrets Manager. A permissão de puxar imagem do registro de contêiner não aparece na lista. Como a imagem do agente carrega o código, isso mantém em pé o caminho de extração de propriedade intelectual e de descoberta de segredo embutido em camada de imagem, que é um achado clássico e independente de agente. Vale conferir o que vai dentro da imagem antes de considerar o assunto encerrado.
- IMDS
Padrão novo vale para implantação nova, e o passivo é o que já estava no ar
O IMDSv2 passou a ser padrão em 14 de fevereiro de 2026 para novas implantações do AgentCore. Não há indicação de migração automática do que já existia. É o mesmo padrão de dívida que o setor conhece de EC2: a versão 2 do serviço de metadados exige token obtido por requisição PUT, o que quebra a falsificação de requisição simples, mas só protege quem a exige. Checar se está disponível não responde nada. A pergunta é se está obrigatória.
- Classe
Falha de padrão em serviço gerenciado não gera CVE, e por isso não entra em fila de correção
Não houve CVE atribuída ao AgentCorruption, e isso não é uma exceção: configuração padrão insegura em serviço gerenciado de nuvem costuma ficar fora do sistema de identificadores, porque o provedor corrige do seu lado e o cliente não aplica atualização alguma. A consequência prática é que o achado não aparece em scanner, em painel de conformidade nem em boletim de fornecedor. Quem só verifica o que tem identificador não tem como saber que precisa verificar isso.
Fontes e aprofundamento
- Zenity · Zenity Labs Discloses AgentCorruption, a Chain of AWS AgentCore Flaws, divulgação original, com a cadeia completa, o alcance do papel padrão e as mudanças confirmadas em teste.
- Forkast · A Single Prompt Compromised Every Agent in the Account. AWS Calls It Expected Behavior, com as datas das correções, a resposta inicial da AWS e o que segue sem correção anunciada.
- The Decoder · A single prompt was enough to hijack every AI agent in an AWS account, Zenity researchers found, com a descrição do alcance regional do acesso obtido.
- Dark Reading · AgentCorruption Puts AWS Environments At Risk With Single Prompt, com a leitura da correção aplicada pela AWS e o risco para o parque de agentes.
- The Next Web · One prompt let researchers take over every AWS AgentCore agent in a region, com o resumo do ataque e do escopo por conta e região.