O Envenenamento da Memória de AI Agents Precisa de Defesas em Todo o Ciclo de Vida

O envenenamento da memória de AI agents transforma uma entrada não confiável em estado durável. Quando um agent grava conteúdo controlado por um atacante na memória persistente, esse conteúdo pode retornar dias ou sessões depois como contexto aparentemente confiável. Defenda todo o ciclo de vida: controle cada gravação, associe proveniência e expiração, isole registros por usuário e agent, faça uma nova triagem na recuperação, mantenha a autorização de ações fora do modelo e preserve um registro de influência que permita rollback.

Sumário

O que é envenenamento da memória de AI agents?

O envenenamento da memória de AI agents é a inserção ou modificação de registros persistentes para que uma recuperação posterior altere a resposta, a decisão ou o uso de ferramentas de um agent. A entrada original pode já ter desaparecido quando o efeito surge. Essa diferença de tempo torna o ataque mais difícil de perceber e reconstruir do que uma prompt injection visível na conversa atual.

A memória pode existir em vários lugares:

A tecnologia de armazenamento não é o fator definidor. Persistência combinada com influência posterior cria o limite de segurança.

Isso difere de três riscos próximos. Prompt injection manipula o contexto atual do modelo, embora possa se tornar o canal de entrega para uma memória envenenada. O envenenamento de dados de treinamento altera o comportamento do modelo por meio do corpus de treinamento. O envenenamento de retrieval tem como alvo o conteúdo selecionado para uma solicitação. O envenenamento da memória de agents persiste um registro que o sistema pode posteriormente tratar como parte do histórico, das preferências ou do estado operacional do usuário.

Três padrões de ataque são relevantes na prática:

A orientação atual da Microsoft descreve a mesma preocupação estrutural em termos defensivos: a memória persistente armazena dados sensíveis e também influencia o comportamento do modelo e a seleção de ferramentas. Portanto, deve ser governada tanto como sistema de dados quanto como control plane. Microsoft Learn

O que três estudos recentes mediram

Três preprints de julho de 2026 examinaram partes diferentes dessa ameaça. Lidos em conjunto, eles mostram por que um único filtro de memória é um critério fraco para release.

GhostWriter testou injeção agora e ativação depois

When Agents Remember Too Much apresentou o GhostWriter, um ataque em duas etapas contra agents pessoais que usam ferramentas. Primeiro, um adversário coloca conteúdo oculto em uma fonte não confiável. O agent processa essa fonte e grava uma memória influenciada pelo atacante. Uma tarefa posterior recupera o registro e ativa seu efeito.

Entre os agents e modelos testados no artigo, o GhostWriter alcançou uma taxa média de injeção de aproximadamente 98% e uma taxa média de ativação de aproximadamente 60%. Os autores também testaram o AM-Sentry, que combina uma política mais rigorosa para salvar memórias com uma triagem na recuperação. O artigo avalia tanto o sucesso do ataque quanto a utilidade da tarefa em sua semana de trabalho simulada personalizada; os resultados da defesa variam conforme o modelo e a configuração.

Os limites são importantes. O trabalho abrange cinco agents, quatro famílias de modelos e fluxos de trabalho de email ou calendário. Seu teste de utilidade é personalizado, os atacantes não são adaptativos e os resultados não estimam a frequência com que agents implantados são atacados.

MemPoison separou falhas diretas, composicionais e dormentes

MemPoison reuniu 1.227 casos validados manualmente em quatro tipos de ataque, três canais de injeção e três substratos de memória. A avaliação incluiu sete famílias de modelos open-weight e três famílias de modelos closed-weight.

A contribuição útil do artigo é sua taxonomia de três níveis. L1 é a corrupção direta de um único registro. L2 torna-se prejudicial quando vários registros são recuperados em conjunto. L3 permanece dormente até que um contexto posterior o ative. Os autores relatam que as defesas básicas no momento da gravação suprimem ataques diretos com mais confiabilidade do que casos L2 ou L3. A análise mecanística de influência dos autores atribui a diferença a registros que parecem benignos quando armazenados, mas se tornam prejudiciais sob composição ou diante de um gatilho.

Isso não prova que todo filtro de gravação em produção falhará. O benchmark abrange três substratos de memória representativos e canais padrão baseados em texto. Os autores defendem pesquisas mais amplas sobre decaimento, sumarização, controles de acesso e outros ecossistemas de memória.

MemGhost testou um caminho de entrega de email em uma única etapa

When Claws Remember but Do Not Tell apresentou o WhisperBench, um benchmark com 108 casos usando um fluxo de trabalho real de IMAP/SMTP e uma skill de email-agent. Seu framework de ataque, MemGhost, gera um payload de email sem feedback em tempo de execução. Para obter sucesso, o agent precisa adotar a memória envenenada, evitar alertar o usuário em sua resposta imediata e alterar seu comportamento posterior.

