Um Prompt, Um Agente, uma Conta AWS Inteira: Por Dentro do AgentCorruption no Amazon Bedrock AgentCore

Em 8 de outubro de 2026, Zenity Labs divulgou AgentCorruption: uma cadeia de falhas no Amazon Bedrock AgentCore, a plataforma gerenciada da AWS para implantar e executar agentes de IA, que permitia que um único prompt em linguagem natural para um agente voltado ao público assumisse o controle de todos os agentes do AgentCore na mesma conta e região da AWS. A pesquisa foi publicada junto com uma palestra na SecTor 2026 em Toronto, onde o diretor de pesquisa de segurança da Zenity, Tamir Ishay Sharbat, a apresentou (Dark Reading, 8 de outubro de 2026). O próprio artigo da Zenity, atribuído a Sharbat, Lana Salameh, Dmitry Lozovoy e João Donato, começa com o mecanismo: um agente do AgentCore que tenha qualquer ferramenta capaz de fazer uma solicitação de saída pode ser direcionado a chamar o AWS Instance Metadata Service (IMDS) no endereço link-local 169.254.169.254, que retorna credenciais temporárias para a própria função de execução do agente. A Zenity afirma que exportou essas credenciais para sua própria máquina e confirmou que elas funcionaram a partir dali. Nenhum identificador CVE foi atribuído.

O arquivo registra isto como uma vulnerabilidade — algo encontrado, não necessariamente explorado — com altagravidade, confiança A, nenhum dano real registrado e envolvimento de IA confirmado. As partes discordam quanto ao enquadramento, embora concordem quanto ao comportamento: a AWS disse ao Dark Reading que a pesquisa "retrata de forma imprecisa um comportamento esperado e documentado como uma vulnerabilidade".

O que a corrente realmente era

O AgentCore empacota cada agente como um contêiner e o executa, por sessão, em uma Firecracker MicroVM. O primeiro post da Zenity na série reproduz todo o ponto de apoio com uma solicitação em linguagem simples a um agente de teste criado com Strands SDK, o framework de agentes de código aberto da AWS, que traz uma ferramenta integrada de requisições HTTP e uma ferramenta de shell. A microVM não restringiu o tráfego para o serviço de metadados, então a solicitação partiu de dentro da instância e o IMDS respondeu. Os pesquisadores percorreram os endpoints depois disso: o nome da função IAM, as próprias credenciais temporárias do STS, o endpoint de dados do usuário — que retornou o ID da conta, ARNs completos, a URL de runtime e a Amazon Elastic Container Registry (ECR) URI da imagem do agente — e tags da instância, incluindo uma cadeia de certificados mTLS, uma chave privada e uma URL pré-assinada para o armazenamento interno. A Zenity diz que o mesmo resultado veio pela ferramenta de shell, porque a falha de isolamento está no nível da plataforma, e não em uma ferramenta específica.

Dois detalhes nessa sequência são fáceis de passar despercebidos. As credenciais não estavam confinadas ao sandbox: a Zenity as exportou para fora do AgentCore e executou uma chamada de identidade da AWS que retornou como a role assumida do agente. E a role roubada conseguia baixar a imagem de contêiner, e foi assim que o código-fonte dos agentes se tornou legível — a publicação da Zenity observa que imagens costumam conter chaves codificadas diretamente, tokens deixados para trás e configurações que nunca deveriam ter sido incorporadas, e que uma imagem baixada é um mapa da lógica de negócios subjacente.

O papel padrão é onde um ponto de apoio se tornou uma conta

A segunda falha, relatada separadamente, é que a função de execução que o AgentCore atribuía aos agentes por padrão não estava restrita a um único agente. A Zenity descreve permissões que alcançam todos os recursos do AgentCore na conta e na região, incluindo bedrock-agentcore:InvokeAgentRuntime, bedrock-agentcore:ListEvents, bedrock-agentcore:CreateEvent, bedrock-agentcore:DeleteEvent e, na ponta das credenciais dessa cadeia, bedrock-agentcore:GetResourceApiKey e secretsmanager:GetSecretValue.

A enumerabilidade transformou esses curingas em uma lista de alvos. A Zenity usou alogs:DescribeLogGroups permissão da função, porque o AgentCore nomeia o grupo de logs do CloudWatch de cada agente como /aws/bedrock-agentcore/runtimes/{AGENT_ID}-{ENDPOINT_NAME}, e derivou os IDs dos agentes a partir desses nomes de grupos de logs. Os nomes dos repositórios do ECR seguiam uma convenção observada pelos pesquisadores — bedrock-agentcore-<agent_name> —, então a imagem de cada agente na região podia ser baixada. Os recursos de memória foram encontrados da mesma forma, a partir do padrão de grupo de logs /aws/vendedlogs/bedrock-agentcore/memory/APPLICATION_LOGS/{MEMORY_ID}, e as permissões ListActors, ListSessions e ListEvents da função produziam os identificadores de ator e de sessão necessários para ler o conteúdo das conversas.

