Zenity AgentCorruption Expôs um Caminho de Sequestro em Toda a Conta do AWS AgentCore

Pesquisadores do Zenity AgentCorruption descobriram que um único prompt malicioso poderia expor credenciais temporárias da AWS a partir de um agente Amazon Bedrock AgentCore acessível publicamente. Segundo o relato, essas credenciais abriam caminhos para todos os runtimes do AgentCore que compartilhassem a conta, a região e a função padrão vulnerável com permissões amplas. A descoberta transformou um problema conhecido de injeção de prompt em uma falha de segurança em nuvem que abrangia toda a conta.

O ataque não dependia de violar um modelo fundacional, escapar para um cliente AWS não relacionado ou roubar uma senha de administrador. Ele combinava a capacidade de um agente de fazer requisições HTTP com credenciais de metadados e permissões excessivas de Identity and Access Management. A Zenity afirma que a cadeia alcançava agentes privados, código-fonte, históricos de conversas, segredos armazenados e memória de longo prazo.

Essa combinação importa mais do que o número chamativo de um único prompt. A AWS promovia o AgentCore como infraestrutura gerenciada para operar agentes de produção com segurança, incluindo identidade, memória, ferramentas, observabilidade e runtimes isolados. O AgentCorruption mostrou como esses serviços conectados poderiam ampliar o impacto de um agente comprometido quando suas fronteiras de autorização eram amplas demais.

Há também uma ressalva importante. A Zenity divulgou os problemas meses antes de publicar sua pesquisa em 8 de outubro de 2026. Os pesquisadores relataram que a AWS restringiu a função de execução padrão antes da publicação, enquanto a documentação da AWS agora exige controles de metadados mais fortes e alerta contra o uso em produção de políticas amplas geradas pela CLI.

O resultado não é prova de que todas as implantações atuais do AgentCore continuem expostas à cadeia completa. É evidência de que as equipes não podem tratar a infraestrutura gerenciada de agentes como substituta do princípio do menor privilégio. A segurança de agentes agora precisa abranger conjuntamente o comportamento do modelo de linguagem, as credenciais de runtime, as permissões em nuvem, a integridade da memória e o movimento lateral.

Como o Zenity AgentCorruption Transformou um Prompt em Credenciais da AWS

A primeira falha atravessou a fronteira entre uma entrada linguística não confiável e uma identidade de nuvem confiável.

De acordo com a pesquisa AgentCorruption da Zenity, um agente AgentCore exposto aceitou um prompt que o instruía a solicitar um endpoint local de metadados. A requisição visava 169.254.169.254, um endereço link-local usado por ambientes de computação da AWS para fornecer metadados de workloads e credenciais temporárias de função.

O serviço relevante é o Instance Metadata Service, normalmente abreviado como IMDS. O ambiente de microVM Firecracker do AgentCore usa um MicroVM Metadata Service relacionado, ou MMDS, para disponibilizar credenciais de função de execução dentro do workload.

Esse mecanismo de entrega de credenciais tem uma finalidade legítima. Um agente pode precisar de autorização temporária para ler um objeto S3 aprovado, chamar outro serviço AWS ou executar uma tarefa de negócios. Credenciais temporárias também evitam incorporar chaves de acesso permanentes no código ou em imagens de contêiner.

O problema surge quando um prompt não confiável pode fazer uma ferramenta contatar o endpoint de metadados. A Zenity afirma que uma ferramenta capaz de usar HTTP enviou a requisição de dentro da microVM, de modo que o serviço de metadados a tratou como uma solicitação local do workload. A resposta expôs a chave de acesso temporária, a chave secreta e o token de sessão do runtime do agente.

Esse é um padrão de falsificação de requisições do lado do servidor, geralmente chamado de SSRF. Um atacante induz um componente do lado do servidor a solicitar um destino que ele não consegue alcançar diretamente. Neste caso, segundo o relato, o agente se tornou o componente solicitante porque suas ferramentas podiam fazer chamadas HTTP de saída.

