Um prompt sequestrou todos os agentes AWS na região

Um chat público, acesso total

Bedrock AgentCore era para ser a base segura para rodar agentes de IA na AWS com ferramentas, memória e controle de acesso. Na prática, pesquisadores da Zenity mostraram que bastava uma única mensagem enviada para um agente público para comprometer todos os outros agentes da mesma conta e região. Não foi phishing, não foi engenharia social complexa, foi um prompt direto pedindo para o agente consultar um endereço interno e enviar o resultado para fora.

Se você opera agentes em produção, esse caso dói porque mexe no ponto mais sensível: isolamento. A gente assume que cada agente roda na sua caixinha, com sua role, seu escopo, seu limite. Aqui a caixinha simplesmente não existia. E quando o isolamento falha na camada da plataforma, não adianta ter prompt bem escrito ou guardrail bonitinho no topo. O problema está embaixo, na fundação.

O fato

O time da Zenity Labs chamou a cadeia de falhas de 'AgentCorruption'. O alvo foi o Amazon Bedrock AgentCore, a plataforma da AWS para executar agentes empresariais com acesso a ferramentas, memória de longo prazo e gestão de permissões. Segundo os pesquisadores, o problema era sistêmico e afetava agentes com ferramentas embutidas em várias contas da AWS.

O ataque começava com acesso de chat a apenas um agente exposto, como um agente de atendimento ao cliente. Com um único prompt, eles conseguiam extrair credenciais internas daquele agente e, a partir daí, listar todos os agentes da mesma conta e região, baixar pacotes de código em segundos, ler conversas privadas e invocar outros agentes. Para agentes com memória ativada, era possível até envenenar a memória para influenciar comportamentos futuros, como instruir o agente a encaminhar conversas para um servidor externo.

A AWS já aplicou correções parciais, dificultando para novos agentes a recuperação de metadados internos e apertando a role de execução padrão. Mesmo assim, a recomendação continua sendo revisar manualmente as permissões e aplicar o princípio de privilégio mínimo em cada agente.

Como funciona na visão de quem opera

Para entender o estrago, pense na arquitetura. Todo workload na AWS costuma consultar o Instance Metadata Service no endereço 169.254.169.254 para pegar credenciais temporárias. Quem tem essas credenciais consegue se passar por aquele workload. Em um desenho correto, um agente de IA jamais deveria alcançar esse endereço, ainda mais com uma ferramenta web genérica.

Os pesquisadores construíram um agente de teste com o Strands, framework open source da própria AWS que já vem com ferramenta web. Eles pediram em linguagem simples para consultar o serviço de metadados e enviar a resposta para fora. O agente obedeceu. Nas palavras deles, a fronteira de sandbox que eles esperavam enfrentar simplesmente não estava lá. E remover a ferramenta web não resolveria, porque a falha estava na plataforma. Eles repetiram o caminho até por linha de comando.

O segundo elo é ainda mais crítico para quem opera. As credenciais roubadas funcionavam fora da plataforma, no computador dos pesquisadores, o que eliminava a necessidade de continuar usando o agente inicial. Além disso, o serviço de metadados expôs material de certificado e chave de um serviço interno e uma URL pré-assinada para um storage S3 interno que nem pertencia à conta deles. Em termos de API, custo e latência, isso é devastador porque o ataque é barato, rápido e silencioso. Não precisa de brute force, não gera pico de latência, é só uma chamada de leitura que retorna um segredo válido.

Permissão padrão ampla demais

O golpe final veio das permissões padrão. Em vez de limitar cada agente ao seu próprio escopo, a role de execução padrão valia para todos os agentes da mesma conta e região, com acesso de leitura, escrita e deleção. Na prática, isso permitia listar agentes, baixar o código fonte empacotado, invocar qualquer um e ler históricos privados. E esses pacotes costumam carregar senhas esquecidas, chaves de API e trechos de lógica interna. Ou seja, de um agente público de suporte você pulava para um agente financeiro interno e herdava os dados dele.

Para quem trabalha com memória de agente, o ponto mais incômodo é o memory poisoning. Se o agente guarda contexto de longo prazo sem validação forte de origem, uma escrita maliciosa vira comportamento persistente. Não é só vazar o passado, é controlar o futuro do agente sem precisar atacar de novo.

O que isso muda na prática

Quem ganha com essa descoberta é quem constrói com mentalidade de plataforma, não de demo. Quem perde é quem subiu dez agentes rapidinho, todos pendurados na mesma role padrão, com um deles exposto na web. Esse padrão era comum porque era conveniente. Agora ficou claro que conveniência aqui significa blast radius total na região.

Se você tem AgentCore em produção, tem ajuste imediato para fazer. Comece pelo isolamento de identidade e rede, depois revise dados e memória. Uma ação prática que você pode executar hoje é auditar todas as roles de execução dos seus agentes e quebrar a role padrão compartilhada por função e por ambiente.

• Separe público de interno: agente exposto em chat nunca deve compartilhar conta, região ou role com agente financeiro, de RH ou com acesso a dados sensíveis.
• Aplique privilégio mínimo de verdade: crie roles específicas por agente, sem listar, invocar ou ler outros agentes, e bloqueie saída para metadados e S3 interno.
• Trate pacote de código como segredo: remova senhas e chaves hardcoded, gire tudo que estava embutido e ative logs de quem listou, baixou ou invocou agentes.

A tensão que fica

O incômodo real não é só o bug, é o modelo mental. Agentes precisam de ferramentas poderosas para serem úteis, mas cada ferramenta aumenta a superfície de ataque. Se a plataforma entrega isolamento fraco e permissão ampla por padrão, a maioria dos times vai herdar essa fragilidade sem perceber. Isso escala? Hoje, quanto mais agentes você coloca na mesma região, maior o prêmio para o atacante que achar o mais fraco. O custo compensa? Para a AWS, apertar o padrão pode gerar fricção e quebrar tutoriais. Para você, operar com roles granulares dá trabalho, aumenta a gestão de IAM e pode adicionar latência de revisão. Mas resolve ou só move o gargalo? Mesmo com o fix parcial, memória persistente, pacotes com segredos e conversas armazenadas continuam sendo alvos valiosos se outro isolamento falhar.

Conclusão

O caso mostra que segurança de agentes não se resolve só no prompt, se resolve na identidade, na rede e nas permissões. Vale perguntar agora: quantos dos seus agentes ainda rodam com a role padrão na mesma região do seu agente público?