O que os investigadores fizeram

A Zenity Labs publicou a 8 de outubro a primeira parte de uma cadeia a que chama AgentCorruption. O alvo é o Amazon Bedrock AgentCore Runtime, o serviço gerido que as empresas usam para correr agentes de IA na AWS.

Os investigadores colocaram em funcionamento um agente de exemplo construído com o Strands, o SDK de agentes de código aberto da AWS, usando a ferramenta http_request nele incorporada. Depois pediram ao agente que consultasse o ponto final de metadados da instância em 169.254.169.254 e reencaminhasse a resposta para um recetor que controlavam. Ele fê-lo. Reproduziram o mesmo resultado através da ferramenta shell do SDK.

A conclusão da Zenity é sobre a plataforma e não sobre a ferramenta: “A microVM não restringia o tráfego para o serviço de metadados”, e “A falha de isolamento está ao nível da plataforma, não da ferramenta”.

O que os metadados entregaram

O serviço de metadados devolveu o nome do papel de execução do agente e as suas credenciais temporárias de STS. Os investigadores confirmaram que essas credenciais funcionavam totalmente fora do AgentCore: aws sts get-caller-identity devolvia o papel assumido pelo agente.

A partir daí os metadados continuaram a dar. Os dados de utilizador revelaram o URI da imagem de contentor do agente no Elastic Container Registry. As etiquetas de instância expuseram material de certificado e chave mTLS e um URL de S3 pré-assinado.

Uma pessoa a desenhar diagramas de fluxo num quadro branco de escritório
A Zenity diz que a falha de isolamento está na plataforma, não na ferramenta. Fotografia ilustrativa. Christina Morillo · pexels · Pexels License

Porque é que um agente chegava a todos

O papel de execução é a parte com que a Zenity é mais dura: “O papel que o AgentCore associa por omissão ao tempo de execução do agente tem privilégios muito excessivos”. Tinha permissões de leitura do ECR com carateres universais, e o AgentCore nomeia os repositórios de imagens de forma previsível, como bedrock-agentcore-<nome_do_agente>.

Essa combinação transformou um agente comprometido num diretório de todos os outros agentes da mesma conta e região. Nas palavras dos investigadores, “correr a nossa ferramenta automatizada sobre todos os agentes descobertos deu-nos todo o código-fonte de todos os agentes da região em poucos segundos”. A Zenity diz que as publicações seguintes vão cobrir capacidades de leitura, escrita e eliminação no AgentCore e noutros serviços da AWS na região.

O que a AWS mudou, e o que diz agora

A cronologia da Zenity não é coerente consigo mesma: o texto diz que as conclusões chegaram à AWS a 17 de dezembro de 2025, enquanto a sua própria tabela data a divulgação do problema de IMDS a 25 de dezembro de 2025. As datas seguintes são mais claras. A 14 de fevereiro de 2026 o AgentCore passou a usar apenas IMDSv2, pelo que os agentes recém-implementados arrancam com ele. A 12 de abril de 2026 a AWS respondeu e encerrou o relatório como “informativo”. Não foi atribuído qualquer CVE.

A posição da AWS, numa declaração relatada pelo The Decoder a 9 de outubro, é que a investigação “retrata de forma inexata um comportamento esperado e documentado como uma vulnerabilidade”. A AWS disse que um agente só pode alcançar recursos de outra conta quando um programador concedeu explicitamente permissões tanto no papel de execução como no recurso de destino, e remete para a sua documentação de permissões do tempo de execução e para papéis de privilégio mínimo. O The Decoder relata que a AWS também estreitou depois o papel de execução por omissão, retirando permissões para invocar outros agentes, ler conversas privadas e obter credenciais do Secrets Manager.

Uma fila de portas de armário idênticas com volantes e chaves deixadas nas fechaduras
O papel por omissão conseguia listar e descarregar todas as imagens de agentes da região. Fotografia ilustrativa. cottonbro studio · pexels · Pexels License

A discussão de fundo

Ambos os lados concordam na mecânica e discordam sobre de quem era a tarefa. O argumento da AWS é que um papel por omissão é um ponto de partida e a documentação diz para o estreitar. O da Zenity é que um tempo de execução gerido cuja caixa de areia não bloqueia o serviço de metadados, e cujo papel por omissão consegue enumerar os vizinhos, entrega uma predefinição que a maioria dos clientes nunca vai mudar.

É a mesma discussão que o setor da nuvem teve sobre os buckets S3 públicos, e foi resolvida mudando a predefinição, não a documentação.

O que observar

A Zenity diz que esta é a primeira parte. As seguintes é que contam: o acesso inicial a credenciais é uma conclusão séria, mas o que chamou a atenção foi o movimento lateral entre todos os agentes de uma região, e essa parte ainda está por publicar em detalhe.

Para quem corre agentes no AgentCore hoje, a medida prática não está em disputa. O fornecedor e os seus críticos dizem o mesmo: não entrar em produção com o papel de execução por omissão.