Skip to content
VeriSwarm
Sobre
DocumentaçãoPreçosHabilidade do agente
EntrarCadastrar
  1. Início
  2. /Learn
  3. /Prevent ai agent data leak
VeriSwarm
  • English
  • Español
  • Deutsch
  • Français
  • Italiano
  • ✓ Português
  • 日本語
  • 한국어
  • 简体中文

Produto

  • Preços
  • Documentação
  • API
  • Habilidade do agente
  • Especificação OATS

Confiança

  • Central de confiança
  • Segurança
  • Conformidade
  • Status
  • Changelog

Empresa

  • Sobre
  • Blog
  • Código aberto
  • Investidores
  • Imprensa

Jurídico

  • Termos
  • Privacidade
  • SLA
  • DPA
  • Acessibilidade
Proteção de Dados em Tempo de Execução

Como impedir que um agente de IA vaze dados

Os agentes vazam dados de três formas: pelos argumentos que encaminham em uma chamada de ferramenta, pelo que escrevem na memória da conversa e pelo que ecoam de volta em uma resposta. Um memorando de política não impede nenhuma das três — todas parecem o agente simplesmente fazendo seu trabalho. O que as impede é uma camada de tokenização em tempo de execução que intercepta o texto em cada um desses três pontos e remove o PII antes que ele cruze sua fronteira. É assim que essa camada funciona.

Os três vetores de vazamento

Redigir o que entra no prompt do LLM é o mínimo esperado e não fecha a brecha. O caminho de dados de um agente tem três pontos onde um valor bruto pode sair do perímetro, e nenhum deles passa pelo prompt.

Argumentos da chamada de ferramenta

O agente decide chamar uma ferramenta — uma API de calendário, um CRM, um processador de pagamentos — e encaminha os dados sobre os quais está raciocinando como argumento da chamada. O MCP não carrega metadados de sensibilidade por campo, então o servidor da ferramenta recebe, por padrão, o que quer que o agente envie, em texto puro.

O que ele escreve na memória

O histórico da conversa persiste entre os turnos para que o agente tenha contexto. Qualquer texto anexado a esse histórico — incluindo o CPF de um cliente ou um detalhe médico que surja no meio da conversa — permanece lá em texto puro durante toda a sessão, a menos que algo o tokenize antes que o anexo aconteça.

O que ele ecoa de volta

A resposta final devolvida ao solicitante é construída a partir do contexto que o agente recuperou e sobre o qual raciocinou. Se a tokenização só ocorrer na entrada, um valor que entrou como token ainda pode reaparecer sem tokenização na resposta de saída.

O argumento mais profundo sobre por que a chamada de ferramenta — e não o prompt — é onde a maioria dos vazamentos em produção realmente acontece está em Seu agente de IA está vazando PII por meio de chamadas de ferramentas. Aqui está a prova.

A solução: uma única primitiva de tokenização, aplicada a cada vetor

O VeriSwarm Guard fecha os três vetores com a mesma chamada subjacente — POST /v1/suite/guard/pii/tokenize — aplicada no ponto em que cada vetor vazaria dados. O texto passa por um mecanismo de detecção NER baseado no Presidio (Presidio + spaCy NER, além de reconhecedores de regex personalizados para identificadores que o Presidio não cobre de fábrica) e volta com cada trecho de PII substituído por um token tipado — [VS:EMAIL:a1b2c3], [VS:SSN:f9e2d1], e assim por diante. O agente, o servidor da ferramenta e qualquer coisa registrada no meio do caminho veem o token. O valor original é restaurado, quando realmente necessário, por meio de uma chamada separada a POST /v1/suite/guard/pii/rehydrate, restrita à sessão que criou os tokens.

Vetor 1 — fechado pelo Guard Proxy

O Guard Proxy é uma camada de interceptação MCP transparente. Aponte o cliente MCP do seu agente para o proxy em vez de diretamente para o servidor da ferramenta, e ele tokeniza o PII tanto na solicitação de saída da chamada de ferramenta quanto na resposta de entrada — sem nenhuma mudança no código do agente. Três modos de implantação: hospedado na nuvem, Docker on-prem, stdio local.

Vetores 2 e 3 — fechados no runtime do agente

O próprio runtime de agentes da VeriSwarm chama o endpoint de tokenização na resposta do agente antes que essa resposta seja anexada ao histórico da conversa e antes que ela seja devolvida ao solicitante. O valor gravado na memória e o valor ecoado de volta são o mesmo texto tokenizado — não dois controles separados que podem ficar dessincronizados.

Como isso difere de Proteção de PII para Agentes de IA

O pilar de proteção de PII cobre o caso mais amplo a favor da tokenização em vez da redação da entrada do prompt — por que o DLP não cobre o tráfego de agentes, a ressalva de pseudonimização do GDPR, a trilha de auditoria do Vault, a postura para o setor de saúde. Esta página é mais restrita e mais operacional: é um mapa dos três pontos específicos no caminho de dados de um agente onde um vazamento realmente acontece, e qual mecanismo fecha cada um deles. Leia o pilar para a arquitetura completa e o raciocínio de conformidade; leia esta página para saber, especificamente, onde direcionar a correção.

