A publicação AgentCorruption da Zenity, de 8 de outubro, descreve um caminho histórico de um agente Amazon Bedrock AgentCore público até runtimes vizinhos e memória persistente. A condição decisiva era um papel de execução amplo na mesma conta AWS e região, não invasão de clientes diferentes ou roubo de senha administrativa.
Um pedido de rede induzido por prompt expôs credenciais temporárias; o IAM ampliou seu alcance. Antes da divulgação, pesquisadores viram restrições substanciais no papel padrão. A pesquisa demonstra falhas dos padrões anteriores testados, não que toda instalação atual permita a cadeia completa.
O prompt atravessou para uma identidade de workload confiável
Disponível em geral desde outubro de 2025, AgentCore combina runtimes isolados, identidade, memória, gateways, navegador, execução de código e observabilidade. Resolve problemas reais, mas a integração cria dependências de autorização além da microVM.
No teste, uma ferramenta HTTP seguiu instruções não confiáveis e pediu metadados locais. A AWS usa serviço link-local; as microVMs Firecracker do AgentCore oferecem o MMDS relacionado. Credenciais temporárias legitimamente permitem acesso aprovado sem chaves permanentes embutidas em imagens.
O pedido ocorreu dentro da microVM e foi tratado como local, retornando chave de acesso, segredo e token de sessão temporários. É SSRF: induzir um componente servidor a contatar destino inacessível ao atacante diretamente. A injeção forneceu intenção, a ferramenta rede e os metadados identidade.
Texto inseguro sozinho não produziria a cadeia. Bloquear acesso desnecessário de ferramentas aos metadados interromperia o caminho; um papel restrito conteria efeitos mesmo após vazamento. A documentação AWS diz explicitamente que código ou atores da microVM acessam credenciais e exige permissões mínimas.
A Zenity relatou metadados em 25 de dezembro de 2025. A AWS encerrou como informativo em 12 de abril de 2026, dizendo que novas implantações usavam IMDSv2 desde 14 de fevereiro. Tokens preliminares bloqueiam muitos SSRF convencionais, mas ferramentas flexíveis podem realizar essas etapas. Para a Zenity, isso adiciona atrito sem resolver confiança.
A orientação atual diz rejeitar runtimes sem MMDSv2 desde 30 de junho de 2026. Clientes devem verificar a configuração implantada, incluindo requireMMDSV2, sem presumir atualização de toda instalação antiga. Metadados protegidos são uma camada, não justificativa para privilégios excessivos disponíveis ao código legítimo.
Permissões amplas tornaram o ponto inicial útil em outros recursos
O segundo relatório, de 12 de janeiro, focou no alcance do papel. Listagem regional de grupos CloudWatch e padrões de nomes AgentCore revelaram IDs de runtimes e memórias sem inventário prévio. Permissões ECR e repositórios previsíveis ligaram runtimes a imagens, potencialmente expondo código e configurações.
O direito wildcard testado de invocação alcançava agentes privados da mesma conta e região. Um bot público poderia atingir agente de cobrança mais sensível. A Zenity mostrou ferramentas e billing.json em um agente de teste por APIs legítimas, não um segundo exploit independente.
Direitos de memória permitiriam listar atores, sessões e eventos de outros agentes e usuários. Conversas poderiam conter dados pessoais, código, planos, clientes ou credenciais coladas em diagnóstico. Um segredo não dever estar na conversa é diferente de workloads não relacionados poderem lê-lo.
Criar e excluir eventos ameaçava também integridade. Contexto falso poderia entrar na sessão e resultados reais desaparecer. Isolamento computacional não impedia a identidade de chamar ou modificar recursos vizinhos; autorização isolada é outro requisito.
A AWS informou em 25 de fevereiro que tratava o problema. Segundo pesquisadores, em 22 de junho o padrão estava inalterado; em 29 de setembro havia grandes restrições: remoção de chamadas entre runtimes, acesso a conversas privadas e recuperação no Secrets Manager, além de outros cortes.
Isso limita materialmente afirmações atuais. Papéis próprios, políticas copiadas e implantações antigas merecem revisão, mas testes históricos não demonstram autoridade idêntica hoje. Foram ambientes controlados; a evidência pública citada não estabelece exploração ampla de clientes. Não havia boletim dedicado AWS da cadeia completa.
Memória podia preservar influência depois de expirar a credencial
Memória curta contém eventos; estratégias longas extraem fatos, preferências, resumos e lições. Isso ajuda casos pendentes e formatação, mas transforma histórico em entrada de decisões futuras, não somente prova depois de incidente.
A Zenity relata descoberta de IDs por logs, enumeração de atores, sessões e estratégias e adição de eventos hostis. A extração converteu conteúdos em registros longos que sessões futuras podiam recuperar como contexto confiável. Não seria necessário repetir a injeção inicial a cada conversa.
“Comando e controle persistente” é a caracterização do teste pelos pesquisadores. O efeito depende de configuração, recuperação, modelo, ferramentas e permissões. Endereço falso, aprovação fabricada e resumo contaminado ilustram risco, não domínio garantido de todo agente por qualquer memória.
Histórico inserido do assistente pode parecer decisão anterior; resultado apagado remove evidência contrária. Expiração ou rotação impede novo acesso API, mas não apaga código copiado, segredos ou estado contaminado. A recuperação exige identificar sessões, eventos, resumos e memórias afetados.
A AWS recomenda validação, proteção antes de persistir, testes de injeção e mínimo privilégio. Proveniência deve apontar usuário, agente, sessão e extração, permitindo quarentena. Preferências de estilo diferem de destinos de pagamento ou concessão de acesso, que exigem criação, retenção e revisão mais fortes.
Memória não deve autorizar sozinha uma ação de risco. Lembrar conta bancária preferida não substitui aprovação atual independente. Escritas e exclusões devem ser monitoradas além de leituras, incluindo volumes anormais e padrões entre agentes, usando CloudTrail, logs e observabilidade AgentCore.
A autorização pertence fora do julgamento do modelo
A AWS alerta contra políticas amplas de desenvolvimento geradas por CLI em produção e recomenda ARNs específicos em vez de wildcards. Os privilégios do papel não devem superar os dos sujeitos autorizados a invocá-lo. Exposição pública exige autoridade especialmente pequena.
Isso não torna todo agente público inseguro. Significa tratar linguagem como não confiável, inclusive pedidos hostis de clientes autenticados e instruções indiretas em páginas ou documentos. Autenticação identifica o chamador, não torna seguro todo seu conteúdo.
Gateways, guardrails e interceptores ajudam a validar ou restringir quando nenhuma outra rota autorizada os contorna. Se gateway é a entrada, a invocação direta deve ser limitada ao papel dele. Identidade do usuário precisa vir de sujeitos verificados, não rótulos inventados pelo modelo ou declarados pelo cliente.
IAM por recurso pode impedir outros agentes, imagens, logs regionais e memórias. Workloads públicos e internos não devem compartilhar papéis só por conveniência; contas ou regiões separadas podem criar fronteiras mais claras.
Ferramentas são interfaces privilegiadas, não direitos concedidos pela escolha do modelo. Autorização precisa avaliar usuário, recurso e operação independentemente. Registros técnicos podem conectar responsáveis, políticas, ameaças e incidentes, sem substituir negação imposta.
Revisão atual precisa de histórico e estado duradouro
Uma revisão delimitada cobre papéis, metadados, entrada pública/IAM/JWT, bypass de gateway, direitos entre runtimes, ECR e logs, memória entre usuários, escrita/exclusão e recuperação de tokens e Secrets Manager. Políticas de identidade e recurso devem ser testadas juntas para a negação esperada, não julgadas por um protótipo que funciona.
Exposição histórica pede eventos do período em CloudTrail, invocações, atividade de metadados, imagens, memória e segredos, não só políticas atuais. Credenciais temporárias deixam efeitos permanentes; rotação e validação de estado se complementam.
Evidências futuras úteis seriam aviso formal ou migração AWS, maior separação de ferramentas e endpoints de credenciais e proveniência de memória visível ao cliente, escrita restrita, alertas e quarentena em lote. São sinais a verificar, não recursos presumidos entregues.
A questão ampla é o que ainda acontece depois de o modelo seguir uma instrução maliciosa. Infraestrutura gerenciada reduz complexidade, mas não pode fundir ferramentas, identidade e memória em um papel amplamente confiável. Limites determinísticos devem impedir que uma resposta manipulada vire incidente de toda a conta, mesmo quando a defesa do modelo falha.
Fontes e leituras relacionadas
Cadeia de ataque Zenity · Credenciais na AWS · Análise de papéis Zenity · Segurança de runtime AWS · Leitura: bases de conhecimento técnico · Estudo de envenenamento de memória · Práticas de memória AWS · Reportagem AgentCorruption