A injeção de prompt forneceu a intenção, enquanto a ferramenta HTTP forneceu a capacidade. O serviço de metadados então forneceu uma identidade de nuvem. Nenhum desses elementos, isoladamente, teria produzido o impacto relatado.

Um modelo que apenas gerasse texto inseguro não teria roubado credenciais. Um endpoint de metadados protegido contra as ferramentas do agente teria interrompido o caminho. Uma função de execução com escopo restrito teria contido as consequências mesmo após o roubo das credenciais.

A AWS agora documenta explicitamente essa propriedade de exposição de credenciais. Sua orientação sobre credenciais afirma que códigos ou atores dentro de uma microVM podem chamar o endpoint de metadados e acessar as credenciais disponíveis. Por isso, a AWS orienta os clientes a limitar as funções de execução apenas às permissões exigidas por seus workloads.

A Zenity relatou inicialmente o problema de metadados à AWS em 25 de dezembro de 2025. Os pesquisadores afirmam que a AWS encerrou o relatório como informativo em 12 de abril de 2026. A AWS lhes disse que agentes recém-implantados usavam IMDSv2 desde 14 de fevereiro.

O IMDSv2 exige um token de sessão antes que um cliente possa recuperar metadados. Esse projeto bloqueia muitos ataques SSRF convencionais porque o atacante nem sempre consegue controlar a solicitação preliminar de token e seus cabeçalhos.

Um agente autônomo muda essa premissa. Se o agente puder fazer requisições suficientemente flexíveis, poderá obter o token e então recuperar credenciais. A Zenity argumenta que exigir o IMDSv2 aumentou o atrito, mas não eliminou o problema subjacente de confiança.

Posteriormente, a AWS foi além da adoção opcional. A orientação atual de runtime afirma que runtimes do AgentCore sem MMDSv2 habilitado têm sido rejeitados desde 30 de junho de 2026. Esse controle melhora a linha de base, embora não justifique permissões excessivas vinculadas a credenciais que o código legítimo do runtime ainda pode acessar.

A lição essencial é arquitetural. A injeção de prompt se torna um comprometimento de nuvem quando um agente consegue traduzir instruções em linguagem natural em operações privilegiadas de rede e identidade. Filtrar a frase maliciosa resolve apenas uma camada desse caminho.

A Função Padrão Transformou um Agente em Problema de Todos

As credenciais roubadas se tornaram uma alavanca em toda a conta porque a função de execução testada confiava a um agente acesso regional a outros agentes.

A Zenity apresentou um segundo relatório em 12 de janeiro de 2026, concentrando-se nas permissões por trás do comprometimento inicial. Os pesquisadores disseram que a função padrão não se limitava ao runtime que a assumia. Diversas permissões se aplicavam a recursos do AgentCore em toda a mesma conta e região da AWS.

A primeira etapa de expansão usou o CloudWatch Logs. A Zenity afirma que logs:DescribeLogGroups permitia à identidade comprometida listar nomes de grupos de logs regionais. As convenções de nomenclatura do AgentCore expunham identificadores de runtimes e recursos de memória nesses nomes.

Os atacantes não precisavam de um inventário prévio de agentes privados. Segundo o relato, eles podiam derivar identificadores de runtime a partir de metadados operacionais já visíveis para a função. A descoberta transformou uma identidade roubada de um ponto de apoio local em um mapa de recursos vizinhos.

A função também continha permissões regionais para o Amazon Elastic Container Registry. A Zenity afirma que nomes previsíveis de repositórios permitiram aos pesquisadores associar runtimes do AgentCore a imagens de contêiner. A extração dessas imagens expôs código de aplicação e, potencialmente, configurações sensíveis incorporadas aos artefatos implantados.

