Pesquisa da Zenity: o prompt foi a porta de entrada, o role do agente decidiu o estrago

Prompt injection costuma ser discutido como um problema de modelo: como impedir que um agente siga instruções escondidas na sua entrada. A nova pesquisa do Zenity Labs sobre o Amazon Bedrock AgentCore é um lembrete de que a pergunta mais cara vem depois que a injeção dá certo. Até onde chega a própria identidade na nuvem do agente?

No ambiente testado pelos pesquisadores, a resposta era muito mais do que um único agente deveria alcançar. A Zenity relata que, partindo de um único agente exposto publicamente, obteve as credenciais do role de execução desse agente, e que as permissões do role alcançavam todos os agentes da mesma conta e da mesma região da AWS: outros agentes podiam ser invocados, suas imagens de container recuperadas, e sua memória, incluindo conversas privadas entre usuários e agentes, lida e alterada.

Duas ressalvas enquadram tudo o que vem abaixo. Primeiro, este é o relato dos pesquisadores sobre a própria configuração de teste, publicado em 8 de outubro como uma série de posts; não encontramos nenhuma declaração pública da AWS sobre o assunto, e a AWS encerrou o primeiro dos dois relatórios da Zenity como “informative”. Segundo, a Zenity vende produtos de segurança para agentes do AgentCore. Nenhum dos dois pontos torna os achados errados, mas ambos precisam ficar ao lado deles.

O role, não o prompt, definiu o raio de impacto

O achado central é sobre escopo. Segundo a Zenity, o role de execução padrão ligado aos agentes “não era escopado para o agente específico”: suas permissões cobriam runtimes de agentes, memória e logs em toda a região, em vez dos recursos do agente ao qual pertencia. Os pesquisadores chamam o resultado de “movimento lateral amplo”.

É uma falha de nuvem conhecida em um lugar novo. Um role de workload escrito com wildcards é um risco em qualquer serviço de computação. Em uma plataforma de agentes, o risco é mais afiado por dois motivos. O workload recebe instruções em linguagem natural de quem conseguir falar com ele, então o caminho da entrada externa até o role é curto. E os vizinhos que ele alcança são outros agentes, cuja memória guarda o que os usuários contaram a eles, que muitas vezes é exatamente o dado pessoal e de negócio que a plataforma deveria manter separado.

O achado sobre a memória merece uma linha própria. A Zenity relata que o role não só podia ler a memória como escrever nela, o que transforma um problema de confidencialidade em um problema de integridade: um agente que confia na própria memória pode ser conduzido por quem conseguir adicionar algo a ela. Fizemos esse ponto geral quando escrevemos que memória de agente é armazenamento de dados enterprise; é isso que acontece quando o caminho de escrita está aberto.

O que o role de execução de um agente deveria alcançar

Os recursos do próprio agente

• Seu runtime
• Sua memória
• Seus logs
• Seu acesso ao modelo

Escopado por recurso, não por wildcard

Todo o resto na conta

• Outros agentes
• A memória e as sessões deles
• Segredos compartilhados
• Imagens de container

Alcançado apenas por uma chamada auditada sob outra identidade

O que a AWS mudou, e o que deixa para você

A linha do tempo da Zenity se estende por quase um ano. Ela reportou o problema de acesso inicial em 25 de dezembro de 2025, e o role padrão com privilégios excessivos em 12 de janeiro de 2026. O AgentCore passou a usar somente IMDSv2, um endurecimento de como os workloads obtêm credenciais, em 14 de fevereiro de 2026, segundo os pesquisadores. Em junho, dizem eles, o role padrão continuava inalterado. Em uma revisão final em 29 de setembro, a Zenity observou “mudanças substanciais” no role de execução padrão: execução de agentes entre regiões, leitura de conversas privadas e acesso ao Secrets Manager foram removidos, e outras permissões foram significativamente restringidas. A Zenity não publica as permissões do role antes e depois.

Três consequências decorrem disso para times que rodam agentes no AgentCore, ou em qualquer plataforma que liga um role na nuvem a um agente.

Um padrão mais seguro não reescreve roles que você já tem. A Zenity não diz se roles existentes foram atualizados. Roles do IAM em uma conta de cliente normalmente só mudam quando alguém as muda, então agentes implantados com o padrão anterior merecem uma revisão direta dos seus roles de execução, em vez de suposição.

Escope cada role para um agente. Runtime, memória, logs e segredos devem ser nomeados por recurso. Separar agentes expostos publicamente dos internos, por conta onde o risco justifica, limita o que um comprometimento consegue alcançar; a Zenity observa que muitas organizações rodam os dois tipos lado a lado.

Trate requisições de saída das ferramentas do agente como fronteira de segurança. Qualquer ferramenta que busca URLs em nome do agente pode ser apontada para um lugar inesperado. Regras de egress aplicadas fora do agente, o tipo de fronteira que discutimos em nossa análise de contenção de agentes, e credenciais que nunca entram no ambiente do agente, como no próprio design do Strands Box, da AWS, ambos reduzem o que um agente manipulado consegue fazer.

A lição não é específica da AWS. Todo runtime gerenciado de agente dá ao agente uma identidade na nuvem por baixo dele, e essa identidade geralmente é criada pelo ferramental de deploy, revisada por ninguém do programa de IA, e invisível na própria trilha de auditoria do agente. O prompt injection não será totalmente prevenido. Até onde ele viaja é decidido no IAM, antes de o primeiro prompt chegar.