Um guia prático para defender a memória do seu agente contra ataques.

De injeção de prompt, envenenamento e exfiltração silenciosa.
Pressione enter ou clique para ver a imagem em tamanho real

por VEKTOR Memory | 10 min de leitura

No último artigo, analisamos o cenário de ameaças do lado de fora. Pesquisamos a taxonomia de ataques e a lacuna de governança. As dez superfícies que tornam a IA agente uma verdadeira nova questão de privacidade.

Este artigo vai um nível mais profundo. Não é sobre qual é o problema, mas o que você pode realmente fazer sobre isso em código, na arquitetura e na prática.

Especificamente: como é realmente uma camada de segurança para a memória do agente, e o que aprendemos ao construir uma.

A maioria dos escritos sobre segurança de IA agente permanece na camada de descrição do problema. Aqui estão os ataques. Aqui está o motivo pelo qual eles funcionam. Aqui está qual porcentagem de modelos é vulnerável.

Isso é útil, mas deixa uma lacuna. Se você é alguém que está construindo com agentes ou pensando seriamente em implantá-los, a pergunta que você realmente quer respondida é: o que eu implemento e em que ordem?

O artigo "DeepMind AI Agent Traps" identifica seis categorias de ataque. A que mais importa para sistemas de memória é a corrupção de memória persistente, onde um atacante planta dados na memória de longo prazo que se ativam como maliciosos quando recuperados em um contexto futuro. As taxas de sucesso demonstradas na pesquisa excedem 80% com menos de 0,1% de envenenamento de dados.

Esse número vale a pena refletir. Você não precisa corromper a maior parte da memória. Você precisa corromper quase nada dela.

A implicação para qualquer um que esteja construindo um agente com memória é direta: seu armazenamento de memória é uma superfície de ataque, e provavelmente é a que você menos pensou.

Interface Faraday — simulando um vetor de ataque canário

A abordagem clássica para a segurança de agentes é a sanitização de entrada. Remover o prompt. Validar o esquema. Recusar padrões suspeitos. Isso funciona para pipelines simples, mas falha para sistemas agentes que operam através de várias ferramentas e sessões por um motivo: o ataque não chega na camada de entrada.

Ele chega através de uma página da web que seu agente visitou três sessões atrás. Através de um anexo de e-mail que foi resumido e armazenado. Através de uma descrição de ferramenta de um servidor que você não escreveu e que mudou desde que você se conectou hoje.

A ameaça chega através do ambiente, não do prompt.

Um proxy que fica entre seu agente e tudo que ele toca é a resposta arquitetônica correta para isso. Nossa solução cria um ponto de estrangulamento seguro onde cada interação pode ser observada, registrada e avaliada antes de chegar à memória.

Esse é o problema que o Faraday foi projetado para resolver.

O Faraday é inicializado como parte do servidor VEKTOR MCP. Quando ele inicia, lê seu claude_desktop_config.json e gera todos os outros servidores MCP listados lá como um processo filho. Suas outras ferramentas, sistemas de arquivos, bancos de dados, APIs, todos eles passam pelo Faraday antes que qualquer coisa chegue à memória VEKTOR.

Esse é o padrão de proxy transparente. Da perspectiva do Claude, nada muda. As mesmas ferramentas estão disponíveis. As mesmas chamadas funcionam. Mas cada esquema de ferramenta, cada chamada de ferramenta e cada resposta passa por um conjunto de verificações antes de ser executada ou escrita na memória.

Existem quatro camadas.

L0: Verificação estática no momento da conexão. Quando o Faraday gera um servidor e recupera sua lista de ferramentas, ele verifica cada nome de ferramenta, descrição e esquema de entrada contra uma biblioteca de assinaturas antes de confiar em qualquer coisa. Isso captura padrões inativos, assinaturas de injeção conhecidas e qualquer coisa marcada como CRÍTICA ou ALTA severidade. Uma ferramenta bloqueada não é registrada. O agente nunca a vê.

Fase C: Fixação de ferramentas. O hash SHA-256 do esquema de cada ferramenta é armazenado na primeira conexão. Cada conexão subsequente recomputa o hash. Se mudou, isso é um rug-pull: as definições de ferramentas do servidor foram mutadas desde a última vez que você se conectou. O Faraday registra a interceptação, bloqueia a ferramenta e gera um alerta. Essa é a defesa contra ataques à cadeia de suprimentos onde um servidor MCP de terceiros do qual você depende é comprometido entre sessões.

Tokens canário. No início da sessão, o Faraday injeta tokens canário na memória através do faraday-canary.js. Esses são fatos sintéticos com assinaturas específicas e rastreáveis. Se um valor canário aparecer em uma chamada de API de saída, uma tentativa de exfiltração está em andamento. A detecção não depende de entender a intenção do atacante. Depende do token aparecer onde não deveria.

Propagação de contaminação. O faraday-taint.js rastreia rótulos através do gráfico de memória. Se uma memória é marcada como contaminada porque veio de uma fonte suspeita, qualquer memória derivada dela herda esse rótulo de contaminação. Isso não é infalível, mas reduz o raio de explosão de um evento de envenenamento tornando a contaminação rastreável.

Cada interceptação, evento de portão e limite de sessão é registrado em um banco de dados SQLite persistente via faraday-db.js. A trilha de auditoria existe independentemente de qualquer log que Claude ou a estrutura do agente registre.

Um dos padrões que surgiram ao construir isso foi que algumas classes de ameaça não são binárias. Você não pode bloqueá-las completamente porque fazê-lo também bloquearia comportamentos legítimos. Você só pode segurá-las.

A fila de portão é o mecanismo para isso. Quando o Faraday detecta uma ação de alto risco, ele não executa nem bloqueia. Ele coloca a ação em uma fila com um gate_id e espera. Três novas ferramentas MCP lidam com isso:

faraday_status retorna o estado atual da sessão, incluindo qualquer coisa que esteja na fila de portão. Você pode ver o que está retido, por que foi retido e quais dados estavam envolvidos.

faraday_update_goal permite que você declare a intenção da sessão atual. O Faraday usa isso para detecção de desvio semântico. Se o objetivo declarado é "resumir minhas notas de vendas do Q2" e uma chamada de ferramenta tenta ler seu arquivo de e-mails, essa divergência é sinalizada.

faraday_approve_action leva um gate_id e um booleano. Aprove e a ação prossegue. Negue e é registrado como bloqueado.

Esse é o padrão humano-no-loop implementado na camada de memória em vez da camada de aplicação. Você não precisa reconstruir seu fluxo de trabalho para adicioná-lo. Ele funciona abaixo das ferramentas que você já está usando.

A segurança não é a única coisa que se desintegra quando você passa de uma chamada LLM simples para uma sessão de agente de múltiplos passos. A seleção de modelo também se desintegra.

Em uma interação de turno único, você escolhe um modelo uma vez e ele lida com tudo. Em uma sessão colaborativa com um condutor planejando um DAG, trabalhadores executando etapas e um verificador avaliando resultados, usar o mesmo modelo para cada função é caro e muitas vezes a escolha errada.

O papel do condutor precisa de suporte a saída estruturada e capacidade de raciocínio suficiente para planejar um gráfico de tarefas coerente. O papel do trabalhador precisa de throughput. O verificador precisa retornar um JSON limpo de aprovação/reprovação rapidamente.