Essa descoberta desafia uma suposição comum sobre runtimes gerenciados. Uma microVM pode isolar uma sessão em execução de outra, enquanto o IAM ainda autoriza a sessão a recuperar recursos não relacionados. Isolamento de computação e isolamento de autorização resolvem problemas diferentes.

Em seguida veio bedrock-agentcore:InvokeAgentRuntime. A análise de função da Zenity mostra que a política testada abrangia recursos de runtime curinga na região. Portanto, as credenciais roubadas podiam invocar agentes privados que um usuário externo jamais deveria alcançar.

Um bot público de suporte poderia ter ferramentas limitadas e dados cuidadosamente filtrados. Um agente privado de faturamento poderia acessar arquivos financeiros, APIs internas ou sistemas de transações. A invocação regional conectou o ponto de entrada exposto ao agente mais sensível.

A Zenity demonstrou esse caminho contra um agente de faturamento de teste. Os pesquisadores enumeraram suas ferramentas, identificaram um arquivo chamado billing.json e instruíram o agente a retornar seu conteúdo. Esse cenário ilustrou movimento lateral por meio de APIs legítimas do AgentCore, e não uma segunda exploração de software.

A memória de conversação ampliou novamente os danos. O AgentCore Memory armazena eventos de curto prazo por recurso de memória, ator e sessão. Estratégias de longo prazo podem preservar fatos extraídos, preferências, resumos e aprendizados para interações futuras.

A Zenity afirma que a função comprometida podia listar atores e sessões e então chamar ListEvents para recuperar conteúdo de conversas. Como essas permissões abrangiam recursos de memória curinga, os pesquisadores supostamente acessaram conversas pertencentes a outros agentes e usuários.

O material exposto poderia incluir informações pessoais, código-fonte, planos internos, registros de clientes ou credenciais coladas durante a solução de problemas. A plataforma não consegue determinar se um segredo inserido em uma conversa deveria estar ali. A autorização precisa impedir que workloads não relacionados leiam a sessão em primeiro lugar.

Permissões de escrita criaram uma ameaça distinta à integridade. A Zenity descobriu que a função podia criar e excluir eventos de memória. Um atacante poderia injetar contexto falso em uma sessão ativa, remover resultados de ferramentas ou influenciar o que o agente acreditava ter acontecido.

Esse risco difere do roubo comum de dados. Um agente manipulado pode continuar se apresentando como um serviço confiável da empresa enquanto age com base em contexto fornecido pelo atacante. Os usuários podem não ver a instrução hostil porque ela permanece no estado armazenado da sessão, e não no prompt visível.

A AWS disse à Zenity em 25 de fevereiro que sua equipe estava resolvendo o problema subjacente. Os pesquisadores verificaram novamente em 22 de junho e relataram que a função padrão permanecia inalterada. Essa cronologia manteve a função ampla no centro da cadeia não resolvida por vários meses.

Durante uma revisão final em 29 de setembro, a Zenity encontrou restrições substanciais. Os pesquisadores afirmaram que a AWS havia removido permissões que possibilitavam invocação entre runtimes, acesso a conversas privadas e recuperação do Secrets Manager. Outras permissões também foram restringidas.

Essa remediação altera significativamente a avaliação de risco atual. A cadeia publicada documenta o que os pesquisadores conseguiram realizar com padrões anteriores, não prova de que permissões idênticas permaneçam vinculadas hoje. Funções criadas por clientes, políticas copiadas e implantações mais antigas ainda merecem revisão direta.

O Isolamento Gerenciado Encontrou uma Realidade com Privilégios Excessivos

O AgentCorruption expôs um conflito entre a promessa de isolamento do AgentCore e os caminhos de autorização compartilhados que cercam cada runtime isolado.

A AWS lançou o AgentCore para disponibilidade geral em outubro de 2025, descrevendo-o como infraestrutura para executar agentes com segurança em escala. A plataforma combinava isolamento de runtime com identidade, memória, gateways, automação de navegador, execução de código e observabilidade.