Em 56 casos reservados para teste, o artigo relata 87,5% de sucesso ponta a ponta no OpenClaw com GPT-5.4 e 71,4% no Claude Code SDK com Sonnet 4.6.

Esses números pertencem ao benchmark, ao ambiente proxy, ao design de recompensa e às versões de modelo dos autores. A avaliação começa depois que uma mensagem chega à caixa de entrada. Ela não modela controles do provedor de email, como filtragem de spam, SPF, DKIM ou DMARC. O artigo é um preprint de primeira versão, portanto seus resultados precisam ser replicados.

Por que a filtragem no momento da gravação não é suficiente

Um gate de gravação vê o registro proposto e as evidências disponíveis naquele momento. Ele pode não ver a tarefa futura, os outros registros que serão recuperados junto com ele ou a ferramenta que o agent chamará posteriormente.

Isso cria quatro pontos cegos:

As verificações no momento da gravação ainda são importantes. Elas reduzem a quantidade de estado inseguro que chega à persistência. O erro é tratar a aprovação do armazenamento como confiança permanente.

A recuperação deve retornar contexto candidato, não autoridade. Antes de inserir um registro no contexto do modelo, o sistema pode verificar sua fonte, idade, relevância para a tarefa, contradições, sensibilidade e efeito solicitado. Um registro de alto risco pode ser omitido, resumido ou encaminhado para revisão. A orientação atual da Microsoft recomenda essa separação entre gravação e recuperação, além de isolamento determinístico e visibilidade de todo o ciclo de vida. Microsoft Learn

Uma arquitetura segura para a memória de agents

O sistema precisa de uma cadeia rastreável da fonte à ação:

`source → write decision → stored version → retrieval decision → model context → policy decision → tool result`

*Legenda: Um registro de memória se torna contexto candidato somente após as verificações de gravação e recuperação. A política independente ainda autoriza cada ação consequencial, enquanto a cadeia de influência permite investigação e rollback.*

1. Exija intenção explícita para gravações duráveis

Não permita que toda mensagem, documento ou resposta de ferramenta se torne memória de longo prazo. Defina quais eventos podem criar estado durável. Preferências confirmadas pelo usuário e ações explícitas de “lembrar isto” são mais fáceis de justificar do que um resumo autônomo de um anexo não confiável.

Registre quem ou o que solicitou a gravação. Se uma ferramenta ou subagent a iniciou, preserve essa identidade em vez de reduzir tudo ao nome do usuário final.

2. Armazene proveniência, escopo e expiração com o registro

Um registro de memória útil precisa de mais do que texto e um embedding. Armazene pelo menos:

Uma assinatura pode proteger a integridade do registro. Ela não pode provar que o conteúdo original era verdadeiro, seguro ou autorizado.

3. Aplique isolamento no código e no armazenamento

Os limites de tenant, usuário, agent e workspace pertencem a listas de controle de acesso, tokens com escopo, políticas em nível de linha e limites de criptografia. Instruções em prompts não são controle de acesso. A memória compartilhada deve ser um recurso explícito do produto, com escritores e leitores nomeados, não um namespace padrão conveniente.

4. Coloque gravações de baixa confiança em quarentena

Crie um estado entre “descartado” e “memória confiável”. Arquivos externos, email, páginas da web, saídas indiretas de ferramentas e registros com intenção pouco clara podem entrar em quarentena. Eles não devem aparecer na recuperação normal até que uma regra determinística ou um revisor autorizado os promova.

A quarentena também oferece aos responsáveis pela resposta a incidentes um local para preservar evidências sem continuar a influência.

5. Reavalie os registros no momento da recuperação

O risco da recuperação depende da tarefa atual. Avalie o conjunto selecionado, não apenas cada registro:

6. Mantenha a autorização de ferramentas independente

A memória pode fornecer parâmetros. Ela nunca deve ampliar permissões. O gateway de ferramentas deve aplicar a identidade atual, a ação permitida, o limite de recursos, o destino, o orçamento e os requisitos de aprovação. Trate argumentos derivados da memória como entradas não confiáveis e valide-os segundo a política atual.

A aprovação humana também precisa de contexto atualizado. Mostre a ação proposta, o recurso afetado, o destino dos dados e as memórias que a influenciaram. Um “Aprovar?” sem essa cadeia oculta a decisão relevante.

7. Registre a influência e ofereça rollback

Registre operações de criação, leitura, atualização e exclusão de memória com identidade e proveniência. Para ações consequenciais, retenha os IDs e as versões dos registros inseridos no contexto. Isso permite responder a três perguntas de incidentes:

A exclusão deve remover a influência ativa, não apenas ocultar uma linha na interface do usuário. Teste índices, resumos, caches, réplicas e registros derivados. A orientação da OWASP para agents recomenda memória validada e isolada, além de testes adversariais e evidências de release; sua análise mais ampla de memória associa prompt injection persistente à superfície de ameaça da memória de agents. OWASP Agent Security Cheat Sheet OWASP GenAI Security Project

Escolha uma política para cada classe de memória

Uma única política de retenção é abrangente demais. Comece com classes que tenham regras diferentes de gravação e recuperação.

Esta tabela é um ponto de partida para a política, não uma afirmação de compliance. Um agente médico, assistente de programação, agente de vendas e assistente pessoal têm modelos de dano diferentes. O invariante é mais restrito: a persistência não deve converter silenciosamente conteúdo não confiável em permissão.

Um fluxo de trabalho reproduzível para testar envenenamento de memória

Construa o harness de testes em torno de marcadores benignos e contas descartáveis. Você não precisa de credenciais reais ou payloads de exfiltração para detectar falhas de persistência e de política.

Etapa 1: Capture uma baseline limpa

Execute um conjunto fixo de tarefas com um armazenamento de memória vazio. Registre respostas, resultados de recuperação, propostas de ferramentas, decisões de política, latência e explicações visíveis ao usuário. Repita o suficiente para separar mudanças no sistema da variação normal do modelo.

Etapa 2: Defina casos limpos e envenenados em pares

Para cada caso, mantenha a tarefa do usuário constante e altere apenas o caminho potencial da memória. Cubra pelo menos:

Use uma ação canário, como gravar `TEST_BLOCKED` em um log descartável. O teste falha se o agent executar ou propuser essa ação fora do caminho de política esperado.

Etapa 3: Observe cada limite

Capture quatro resultados separados:

Um sucesso ponta a ponta pode ocultar uma camada fraca. Por exemplo, a autorização pode bloquear a ação canário mesmo que um registro envenenado tenha sido armazenado e recuperado repetidamente. Isso é uma contenção útil, mas o defeito da memória ainda precisa ser corrigido.

Etapa 4: Meça utilidade e falsos positivos

Execute casos de memória benignos pelo mesmo pipeline. Acompanhe conclusão de tarefas, preferências de usuário aceitas, quarentenas incorretas, precisão da recuperação, latência e volume de revisões. Um filtro que bloqueia toda memória durável tem baixo sucesso de ataque porque removeu o recurso.

Etapa 5: Defina gates de release por risco

Gates úteis incluem:

O projeto open-source Agent Memory Guard da OWASP é um sinal de implementação para ferramentas de varredura e teste de memória. Seu repositório e sua avaliação autorrelatada podem ajudar as equipes a inspecionar padrões, mas não substituem testes do agent, modelo, backend de memória e stack de políticas reais.

Execute novamente o conjunto após mudanças na extração de memória, sumarização, embeddings, recuperação, prompts, modelos, schemas de ferramentas, autorização ou lógica de exclusão. Essas camadas interagem.

O que as evidências sustentam e o que não sustentam

Os artigos mediram o sucesso de ataques dentro de benchmarks construídos. Eles não mediram a taxa populacional de envenenamento da memória de AI agents em produção.

Eles sustentam três conclusões mais restritas:

Os artigos inferem que a governança da memória precisa de defesas sensíveis ao contexto. Microsoft e OWASP recomendam independentemente defesa em profundidade em gravações, isolamento, recuperação, controle do usuário, observabilidade e testes.

A interpretação prática é tornar cada transição testável. Uma equipe deve conseguir explicar por que um registro foi armazenado, por que foi recuperado, como influenciou uma ação, qual política autorizou essa ação e como remover os efeitos posteriores do registro.

Perguntas frequentes das equipes

O envenenamento da memória de AI agents é a mesma coisa que prompt injection?

Não. Prompt injection é uma forma de introduzir instruções hostis. O envenenamento de memória acrescenta persistência: o conteúdo manipulado é armazenado, recuperado em um contexto posterior e pode influenciar raciocínios ou uso de ferramentas futuros depois que a entrada original desapareceu.

Registros de memória assinados podem impedir o envenenamento?

Não. Assinaturas podem provar que um registro não foi alterado após sua criação. Elas não provam que o conteúdo original era verdadeiro, seguro ou autorizado. Um design seguro também precisa de proveniência, intenção explícita de gravação, escopo, expiração, verificações de recuperação e autorização independente de ações.

As defesas contra envenenamento de memória devem ser executadas no momento da gravação ou da recuperação?

Em ambos. Gates de gravação reduzem a persistência insegura. As verificações de recuperação detectam riscos obsoletos, contraditórios, composicionais ou dependentes de gatilho que não eram visíveis quando os registros individuais foram armazenados. Nenhuma camada deve poder conceder autoridade sobre ferramentas.

Verificações de afirmações

Fontes