Como desenhar memória para agentes sem comprometer segurança

Memória de agente parece, à primeira vista, um problema resolvido: guardar dado, recuperar depois. A arquitetura que o Google descreve para o ADK (Agent Development Kit) e o ataque de memory-poisoning documentado pelo paper The Containment Gap mostram que não é bem assim - memória mal desenhada é, ao mesmo tempo, ponto de falha técnica e vetor de ataque.

Memória de sessão: o scratchpad que não sobrevive à conversa

O ADK trata memória de curto prazo como algo que existe só dentro de uma sessão - a analogia usada é uma ligação telefônica com um atendente: ele lembra do que você disse na mesma ligação, mas não de ligações anteriores. Tecnicamente, isso é gerenciado pelo SessionService, com cada sessão carregando um Session ID, User ID, histórico de eventos, e um "state" - uma lista de pares chave-valor que funciona como bloco de notas do agente durante aquela sessão específica.

Memória persistente e de usuário: sobrevivendo entre sessões

Memória de longo prazo é diferente: persiste entre sessões do mesmo usuário, como um atendente que lembra "todas as conversas passadas". O ADK oferece dois prefixos mágicos para controlar esse escopo diretamente no state: user: persiste entre todas as sessões daquele usuário específico; app: persiste entre todas as sessões de todos os usuários. Sem prefixo, o dado morre com a sessão. Essa é a diferença entre memória de sessão, de usuário e de projeto (aplicação) - não três sistemas separados, mas três escopos de persistência do mesmo mecanismo.

Regras de gravação e o risco de escrever demais

O Google recomenda um serviço de memória que não guarda a conversa inteira, mas extrai apenas as informações-chave - o Memory Bank do Vertex AI usa o próprio Gemini para extrair memórias essenciais e as indexa via busca vetorial, em vez de armazenar tudo. Isso importa para segurança: quanto mais dado bruto fica retido, maior a superfície de vazamento e maior o espaço para um ataque de poisoning se esconder.

O risco que a arquitetura sozinha não resolve: memory poisoning

O paper The Containment Gap testou um agente de benefícios governamentais construído em LangChain e encontrou que um ataque de memory-poisoning elevou a taxa de negação indevida para 88,9%, chegando a multiplicar negações indevidas por 3,5 vezes sob uma política mais complexa - mantendo a precisão agregada intacta, ou seja, invisível para monitoramento padrão. Nenhuma arquitetura de armazenamento, por si só, impede isso: é preciso validação de integridade da memória como camada separada, não incluída por padrão em frameworks populares.

Validação, auditoria, expiração e revogação

Validar integridade de memória significa checar se o dado que está sendo lido não foi corrompido ou injetado depois da gravação original - os autores do Containment Gap propõem um validador dedicado para isso, com menos de 0,2ms de overhead por chamada. Regras de expiração evitam que memória desatualizada continue influenciando decisões indefinidamente. Auditoria significa poder reconstruir quando e por que uma memória específica foi gravada. Revogação é a capacidade de apagar memória de um usuário específico sob demanda - obrigatório sob praticamente qualquer regulação de privacidade.

Testes de integridade como parte do pipeline

Assim como qualquer outro componente crítico, o sistema de memória precisa de testes que simulem ativamente tentativas de poisoning - não apenas testes de que a memória "funciona", mas testes de que ela resiste a manipulação deliberada.

Checklist de dez pontos

1. Memória de sessão - escopo mais curto, sem prefixo
2. Memória persistente - sobrevive entre sessões
3. Memória de usuário - prefixo user:, escopada por indivíduo
4. Memória de projeto - prefixo app:, compartilhada entre usuários
5. Regras de gravação - extrair essencial, não guardar tudo
6. Regras de expiração - memória desatualizada não deveria durar para sempre
7. Validação de memória - checagem de integridade antes de confiar no dado lido
8. Auditoria - rastreabilidade de quando e por que algo foi gravado
9. Revogação - apagar memória de um usuário sob demanda
10. Testes de integridade - simular ataques de poisoning ativamente

Fontes

• Google Cloud - Remember this: Agent state and memory with ADK - https://cloud.google.com/blog/topics/developers-practitioners/remember-this-agent-state-and-memory-with-adk
• Arxiv - The Containment Gap - https://arxiv.org/abs/2606.12797