A análise da Zenity apresenta uma demonstração concreta de movimento lateral: entrar por meio de um agente voltado ao público, descobrir as ferramentas de um billing_agent na mesma região, localizar um arquivo chamado billing.json e exfiltrá-lo por meio de uma ferramenta de leitura de arquivos. O comunicado à imprensa descreve o mesmo cenário em termos gerais — um atacante que entra por meio de um agente de atendimento ao cliente exposto à internet poderia migrar para um agente financeiro interno implantado na mesma região, invocá-lo e alcançar seus dados, ferramentas, credenciais relacionadas e conversas privadas.

A memória foi a parte que sobreviveu ao prompt.

O AgentCore Memory mantém a própria conversa como memória de curto prazo e armazena registros extraídos como memória de longo prazo, usando estratégias chamadas SEMANTIC, USER_PREFERENCE, SUMMARIZATION e EPISODIC. A Zenity usou CreateEvent para gravar eventos de conversa nos recursos de memória de outros agentes. A publicação dela é cuidadosa quanto ao que essa primitiva pode e não pode fazer: CreateEvent não permite que o chamador escolha um namespace de longo prazo nem substitua um registro diretamente — as estratégias configuradas da memória de destino decidem o que é extraído e onde é armazenado. A Zenity também descreve DeleteEvent sendo usado para remover eventos de resultado de ferramenta para que um agente tire uma conclusão errada a partir de dados ausentes, e para encobrir rastros excluindo o evento que plantou uma memória.

O que a primitiva de escrita produziu foi persistência. A demonstração da Zenity plantou uma solicitação para que o agente buscasse uma página controlada pelos pesquisadores antes de responder, e seguisse o conteúdo dessa página — um endpoint de comando e controle cujas instruções podiam ser alteradas sem plantar outra memória. O mesmo canal então transportava o conteúdo da conversa para fora: o relatório descreve o agente enviando as mensagens do usuário e as suas próprias respostas para um ponto de coleta, e afirma que as permissões de memória da função se estendiam por toda a conta e região, e não apenas ao agente comprometido. Um vídeo publicado com a pesquisa mostra um usuário continuando uma conversa enquanto esse conteúdo chega ao servidor dos pesquisadores.

Credenciais além da AWS

A última publicação da série fecha o ciclo sobre ferramentas conectadas. O AgentCore Identity e o Outbound Auth armazenam credenciais de ferramentas como segredos no AWS Secrets Manager, sob nomes criados a partir de um nome de provedor e um padrão fixo, como bedrock-agentcore-identity!default/apikey/{provider_name}. A Zenity recuperou nomes de provedores ao fazer scraping do código-fonte do agente que já havia baixado do ECR, e recuperou outros por força bruta: ela relata que o sufixo padrão de cinco caracteres é gerado no lado do cliente a partir de dígitos e letras minúsculas, resultando em 2 x (10+26)^5 = 120,932,352 combinações entre os dois tipos de provedor. Na taxa de requisições que conseguia sustentar contra o Secrets Manager, a Zenity afirma que uma enumeração completa leva várias horas — mais tempo do que as credenciais STS duram — então ela criou um loop que consultava novamente o endpoint IMDS do agente para obter credenciais novas conforme as antigas expiravam. A Zenity acrescenta que variáveis de ambiente eram legíveis por meio do endpoint de user-data dos metadados, com todos os nomes prefixados com CONTAINER_ENV_, incluindo a chave que um agente usa para se autenticar em seu provedor de modelo, e que invocar cada agente descoberto com um prompt adequado coletava esses valores em escala.

Estabelecido, e contestado com base em uma tecnicalidade

O que está estabelecido é limitado e específico. Agentes do AgentCore conseguiam alcançar o IMDS e receber as credenciais temporárias de sua própria função de execução — a AWS não contesta isso, descrevendo o caso em sua declaração como "documentado e esperado". A função de execução padrão trazia permissões com escopo na conta e na região, e não em um único agente; a AWS desde então a alterou, e a Zenity diz que seus próprios testes confirmaram a redução. A pesquisa é uma demonstração, não uma campanha observada: Sharbat disse à Dark Reading que a Zenity não tinha evidências de que a falha tenha sido explorada na natureza antes da correção, em parte pela dificuldade de identificar quais organizações executam no AgentCore, e acrescentou que estava "100% certo de que existem maneiras de fazer isso".

O que está em disputa é se alguma parte disso deveria ser chamada de vulnerabilidade. A declaração da AWS, conforme fornecida ao Dark Reading e ao The Next Web, diz: “A AWS tem conhecimento da pesquisa publicada sobre o Amazon Bedrock AgentCore, que descreve de forma imprecisa um comportamento esperado e documentado como uma vulnerabilidade. Um agente só pode acessar recursos em outra conta da AWS se o desenvolvedor conceder explicitamente permissões tanto na função de execução do agente quanto no recurso de destino.” A declaração da AWS reproduzida nas próprias publicações da Zenity mantém a substância da primeira frase — “o comportamento descrito é documentado e esperado” — e acrescenta que os clientes devem conceder às funções de execução apenas as permissões de que seus agentes precisam. Duas coisas estão por trás da discordância. A AWS enquadra a fronteira em termos de acesso a recursos em outra conta da AWS, enquanto a descoberta da Zenity diz respeito a agentes dentro de uma única conta e região da AWS; e as funções descritas pela Zenity vieram dos padrões da plataforma, e não de um cliente escrevendo uma política manualmente.