Cada capacidade resolve um problema real de implantação. Os agentes precisam manter estado entre conversas, credenciais para serviços conectados, acesso governado a ferramentas e rastreamento de ações imprevisíveis. Construir todos esses componentes de forma independente eleva o custo e a complexidade.

No entanto, a integração também cria dependências de segurança. Um runtime pode estar computacionalmente isolado enquanto sua função de execução consegue invocar outro runtime. Um cofre de tokens pode manter segredos fora do código da aplicação, enquanto uma identidade com privilégios excessivos pode solicitar esses segredos.

Essa é a inversão central no Zenity AgentCorruption. Os controles conectados da plataforma gerenciada foram projetados para viabilizar o uso seguro em produção. Sob as configurações padrão testadas, essas mesmas conexões teriam levado o comprometimento através das fronteiras entre serviços.

As atuais práticas de segurança de runtime da AWS reconhecem essa distinção de forma mais direta. A documentação alerta os clientes para não usarem em produção políticas de desenvolvimento geradas pela CLI. Ela recomenda ARNs de runtime específicos em vez de declarações de recursos com curingas.

A orientação também afirma que uma função de execução deve ter privilégios iguais ou menores que os das entidades principais autorizadas a invocá-la. Essa regra oferece uma forma útil de avaliar agentes públicos. Se um usuário anônimo pode invocar um runtime, o runtime não deve herdar autoridade indisponível a usuários anônimos.

A acessibilidade pública não torna automaticamente um agente inseguro. Ela altera o nível de confiança de toda instrução que chega ao modelo. A função de execução deve pressupor que parte das entradas aceitas será maliciosa, enganosa ou projetada para manipular ferramentas.

A autenticação ajuda a identificar quem chama, mas não elimina a injeção de prompt. Uma conta legítima de cliente pode enviar instruções hostis. Documentos e páginas da web comprometidos também podem entregar injeção indireta de prompt depois que o usuário pede a um agente que os resuma.

Os controles de gateway podem reduzir a exposição ao validar solicitações antes que cheguem a um runtime. Guardrails podem detectar padrões de ataque conhecidos, enquanto interceptores podem restringir operações com base em identidade e contexto. Esses controles só funcionam quando quem chama não consegue contornar o gateway e invocar o runtime diretamente.

A orientação de segurança do AgentCore agora recomenda restringir a invocação do runtime à função de execução do gateway quando este for o ponto de entrada pretendido. Essa abordagem move a autorização para fora do ciclo de decisão do modelo. O agente não pode contornar uma negação do IAM por meio de persuasão.

O escopo de recursos no IAM continua sendo a fronteira de contenção mais forte. Um agente de suporte ao cliente não deve receber permissão com curinga para invocar todos os runtimes. Uma permissão de gravação em memória deve nomear o recurso de memória específico, o escopo do ator e a necessidade de negócio sempre que o serviço oferecer essa precisão.

O mesmo raciocínio se aplica a repositórios de contêineres e logs. Metadados operacionais costumam parecer menos sensíveis do que dados de aplicações. Ainda assim, nomes, identificadores, endpoints e padrões de repositório podem se tornar um sistema de descoberta para movimentação lateral.

As organizações também precisam de separação por nível de confiança. Agentes públicos e internos não devem compartilhar funções de execução apenas porque uma ferramenta de configuração torna essa configuração conveniente. Funções sensíveis podem ser divididas entre contas ou regiões da AWS quando controles no nível da conta oferecem um isolamento mais claro.

Nenhum filtro de prompt pode garantir que um modelo rejeitará todas as variações maliciosas. Modelos interpretam significado em vez de aplicar uma gramática finita de comandos. Atacantes podem reformular solicitações, ocultar instruções em dados recuperados ou explorar conflitos entre o contexto do sistema e o do usuário.