O que isso não cobre

A tokenização reduz a superfície de PII nos três vetores acima e fornece uma trilha de auditoria de cada interceptação quando o Vault está habilitado — ela não garante que nenhum dado jamais vaze. Uma chamada de ferramenta desviada do Guard Proxy, ou uma integração personalizada que não chama o endpoint de tokenização antes de encaminhar os dados, é um caminho de vazamento que essa camada nunca vê. O Guard fecha os vetores nos quais está conectado; conectar um novo é responsabilidade sua na primeira vez que você criar um caminho de vazamento que ele ainda não cobre. A injeção é um risco relacionado, mas distinto — uma entrada elaborada que manipula qual ferramenta é chamada, em vez de PII nos argumentos de uma chamada legítima — tratada separadamente em Detecção de Injeção de Prompt para Agentes de IA.

Perguntas frequentes

Quais são as três formas pelas quais um agente de IA vaza dados?

Pelos argumentos da chamada de ferramenta — um agente encaminha PII bruta em texto puro para um servidor de ferramentas MCP (uma API de calendário, um CRM, um processador de pagamentos). Pelo que ele escreve na memória — o CPF de um cliente ou um detalhe médico é anexado ao histórico da conversa e permanece lá durante toda a sessão. Pelo que ele ecoa de volta — uma resposta construída a partir de contexto tokenizado ainda pode expor o valor original se a etapa de tokenização for pulada na saída. As três compartilham uma propriedade: nenhuma delas parece uma violação de política. Parecem o agente simplesmente fazendo seu trabalho.

Não basta tokenizar o prompt enviado ao LLM?

Não — isso interrompe apenas o ponto de vazamento que causa menos dano. O LLM nunca ver o PII é uma boa prática, mas a chamada de ferramenta que o LLM decide fazer em seguida é onde os dados realmente saem do seu perímetro. Um agente pode ser escrupulosamente cuidadoso com o que coloca em um prompt e, ainda assim, encaminhar o número de telefone de um cliente literalmente para um servidor de ferramentas MCP de terceiros, porque a especificação do MCP não carrega inerentemente metadados de sensibilidade de dados por campo. A cobertura precisa se estender até a chamada de ferramenta, não parar na fronteira do modelo.

Como a VeriSwarm tokeniza o PII antes que ele saia da fronteira?

O texto é passado para POST /v1/suite/guard/pii/tokenize, que o processa por meio de um mecanismo de detecção NER baseado no Presidio (Presidio + spaCy NER, além de reconhecedores de regex personalizados para identificadores que o Presidio não cobre) e retorna o texto com cada trecho de PII substituído por um token tipado — [VS:EMAIL:a1b2c3], [VS:SSN:f9e2d1], e assim por diante. O mapa de token para valor é restrito ao tenant e nunca trafega junto com o payload tokenizado. Os tokens só são reversíveis por meio de POST /v1/suite/guard/pii/rehydrate, restrito à sessão que os criou, para o caso específico em que um sistema downstream precisa do valor real para fazer seu trabalho — gravar em um registro de CRM, por exemplo.

Isso exige reescrever o código do agente?

Para o vetor de chamada de ferramenta, não. O Guard Proxy é uma camada de interceptação MCP transparente — o cliente MCP do seu agente aponta para a URL do proxy em vez de diretamente para o servidor da ferramenta, e ele tokeniza o PII tanto na chamada de ferramenta de saída quanto na resposta de entrada antes que qualquer uma delas cruze a fronteira. Três modos de implantação cobrem hospedado na nuvem, Docker on-prem e stdio local. Para os vetores de memória e eco, o próprio runtime de agentes da VeriSwarm já chama o endpoint de tokenização antes de anexar uma resposta ao histórico da conversa ou devolvê-la ao solicitante — essa infraestrutura já vem pronta como parte da plataforma, não é algo que você precise construir.

Em qual plano isso está disponível?

O Guard — tokenização de PII, Guard Proxy e a varredura de injeção que roda junto com ele — é um recurso do plano Max. O Gate, o trust scoring do plano gratuito da VeriSwarm, oferece visibilidade sobre o comportamento do agente e o fluxo de eventos antes de você precisar da camada de tokenização; é no Guard que você ativa a aplicação.

A tokenização garante que nenhum dado jamais vazará?

Não, e é preciso encarar com ceticismo qualquer fornecedor que afirme o contrário. A tokenização reduz a superfície de PII em cada um dos três vetores cobertos aqui e fornece uma trilha de auditoria de cada interceptação quando o Vault está habilitado. Ela não cobre caminhos de vazamento fora desses três — uma integração malconfigurada que contorna o Guard Proxy, ou um caminho de chamada de ferramenta personalizado que não passa pela etapa de tokenização, ainda precisa ser conectado deliberadamente.

Feche os três vetores de uma vez

A tokenização de PII do Guard é um recurso do plano Max; o plano gratuito do Gate oferece o trust scoring e a visibilidade de eventos para você ver para onde os dados de um agente realmente vão antes de ativar a correção.

Experimente a demoComece grátis