Vale a pena registrar a correção que o The Next Web fez em sua própria matéria, porque ela mostra a alegação sendo relativizada por alguém que não são os próprios pesquisadores. O veículo publicou inicialmente, e depois corrigiu, uma manchete que dizia que os pesquisadores assumiram o controle de todos os agentes do AgentCore em uma região; a versão corrigida afirma que a pesquisa abrangeu agentes dentro de uma única conta e região da AWS, e observa que a manchete anterior apresentava a alegação dos pesquisadores como fato.

A cronologia da divulgação

A Zenity registrou dois relatórios em vez de um, e eles receberam respostas diferentes. O relatório de acesso ao IMDS foi enviado em 25 de dezembro de 2025; a AWS encerrou-o em 12 de abril de 2026 como "informativo", escrevendo que o AgentCore só havia usado o IMDSv2 desde 14 de fevereiro de 2026, com agentes recém-implantados sendo iniciados dessa forma. Essa revisão é importante para as especificidades desta pesquisa, porque o IMDSv2 exige um token de sessão em cada solicitação e quebra a requisição simples não autenticada que os pesquisadores usaram para obter credenciais. O segundo relatório, sobre a função padrão e seu raio de impacto, foi enviado em 12 de janeiro de 2026. A AWS informou à Zenity em 25 de fevereiro de 2026 que a equipe estava trabalhando nisso enquanto a função permanecia como estava; a Zenity revisou a função novamente em 22 de junho de 2026 e constatou que suas permissões permaneciam inalteradas. Uma revisão final em 29 de setembro de 2026 constatou que a função havia sido substancialmente restringida, e o comunicado à imprensa da Zenity afirma que a remoção abrangeu a invocação de outros agentes, a leitura de conversas privadas e o acesso a segredos no AWS Secrets Manager, com outras permissões também significativamente restringidas. As próprias publicações da Zenity observam que a AWS desde então tornou o IMDSv2 o padrão para implantações do AgentCore e que os dois lados colaboraram ao longo do processo.

O que não se sabe

A Zenity não publicou quantos agentes ou organizações operaram com a função predefinida no período entre a alteração do IMDSv2 de fevereiro e a restrição de final de setembro, e nada nas fontes citadas afirma que quaisquer dados de clientes tenham sido expostos fora do próprio ambiente dos investigadores. A alteração do IMDSv2 aplica-se a agentes implementados após 14 de fevereiro de 2026, de acordo com a AWS, conforme noticiado pela Zenity; o que significa para agentes implementados antes dessa data não é indicado nas fontes aqui analisadas. O arquivo não regista nenhum dano real, e as fontes corroboram essa leitura ao descreverem uma demonstração e ao contestar a AWS a classificação de vulnerabilidade, em vez de relatar um incidente próprio.

Sharbat disse ao Dark Reading que a Zenity agora está analisando outras plataformas de nuvem em busca de problemas semelhantes de acesso a metadados, e que a empresa ainda não está nomeando-as. A conclusão que ele apresenta é sobre permissões, e não apenas sobre o serviço de metadados: "Mesmo que alguém consiga acessar o IMDS, o raio de impacto será muito menor."

Por que este registro é mantido

O AgentCorruption não é notável porque os endpoints de metadados sejam uma ideia nova. Sharbat apontou à audiência da SecTor a violação da Capital One em 2019, na qual um SSRF alcançou o IMDS e se converteu em credenciais roubadas, e descreveu isso como uma falha de privilégio mínimo do mesmo tipo. O que é novo é o ator que faz a busca. A requisição que produziu uma identidade AWS foi feita por um agente de IA fazendo o que lhe foi pedido, em linguagem simples, por meio de uma ferramenta que lhe foi dada para que pudesse ser útil — e o agente retransmitiu a resposta de volta. As duas condições que transformaram isso em um problema de toda a conta foram um endpoint de metadados que o sandbox não bloqueou e um papel padrão mais amplo do que o agente que o detinha.

A pesquisa completa, incluindo a série técnica em cinco partes e o vídeo de demonstração, está vinculada ao comunicado de imprensa da Zenity de 8 de outubro de 2026. Este registro é uma entrada entre os incidentes de agentes documentados no arquivo de incidentes de IA, onde cada entrada traz suas próprias fontes, gravidade, grau de confiança e indicador de disputa — os campos que permitem distinguir uma disputa de fornecedor sobre enquadramento, como aqui, de uma constatação contestada de dano.

Este é um registro, pesquisado e relatado por outros e aqui citado em referência a eles. Os outros incidentes documentados de agentes, cada um com suas próprias fontes, gravidade, grau de confiança e sinalização de contestação, estão em the AI incident archive — assim, uma configuração padrão da plataforma que transforma um único prompt em um ponto de apoio em toda a conta pode ser lida ao lado do que realmente aconteceu em outros lugares.