Um atacante conversa com seu LLM agent. Algumas mensagens depois, o agent grava uma memória falsa. Quando um usuário legítimo faz uma pergunta relacionada, o agent recupera a memória envenenada e executa a ação do atacante. Taxa de sucesso: até 95%. E piora: essa memória hijacka o control flow do agent — forçando tool selection, reordenando workflows, expandindo escopo entre tasks. Mais de 90% dos trials são vulneráveis. Memória de longo prazo em LLM agents é uma superfície de ataque, e as defesas atuais são insuficientes.
MemPoison — envenenamento que bypassa filtros
LLM agents com memória de longo prazo seguem um pipeline: extraem informações relevantes, reescrevem para compactar, armazenam e recuperam por similaridade de embedding. Pesquisas anteriores assumiam que um atacante escreveria diretamente no banco de memória. Na prática, selective extraction filtra conteúdo de baixa saliência. Memórias ingênuas são descartadas.
O MemPoison resolve isso com três técnicas. Semantic Relational Bridge liga trigger e payload em uma declaração coerente — o pipeline não separa sem perder contexto. Entity Masquerading otimiza a trigger para parecer uma named entity; LLMs preservam named entities verbatim na reescrita, então a trigger sobrevive. Joint Embedding Optimization empacota os textos envenenados em um cluster tight no embedding space, isolados dos benignos. O retrieval puxa a memória envenenada.
O resultado: ASR de até 0.95 entre diferentes domínios e mecanismos de memória. Perplexity filtering não detecta — os textos são semanticamente coerentes. Paraphrasing não remove — entity masquerading preserva a trigger após reescrita. O MemPoison funciona contra os próprios mecanismos que deveriam filtrar.
O detalhe técnico que importa: o MemPoison explora anisotropia no embedding space e redistribui attention patterns. O cluster envenenado cria uma região de alta densidade que atrai queries relacionadas, desviando o retrieval de memórias legítimas. Isso é uma vulnerabilidade estrutural — qualquer sistema de memória baseado em embedding similarity é potencialmente vulnerável.
MCFA — quando a memória hijacka o control flow
Memory Control Flow Attacks vão além de poluir o RAG. A memória recuperada hijacka o control flow do agent — tool selection e execução. O atacante não precisa de acesso ao system prompt, tools ou memory store. Basta interação padrão.
O framework MEMFLOW documentou os números. Tool Override: 91.7% a 100%. A memória força o agent a selecionar tools que não deveria. Com retrieval desligado, o override cai para 0% — a derivação é causada pela memória. Workflow Reordering: 52.8% a 69.4%. A memória reordena tool invocations, pulando steps de segurança. Cross-Task Scope Expansion: 97.2% a 100%. Uma injeção em uma task generaliza para templates diferentes, propagando entre domínios. Persistência: 100% em horizontes longos. Correções textuais post-hoc falham em 100% dos casos — o agent recai no comportamento malicioso na próxima recuperação.
Testado em GPT-5 mini, Claude Sonnet 4.5 e Gemini 2.5 Flash, nos frameworks LangChain e LlamaIndex. Todos vulneráveis. A vulnerabilidade está no design de memória, não na implementação.
Por que as defesas atuais falham
System prompts não protegem. Quando o retrieval está ativo, a memória override as instruções de segurança. O dado é claro: tool override chega a 100% com retrieval ON e cai para 0% com retrieval OFF. A memória é mais forte que a instrução.
Selective extraction filtra ruído, não payloads coerentes. O MemPoison demonstrou que declarações semanticamente coerentes atravessam o pipeline intactas. Filtrar por saliência pressupõe que conteúdo malicioso tem baixa saliência — não é o caso.
Correções textuais não funcionam. O MCFA mostrou que o agent recai na próxima recuperação. A memória é um backdoor durável — corrigir a instrução não remove a memória envenenada.
Mesmo mitigações production-style como dual-channel memory com role-based segregation mostram 85%+ de control flow deviations. Reduz, não elimina. A arquitetura de memória compartilhada entre tasks é o problema fundamental.
O cenário de maior risco: multi-tenant agents
Agents que atendem múltiplos usuários com o mesmo memory store são o cenário mais crítico. Um atacante envenena a memória em uma interação. Todos os usuários subsequentes são afetados. O MemPoison explora isso diretamente: o cluster envenenado no embedding space atrai queries de qualquer usuário que faça perguntas relacionadas.
O risco é multiplicado pela persistência. A memória envenenada não expira. Em horizontes longos, o MCFA documenta 100% de persistência. Cada recuperação reativa o comportamento malicioso. Não há decay natural.
O que verificamos na Tech86
Avaliamos arquiteturas de AI agents com foco em superfícies de ataque de memória e retrieval. Se seus agents usam memória persistente sem isolamento entre usuários, você está a uma conversa de um ataque com 95% de sucesso. Se usam memória com retrieval e tools de alto risco, mais de 90% dos cenários são vulneráveis a control flow hijacking.
O primeiro passo é mapear: quais agents usam memória persistente, qual mecanismo de retrieval, se o memory store é compartilhado. Depois isolar, monitorar e testar adversarialmente. Sem teste adversarial, você não sabe se suas mitigações funcionam — ou se apenas reduzem o problema para 85% de desvios em vez de 100%.