Essa limitação não torna a implantação de agentes impraticável. Ela muda onde os defensores devem depositar sua confiança. Defesas no nível do modelo podem reduzir manipulações bem-sucedidas, enquanto controles determinísticos de nuvem limitam o que um modelo manipulado pode fazer.

As equipes devem tratar prompts como entradas não confiáveis e ferramentas como interfaces privilegiadas. Cada chamada de ferramenta precisa de uma decisão de autorização baseada no usuário autenticado, no recurso solicitado e na operação permitida. A decisão do modelo de chamar uma ferramenta nunca deve servir como autorização por si só.

Para organizações que documentam essas decisões, um conjunto pesquisável de bases de conhecimento de engenharia pode ajudar a conectar a propriedade dos runtimes, políticas do IAM, modelos de ameaça e procedimentos de incidente. Esse registro se torna importante quando várias equipes implantam agentes por meio de contas compartilhadas na nuvem.

O Envenenamento de Memória Transformou uma Violação em Controle Persistente

A parte mais consequente da cadeia não foi o roubo de credenciais, mas a capacidade de corromper o que agentes confiáveis lembrariam mais tarde.

O AgentCore Memory oferece suporte a estado de curto e longo prazo. A memória de curto prazo registra eventos turno a turno em uma sessão. A memória de longo prazo extrai informações reutilizáveis para que um agente possa lembrar preferências, fatos, resumos ou aprendizados anteriores.

Essa persistência melhora a usabilidade. Um agente de suporte pode se lembrar de um caso não resolvido, enquanto um assistente de trabalho pode preservar preferências de formatação. Ela também cria um canal de entrada duradouro que pode influenciar decisões futuras.

O estudo sobre envenenamento de memória da Zenity afirma que a função roubada poderia descobrir identificadores de memória por meio dos logs do CloudWatch. Ela poderia então listar atores, sessões e estratégias de memória configuradas.

Os pesquisadores usaram CreateEvent para adicionar conteúdo hostil às conversas de outros agentes. A extração de memória processou esses eventos e converteu seu conteúdo em registros de longo prazo. Sessões futuras poderiam recuperar esses registros como contexto confiável.

Portanto, um atacante não precisaria repetir a injeção de prompt original em cada interação. Uma instrução implantada poderia sobreviver além da sessão comprometida e afetar conversas posteriores. A interface visível ainda pareceria ser o agente oficial da organização.

A Zenity descreve isso como comando e controle persistente. Essa expressão deve ser entendida como a caracterização dos pesquisadores sobre seu ambiente de teste. O resultado comportamental exato depende da configuração de memória, da lógica de recuperação, do comportamento do modelo, das ferramentas e dos controles de autorização.

A primitiva demonstrada ainda é grave. Uma preferência falsa poderia instruir um agente a enviar dados para um endereço controlado pelo atacante. Um fato fabricado poderia redirecionar um fluxo de trabalho, enquanto um resumo envenenado poderia deturpar a aprovação anterior de um cliente.

A manipulação do histórico de curto prazo acrescenta riscos imediatos. Um evento de assistente inserido pode parecer ao modelo algo que ele decidiu anteriormente. Um resultado de ferramenta excluído pode remover evidências que, de outra forma, impediriam uma ação insegura.

A segurança tradicional de aplicações muitas vezes trata logs e histórico como evidências após um incidente. Sistemas de agentes podem alimentar ativamente o histórico armazenado de volta para decisões futuras. Falhas de integridade nesses dados podem, portanto, alterar a execução, e não apenas dificultar a investigação.

A memória também complica a recuperação. A rotação de credenciais roubadas interrompe o acesso contínuo à API, mas não remove automaticamente todos os registros envenenados. As equipes de resposta precisam identificar quais sessões, eventos, resumos e memórias extraídas foram tocados pela identidade comprometida.

A atual orientação sobre memória da AWS recomenda validação de entrada, guardrails antes da persistência e testes regulares de injeção de prompt. Ela também enfatiza políticas de privilégio mínimo para recursos de memória.

