Você Não Consegue Detectar Uma Memória Envenenada. Consegue Hashear o Arquivo Dela.

TV
Thiago Victorino
6 min de leitura
Você Não Consegue Detectar Uma Memória Envenenada. Consegue Hashear o Arquivo Dela.

“There remains no way to have an agent distinguish ‘good prompt’ from ‘evil prompt’.” A frase é de Cal Paterson, no texto de agosto de 2026 em que ele descreve um formato de arquivo para memória de agente chamado Memoryfields. É a frase mais útil que li sobre segurança de memória de agente neste ano, e é uma concessão.

Toda defesa em tempo de execução para memória de agente pressupõe um classificador que não existe. Depois que uma anotação armazenada entra na janela de contexto, ela tem o mesmo peso da instrução que o usuário digitou. A conclusão de Paterson segue disso: “You must not share your context window, including via memories, with parties you don’t trust.” A resposta dele é um formato de arquivo.

O Que o Formato É

Um .memoryfield.zip guarda páginas em Markdown, cada uma com frontmatter YAML opcional, mais um índice vetorial em SQLite também opcional. O artefato é isso. A especificação está em github.com/calpaterson/memoryfield-spec, junto de uma CLI (memoryfield-tool) e de uma skill de agente (memoryfield-skill).

Cada página tem um limite flexível de cerca de 8kb, algo em torno de 2000 tokens. Paterson traduz o número para quem não pensa em tokens no dia a dia: “8,000 characters is about 1,300 words, or the length of a medium-length magazine article.” A unidade de memória tem o tamanho de um artigo de revista, o que significa que também é uma página que um revisor consegue ler dentro de um diff.

O lado da recuperação é deliberadamente sem graça. O modelo de embedding é o nomic-embed-text-v1.5, que Paterson descreve como “small enough (270MB)” e “over 2 years old”. A afirmação embutida nessa escolha é que a recuperação de memória nunca esteve limitada pela qualidade do embedding. Um modelo de 270MB com mais de dois anos encontra a página certa.

Uma ressalva antes de seguir. Trata-se da proposta de um desenvolvedor, publicada no site dele. Falta órgão de padronização por trás, falta adoção para apontar, e nada aqui deve ser lido como formato emergente de indústria. O que torna o caso interessante é que existe um artefato concreto no lugar de mais um princípio.

O Argumento de Performance e Seu Limite

O caso de Paterson contra memória em grafo é sobre ida e volta. Grafos de conhecimento obrigam o agente a caminhar por arestas, e cada salto é uma chamada de ferramenta, “each of which takes maybe 2-3 seconds”. A formulação dele: “If the relevant information is N steps deep in the knowledge graph, N+1 tool calls are required.” Contra um corpus plano e pesquisável, “at most 2 tool calls are required (#1 to search, #2 to read in parallel).”

Trate esses números como argumento, e não como medição. Paterson deixa de fora metodologia de benchmark, sistema de comparação e conjunto de dados. Os 2 a 3 segundos são a caracterização dele da latência de chamada de ferramenta em travessia de grafo, e o N+1 é uma afirmação estrutural sobre como a travessia funciona, não uma cronometragem que alguém reproduziu. Até lá, isto é uma posição bem fundamentada de um engenheiro.

A parte estrutural é a que sobrevive de qualquer forma. Dependência sequencial entre etapas de recuperação é uma propriedade real da travessia de grafo. O terceiro salto só começa depois que o segundo retorna. Custando 2 segundos ou 200 milissegundos por salto, o formato da curva de custo continua o mesmo.

Por Que o Argumento de Governança Pesa Mais

Paterson cita Fred Brooks: “Show me your flowcharts and conceal your tables, and I shall continue to be mystified. Show me your tables, and I won’t usually need your flowcharts; they’ll be obvious.” Ele usa a citação para defender dados acima de estrutura. Ela vale igualmente bem para auditabilidade.

Um sistema de memória cujo estado vive dentro de um vector store gerenciado responde quase nenhuma pergunta de governança de forma direta. O que o agente sabia na terça passada? O que mudou entre a execução que funcionou e a que falhou? Qual página carregava a instrução que causou o incidente? Na prática, cada uma dessas tende a virar um chamado para o fornecedor, ou uma consulta contra um armazenamento que nunca foi desenhado para responder perguntas históricas.

Um zip estático responde a todas elas com ferramentas que qualquer organização de engenharia já opera. Dá para comparar duas versões. Dá para versionar uma página no controle de versão. Dá para calcular um sha256 do arquivo entregue ao agente, registrar esse hash ao lado da execução e depois provar quais bytes estavam na janela de contexto. Nada no formato torna esse pinning obrigatório, e a especificação não descreve ferramenta que entregue isso pronto. É um controle que o formato do artefato disponibiliza para quem quiser construí-lo, que é exatamente o que um formato de arquivo deveria fazer.

Essa distinção muda como avaliar a ideia. Memoryfields não protege contra envenenamento de memória. O próprio Paterson diz isso. O que um arquivo estático e hasheável entrega é a capacidade de responder, depois do incidente, o que o agente estava efetivamente carregando. A detecção continua impossível. A atribuição fica barata.

Onde Isso Encosta no Que Já Argumentamos

Já mapeamos os três padrões em que a memória de agente sempre desemboca e quais deles sobrevivem ao contato com produção. Já defendemos que conhecimento vence a prontidão para agentes ao virar formato em vez de plataforma. Já argumentamos que memória é o fosso que você não consegue levar entre harnesses.

Os três textos eram argumentos de princípio, feitos sem nenhuma especificação publicada para apontar. Memoryfields é o primeiro artefato que vimos codificando o princípio em um layout de arquivo: um zip, páginas em Markdown, um índice opcional e um repositório de spec que qualquer pessoa lê em uma tarde. Pode não dar em nada. O desenho ainda assim mostra como fica a versão portátil disso quando alguém para de argumentar e escreve o esquema.

Faça Isto Agora

Pegue um agente que você opera em produção e responda uma pergunta só: se esse agente agiu sobre uma memória que jamais deveria ter recebido, você consegue provar qual memória era?

Na prática, três verificações. Você consegue exportar o estado completo de memória do agente para um arquivo agora, sem abrir chamado com fornecedor? Consegue calcular um hash desse estado e guardá-lo junto do registro da execução? Se duas execuções com o mesmo prompt divergirem, consegue comparar a memória entre elas?

Se alguma resposta for não, você opera agentes cujo conhecimento fica sem atribuição depois do fato. A posição é pior do que a maioria dos times imagina, porque a falha é silenciosa até um incidente forçar a pergunta. A correção é barata: exija que qualquer sistema de memória que você adote consiga te entregar um arquivo.


Fontes

A Victorino ajuda organizações de engenharia a tornar memória de agente exportável, hasheável e auditável antes que um incidente force a pergunta: contato@victorino.com.br | www.victorino.com.br

Todos os artigos do The Thinking Wire são escritos com o auxílio do modelo LLM Opus da Anthropic. Cada publicação passa por pesquisa multi-agente para verificar fatos e identificar contradições, seguida de revisão e aprovação humana antes da publicação. Se você encontrar alguma informação imprecisa ou deseja entrar em contato com o editorial, escreva para editorial@victorino.com.br . Sobre o The Thinking Wire →

Se isso faz sentido, vamos conversar

Ajudamos empresas a implementar IA sem perder o controle.

Agendar uma Conversa