A maioria dos agentes autônomos em produção hoje envia PII bruta diretamente para servidores de ferramentas MCP de terceiros — nomes, e-mails, CPFs, dados de pagamento — sem qualquer tokenização e sem qualquer trilha de auditoria. A solução não é um memorando de política. É uma camada de interceptação que fica entre o agente e cada ferramenta externa, tokenizando os dados antes que saiam do seu perímetro e registrando cada interação em um ledger imutável. É assim que VeriSwarm Guard lida com isso.
A proteção de PII para agentes de IA é a prática de impedir que informações de identificação pessoal vazem pelo caminho de dados que um agente percorre — entrada do prompt, contexto do LLM, chamadas de ferramentas MCP, serviços de terceiros e respostas de saída — mantendo, ao mesmo tempo, a capacidade das ferramentas de realizar um trabalho útil com os dados. É um superconjunto da redação de entrada do LLM: o ponto de vazamento que mais prejudica em produção não é o LLM, é a chamada de ferramenta depois que o LLM decide fazê-la.
Um fluxo de trabalho típico de agente: um usuário fornece nome, e-mail, telefone e um cartão de crédito. O LLM os processa. O agente então chama uma ferramenta — uma API de calendário, um CRM, um processador de pagamentos — e encaminha esses dados em texto simples via MCP. A especificação do MCP não carrega contexto de usuário de forma inerente; o servidor da ferramenta não consegue diferenciar usuários nem aplicar controles por usuário. Cada categoria de dado — PII, credenciais, dados financeiros — pode ser encaminhada externamente em um único fluxo de trabalho na velocidade da máquina, por padrão.
Para a mecânica passo a passo de como fechar essa brecha, veja como prevenir um vazamento de dados de um agente de IA.
Os números de 2026 não são nada lisonjeiros:
A prevenção contra perda de dados (DLP) foi construída para um mundo em que humanos copiavam arquivos e enviavam e-mails. As chamadas de ferramentas dos agentes quebram todas as premissas em que o DLP se baseia:
Um agente pode fazer centenas de chamadas de ferramentas por minuto. A inspeção DLP tradicional não consegue acompanhar sem se tornar um gargalo que anula o propósito da automação.
As políticas de DLP classificam dados em repouso ou em trânsito por meio de canais conhecidos. As chamadas de ferramentas MCP são dinâmicas, programáticas e passam por endpoints que a equipe de segurança pode não saber que existem.
A correspondência de padrões detecta formatos conhecidos (números de cartão, CPFs), mas deixa passar PII dependente de contexto, como condições médicas ou identificadores divididos entre vários tokens. É aí que entra a necessidade de NER sobre dados estruturados.
A arquitetura que funciona é uma camada de interceptação em tempo de execução entre o agente e suas ferramentas. O Guard Proxy fica nessa posição. O Presidio (o mecanismo NER de código aberto da Microsoft) detecta e tokeniza categorias de PII — nomes, e-mails, números de telefone, CPFs, cartões de crédito, endereços IP e números de identificação financeira ou governamental (contas bancárias, carteiras de motorista, passaportes) — antes que a chamada de ferramenta saia do perímetro. O servidor da ferramenta vê [PERSON_1] em vez de “Jane Smith”. O LLM raciocina sobre o token. O valor original só é restaurado na resposta final ao usuário autorizado. Não é uma varredura posterior; é uma transformação em linha.
O pipeline de transformadores executa quatro transformadores integrados em uma ordem fixa — primeiro a tokenização de PII, depois a injeção de contexto, o mascaramento de campos e a validação de esquema. O detalhamento completo do que cada um faz, o que o aciona e como adicionar transformadores personalizados está em Os quatro transformadores do Guard Proxy: o que cada um intercepta, em ordem.
Três modos de implantação (hospedado na nuvem, Docker on-prem, stdio local) cobrem toda a gama, desde “aponte seu agente para uma URL” até “os dados nunca saem da sua VPC”.
Tokenização é pseudonimização, não anonimização. Segundo o Artigo 4(5) do GDPR, dados pseudonimizados continuam sendo dados pessoais — o token somado à tabela de correspondência ainda pode reidentificar o indivíduo, e vários campos tokenizados podem ser combinados para revelar a identidade mesmo sem a tabela de correspondência. Isso significa que um payload tokenizado pelo Guard continua dentro do escopo do GDPR; apenas desloca os controles exigidos.
Na prática, a tokenização reduz o raio de impacto de uma exposição e demonstra os controles de “estado da arte” exigidos pelo Artigo 32 — mas não elimina os direitos do titular dos dados, as obrigações de notificação de violação ou os requisitos de registro de operações de tratamento. Um fornecedor que afirma que a tokenização torna o PII “não mais dados pessoais” está enganado ou está vendendo algo. Nós não.
Cada interceptação de PII é registrada no ledger encadeado por hash do Vault — o que foi enviado, o que foi tokenizado, o que foi devolvido, quando, por qual identidade de agente, contra qual ferramenta. Quando um auditor pergunta “para onde foram os dados desse cliente?”, a resposta é uma linha do tempo verificável criptograficamente, não uma captura de tela de uma ferramenta de monitoramento. A verificação de cadeia detecta adulterações; as exportações mapeiam diretamente para os requisitos de registro de operações de tratamento do Artigo 30 do GDPR.
O manual de procedimentos para o dia em que a verificação de cadeia falhar — o endpoint, o formato da resposta, os passos de investigação — está em Verificando uma Cadeia do Vault: um manual para o dia em que a integridade se rompe.
A saúde é o caso de uso mais exigente para a proteção de PII na fronteira entre agente e ferramenta. O histórico de aplicação da OCR de 2025 mostra que os achados de Risk Analysis dominam os acordos em uma proporção de 3:1, com multas médias em torno de US$ 291.000, além de obrigações de monitoramento de 2 anos. A tokenização do Guard, o ledger do Vault e o ciclo de pontuação em nível de agente se combinam em uma postura que resiste a essa auditoria — integrada à superfície vertical de saúde com padrões alinhados à HIPAA ativados por padrão.
Tokens. O Guard Proxy tokeniza PII na fronteira de interceptação — nomes, e-mails, números de telefone, CPFs, cartões de crédito, endereços IP, números de identificação financeira e governamental (contas bancárias, carteiras de motorista, passaportes) — e o LLM raciocina sobre o token. Os servidores de ferramentas recebem o token. O valor original só é restaurado na resposta final ao usuário autorizado; nada a jusante vê texto simples.
O mapa vive dentro da implantação do Guard Proxy do tenant e nunca é enviado pela rede junto com o payload tokenizado. No modo hospedado na nuvem, fica protegido por criptografia específica do tenant; no modo Docker on-prem, nunca sai da sua rede. O formato do token só é reversível com essa chave, então uma chamada de ferramenta interceptada vaza o token, não o valor por trás dele.
É um dos controles. A tokenização na fronteira da chamada de ferramenta mantém o PHI fora do contexto do LLM, fora dos servidores de ferramentas MCP que você não controla, e o leva para o ledger encadeado por hash do Vault, para que o registro do fluxo de dados sobreviva a uma auditoria. A postura completa de HIPAA também exige BAAs com os servidores de ferramentas a jusante, manifestos assinados nos próprios agentes (Passport) e processos operacionais em torno da resposta a violações. A tokenização em tempo de execução fecha a maior lacuna técnica; o resto é burocracia e operação.
A redação destrói o valor (irreversível) — boa para telemetria e logs, inútil quando a ferramenta precisa do dado para funcionar. O mascaramento oculta parcialmente (últimos 4 dígitos de um cartão) — bom para superfícies legíveis por humanos. O bloqueio impede a chamada por completo — certo para violações graves de política. A tokenização preserva a utilidade ao remover o segredo — a única das quatro em que o servidor da ferramenta ainda consegue realizar um trabalho útil sem ver o valor original. O Guard oferece suporte às quatro; a escolha é feita por categoria de dado e por política.
Sim — essa é sua superfície principal. O Guard Proxy é uma camada de interceptação MCP transparente com três modos de implantação (hospedado na nuvem, Docker on-prem, stdio local). O cliente MCP do seu agente aponta para o Guard Proxy em vez do servidor da ferramenta diretamente; o Guard Proxy encaminha a chamada sem o PII e devolve a resposta. Nenhuma mudança no código do agente.
Sim — o mesmo mecanismo de tokenização cobre ambos. Além de dados pessoais, o detector reconhece formatos de credenciais — tokens do GitHub, chaves da OpenAI, chaves da AWS, tokens do Slack, chaves do GCP, chaves do Stripe, JWTs e blocos de chave privada — e os tokeniza da mesma forma que tokeniza um nome ou um CPF. Uma chave de API vazada a caminho de uma chamada de ferramenta é interceptada antes de sair do seu perímetro, não apenas um CPF vazado.
Os tokens expiram após um TTL configurável — uma hora por padrão — e são limitados a um tenant e uma sessão específicos, de modo que um token criado para uma conversa não pode ser reproduzido em outra. Os valores originais são criptografados em repouso (criptografia simétrica Fernet), e toda reidratação de volta ao texto simples é registrada para auditoria. Um token que vaza sozinho é inútil sem a chave de criptografia e uma sessão ativa e delimitada.
Ela percorre toda a estrutura. O tokenizador do Guard percorre recursivamente cada dict e lista nos argumentos de uma chamada de ferramenta — e no corpo da resposta — de modo que o PII escondido em `data.customer.email` ou dentro de uma lista de registros é tokenizado da mesma forma que um campo de nível superior. Uma versão anterior inspecionava apenas o nível superior, o que permitia que PII aninhado nos formatos típicos de payload MCP passasse sem redação; essa lacuna foi fechada como uma correção crítica.
O Guard Proxy não exige nenhuma mudança no código do seu agente. Aponte seu cliente MCP para o Guard Proxy em vez do servidor da ferramenta; o Guard Proxy encaminha a chamada sem o PII e devolve a resposta. O plano gratuito do Gate te dá visibilidade do inventário e do fluxo de eventos primeiro — para que você veja o problema antes de ativar a correção.