Esses controles devem ser combinados com proveniência. Um registro de longo prazo deve reter metadados suficientes para mostrar qual usuário, agente, sessão e processo de extração o criou. As equipes de segurança precisam de uma maneira eficiente de colocar em quarentena memórias associadas a uma identidade comprometida.

Ações de alto risco não devem depender do contexto recuperado como prova de autorização. Um agente pode se lembrar de que um usuário prefere uma determinada conta bancária, mas uma transferência ainda exige aprovação atual e verificada de forma independente. A memória pode orientar um fluxo de trabalho sem autorizá-lo.

As organizações também devem separar os tipos de dados por consequência. Preferências sobre estilo de escrita apresentam menos risco do que instruções de pagamento, concessões de acesso ou endereços de destino. Memórias sensíveis precisam de regras de criação mais rígidas, retenção mais curta e revisão mais forte.

O monitoramento deve cobrir gravações e leituras. Picos incomuns de CreateEvent, acesso à memória entre agentes ou alterações que afetem muitos atores podem sinalizar abuso. CloudTrail, logs da aplicação e dados de observabilidade do AgentCore devem alimentar alertas vinculados ao comportamento esperado da carga de trabalho.

É aqui que o incidente vai além da AWS. Qualquer plataforma de agentes que combine memória persistente com ferramentas enfrenta um problema de integridade semelhante. Os detalhes de implementação diferem, mas a questão de confiança permanece constante.

Que informação o agente pode lembrar, quem pode gravá-la e de quais decisões ela pode depender mais tarde? AgentCorruption mostra que respostas incompletas podem transformar um ponto de apoio temporário em influência contínua.

O Que os Clientes do AgentCore Devem Verificar Agora

A cadeia histórica completa foi limitada antes da publicação, mas permissões definidas pelo cliente e configurações mais antigas determinam a exposição restante de cada implantação.

A primeira verificação é a função de execução vinculada a cada runtime do AgentCore. As equipes devem listar as ações e recursos permitidos e, em seguida, remover permissões não relacionadas à função documentada do runtime. Curingas merecem justificativa específica, e não aceitação rotineira.

Funções de produção não devem herdar políticas geradas para protótipos. A AWS agora classifica permissões geradas pela CLI como conveniências de desenvolvimento e aconselha os clientes a criar alternativas com escopo restrito. Uma implantação de teste bem-sucedida não é evidência de que sua função pertença à produção.

A segunda verificação é a aplicação do MMDSv2. Os runtimes atuais devem definir requireMMDSV2 como true em sua configuração de metadados. As equipes devem verificar a configuração implantada em vez de presumir que uma atualização de plataforma corrigiu adequadamente todos os runtimes históricos.

O MMDSv2 ainda deve ser tratado como uma camada. Se um agente controla legitimamente um cliente HTTP flexível, shell ou interpretador de código, ele pode realizar solicitações que proteções simplistas contra SSRF pressupunham que atacantes não conseguiriam construir. A política de rede deve bloquear o acesso desnecessário a endpoints de metadados.

A terceira verificação é a acessibilidade de entrada. As equipes devem identificar quais runtimes aceitam invocação direta pública, baseada em IAM ou JWT. Agentes públicos precisam das menores funções porque suas entradas vêm do público menos confiável.

Quando o AgentCore Gateway fornece aplicação de políticas, a invocação direta do runtime deve ser restrita. Caso contrário, um atacante pode contornar os guardrails do gateway e chamar o endpoint do runtime por outro caminho autorizado. A autenticação e os identificadores de usuário devem derivar de entidades principais verificadas.

A quarta verificação abrange a movimentação lateral. Um runtime não deve invocar agentes não relacionados, listar grupos de logs regionais, extrair imagens ECR não relacionadas ou enumerar recursos de memória. Essas permissões devem ser isoladas por ARN de runtime e função de negócio.

