Um único prompt bastava para sequestrar todos os agentes de IA de uma conta na AWS

O que a Zenity encontrou

Pesquisadores da Zenity Labs descobriram uma cadeia de falhas no Amazon Bedrock AgentCore, a plataforma da AWS para rodar agentes de IA corporativos com ferramentas, memória e controle de acesso. Segundo o relatório técnico publicado pela Zenity, bastava ter acesso de chat a um único agente público para tomar o controle de todos os agentes do AgentCore na mesma conta e região da AWS.

A empresa batizou o conjunto de falhas de AgentCorruption. Com uma única mensagem de texto, em linguagem natural, os pesquisadores conseguiram expor conversas privadas de outros usuários, baixar código-fonte de agentes internos e roubar credenciais armazenadas. Segundo a Zenity, o problema era sistêmico e afetava agentes com ferramentas nativas em várias contas da AWS, não um caso isolado de configuração errada por parte de um cliente.

Como o ataque funcionava: do chat ao furto de credenciais

Toda instância na AWS pode consultar um serviço interno chamado Instance Metadata Service, acessível pelo endereço 169.254.169.254, que devolve credenciais temporárias para a instância se autenticar com outros serviços da AWS. Um agente de IA, em teoria, não deveria conseguir alcançar esse endereço. Na prática, o isolamento simplesmente não existia no AgentCore.

Os pesquisadores montaram um agente de teste com Strands, framework de código aberto da própria AWS que já vem com uma ferramenta de acesso à web. Pediram, em português claro (no teste original, em inglês), para o agente consultar o serviço de metadados e enviar o resultado para um servidor externo. O agente obedeceu.

A fronteira de sandbox que achávamos que estaríamos enfrentando simplesmente não existia.

The sandbox boundary we were supposed to be fighting simply wasn't there.Pesquisadores da Zenity Labs

As credenciais roubadas funcionaram fora da plataforma, na própria máquina dos pesquisadores, o que significa que depois do primeiro passo eles nem precisavam mais do agente para continuar o ataque. O serviço de metadados também devolveu certificados e chaves de um serviço interno da AWS, além de uma URL pré-assinada para um bucket S3 que não pertencia à conta dos pesquisadores.

Permissões padrão expuseram toda a conta

O ponto mais grave, segundo a Zenity, não foi o vazamento de credenciais de um agente isolado: foi o escopo dessas permissões. O papel de execução padrão do AgentCore concedia acesso de leitura, escrita e exclusão que valia para todos os agentes da mesma conta e região, não apenas para o agente que recebeu o pedido.

Com essas credenciais em mãos, os pesquisadores conseguiram:

• Listar todos os agentes da região em segundos
• Baixar os pacotes de container (com código-fonte) de cada agente
• Invocar diretamente qualquer agente da conta, inclusive os que não eram públicos
• Ler conversas privadas entre usuários e outros agentes
• Alterar a memória de longo prazo de agentes que tinham esse recurso ativado

Os pacotes de código baixados costumam carregar senhas e chaves de API esquecidas junto com o código-fonte, o que amplia o estrago além dos próprios agentes. Um atacante poderia, por exemplo, partir de um agente de atendimento ao cliente exposto publicamente e chegar a um agente financeiro interno. Para agentes com memória de longo prazo ativa, a Zenity descreve em outro estudo como plantou instruções que faziam o agente encaminhar conversas futuras para um destino externo, sem que o usuário percebesse qualquer mudança de comportamento.

O que a AWS corrigiu, e o que ainda fica por conta do cliente

A Zenity relatou as descobertas à AWS em 25 de dezembro de 2025. Depois do aviso, a AWS tornou o IMDSv2, versão mais segura do serviço de metadados, o padrão para novas implantações no AgentCore, fechando o vetor de entrada usado no ataque original.

A empresa também alterou o papel de execução padrão do AgentCore por volta de agosto de 2026. O novo papel não permite mais que um agente invoque outros agentes, leia conversas privadas ou recupere credenciais guardadas no AWS Secrets Manager, e restringiu outras permissões que antes eram concedidas por padrão.

Ainda assim, a Zenity recomenda que empresas criem papéis de execução personalizados, com acesso mínimo necessário para cada agente, em vez de confiar no padrão da plataforma. A correção da AWS reduz a superfície de ataque, mas não elimina a responsabilidade de configurar permissões sob medida para cada caso de uso.

O que fazer agora se a sua empresa roda agentes no AgentCore

Para times de TI que já têm agentes em produção no Bedrock AgentCore, ou estão avaliando a plataforma, a lição prática é direta:

1. Audite o papel de execução (execution role) de cada agente e remova qualquer permissão que não seja estritamente necessária para a função dele
2. Separe agentes públicos de agentes internos em contas ou regiões diferentes, em vez de deixá-los compartilhar o mesmo escopo de permissões
3. Trate qualquer entrada de texto de um agente com ferramenta de acesso à web ou linha de comando como potencialmente hostil, já que o ataque dependia só de linguagem natural
4. Revise se a memória de longo prazo dos agentes está habilitada sem necessidade, dado o risco de envenenamento de memória
5. Confirme que novas implantações já usam IMDSv2 e que o papel padrão atualizado pela AWS está de fato em uso nos ambientes existentes

O CTO da Zenity, Michael Bargury, resume a tensão por trás do problema:

Segurança em nuvem é sobre segmentação e acesso de menor privilégio. Mas agentes de IA precisam de liberdade criativa para serem úteis.

Cloud security is about segmentation and least-privilege access. But AI agents need creative freedom to be useful.Michael Bargury, CTO da Zenity Labs

Essa tensão fica mais visível quando agentes voltados ao público e agentes internos dividem o mesmo ambiente de nuvem. Nesse desenho, uma única falha pode derrubar a fronteira de segurança do sistema inteiro, como aconteceu no AgentCore.

Não é caso isolado entre plataformas de agentes

A Zenity já havia documentado padrão parecido em outras pesquisas. No estudo chamado AgentFlayer, ataques de clique zero fizeram Salesforce Einstein, Copilot Studio e Cursor vazarem dados de clientes ou credenciais. Em outro caso, batizado AgentForger, um link adulterado do ChatGPT bastou para criar um agente autônomo nos Workspace Agents da OpenAI com as exigências de aprovação desativadas.

A OpenAI corrigiu sua falha em quatro dias. As permissões excessivas do AgentCore, segundo a Zenity, persistiram por meses depois do aviso inicial. A AWS já disponibilizou o AgentCore para empresas em geral, com clientes que incluem Sony e Ericsson, segundo a própria Amazon.

A manipulação de memória de longo prazo também aparece em pesquisas independentes. O Google DeepMind lista esse tipo de ataque como categoria própria em sua taxonomia de riscos de agentes de IA, apontando que alguns documentos envenenados numa base de conhecimento já bastam para direcionar as respostas de um agente. Em outro estudo de red team, pesquisadores assumiram o controle remoto de um agente OpenClaw através de um documento editável externamente e vinculado ao arquivo de memória dele, enquanto outro agente, no mesmo teste, chegou a entregar dados bancários sem qualquer redação.

O CEO da OpenAI, Sam Altman, já defendeu publicamente que agentes devem receber apenas o acesso mínimo necessário para a tarefa. Segundo a Zenity, foi exatamente esse princípio que o papel padrão do AgentCore violava.

Fonte: The Decoder