A quinta verificação é a confidencialidade das conversas. As equipes de segurança devem testar se uma identidade de runtime consegue listar atores, sessões ou eventos pertencentes a outra carga de trabalho. Elas também devem verificar se políticas de recursos e políticas de identidade produzem em conjunto a negação pretendida.

A sexta verificação é a integridade da memória. As equipes devem inventariar as entidades principais com CreateEvent, DeleteEvent e acesso à memória de longo prazo. Os alertas devem distinguir gravações normais de sessões de usuários de alterações entre agentes ou em alto volume.

A sétima verificação diz respeito às credenciais armazenadas. O AgentCore Identity pode manter tokens de terceiros fora do código da aplicação, mas o IAM ainda controla quem pode recuperá-los. Funções de runtime não devem ter acesso amplo a chaves de API ou valores do Secrets Manager.

Investigadores que analisam uma possível exposição histórica precisam de mais do que retratos das políticas atuais. Eles devem examinar eventos do CloudTrail, logs de invocação em tempo de execução, atividades relacionadas a metadados, pulls de imagens do ECR, chamadas à API de memória e acessos ao Secrets Manager durante o período relevante.

Credenciais temporárias expiram, mas seus efeitos podem persistir. Um invasor pode copiar código-fonte, reter um segredo obtido, modificar o histórico de sessões ou inserir memória de longo prazo antes da expiração. Os planos de resposta devem incluir rotação de credenciais e validação de estado.

Duas incertezas permanecem centrais. As descobertas da Zenity vêm de implantações controladas por pesquisadores, e nenhuma evidência pública citada aqui estabelece exploração generalizada em ambientes de clientes. A AWS não publicou um boletim de segurança específico que descreva a cadeia completa do AgentCorruption.

Essa ausência deve impedir alegações exageradas, não desconsiderar a pesquisa. A Zenity publicou exemplos detalhados de permissões, caminhos de exploração e datas de divulgação. A documentação atualizada da AWS confirma de forma independente que o código em tempo de execução pode acessar credenciais de metadados e que políticas amplas de desenvolvimento não são adequadas para produção.

O primeiro sinal a observar é se a AWS emitirá um aviso formal, uma análise retrospectiva ou orientações adicionais para migração de políticas. Essa documentação esclareceria as configurações afetadas e se os clientes precisam corrigir manualmente funções mais antigas.

O segundo sinal é uma restrição adicional ao acesso a metadados por ferramentas controladas por agentes. Um controle que impeça workloads em tempo de execução de alcançar endpoints de credenciais reduziria a dependência do comportamento do modelo. Uma política granular de saída também poderia conter outros caminhos de SSRF.

O terceiro sinal é a proteção de memória visível para os clientes. Melhor procedência, autorização de escrita com escopo definido, alertas de integridade e ferramentas de quarentena em massa tornariam o envenenamento de memória mais fácil de detectar e reverter. Essas capacidades são importantes à medida que a memória de longo prazo passa a integrar fluxos de trabalho críticos para os negócios.

O AgentCorruption da Zenity, em última análise, testa uma afirmação mais ampla por trás dos agentes empresariais. A infraestrutura gerenciada pode reduzir a complexidade operacional, mas não pode fundir com segurança identidade, memória e acesso a ferramentas em uma única função amplamente confiável.

Agora, os desenvolvedores devem fazer uma pergunta concreta sobre cada agente implantado: o que acontece depois que o modelo segue a pior instrução que pode receber? Rastreie as chamadas de ferramentas resultantes, credenciais, permissões, agentes acessíveis e memórias graváveis.

Se a resposta for além da tarefa restrita desse agente, trate o escopo como uma falha de segurança ativa. Revise a função, isole runtimes públicos, teste os limites da memória e confirme diretamente as configurações padrão atuais da AWS. O agente mais seguro não é aquele que sempre rejeita manipulação. É aquele cujas permissões de nuvem impedem que uma resposta manipulada se transforme em um incidente que afete toda a conta.