La mayoría de los agentes autónomos en producción hoy en día envían PII en bruto directamente a servidores de herramientas MCP de terceros — nombres, correos electrónicos, números de la seguridad social, datos de pago — sin ninguna tokenización y sin ningún registro de auditoría. La solución no es un memorando de políticas. Es una capa de interceptación que se sitúa entre el agente y cada herramienta externa, tokenizando los datos antes de que salgan de tu perímetro y registrando cada contacto en un libro de auditoría inmutable. Así es como VeriSwarm Guard lo gestiona.
La protección de PII para agentes de IA es la práctica de evitar que la información de identificación personal se filtre a través de la ruta de datos que recorre un agente — entrada del prompt, contexto del LLM, llamadas a herramientas MCP, servicios de terceros y respuestas salientes — sin dejar de permitir que las herramientas realicen un trabajo útil con esos datos. Es un superconjunto de la redacción de la entrada del LLM: el punto de fuga que más perjudica en producción no es el LLM, es la llamada a la herramienta después de que el LLM decide realizarla.
Un flujo de trabajo típico de un agente: un usuario proporciona su nombre, correo electrónico, teléfono y una tarjeta de crédito. El LLM lo procesa. El agente entonces llama a una herramienta — una API de calendario, un CRM, un procesador de pagos — y reenvía esos datos en texto plano a través de MCP. La especificación de MCP no lleva de forma inherente contexto de usuario; el servidor de la herramienta no puede diferenciar usuarios ni aplicar controles por usuario. Cada categoría de datos — PII, credenciales, datos financieros — puede reenviarse externamente en un único flujo de trabajo a velocidad de máquina, por defecto.
Para conocer la mecánica paso a paso para cerrar esa brecha, consulta cómo prevenir una fuga de datos de un agente de IA.
Las cifras de 2026 no son halagüeñas:
La prevención de pérdida de datos (DLP) se construyó para un mundo en el que los humanos copiaban archivos y enviaban correos electrónicos. Las llamadas a herramientas de los agentes rompen todas las premisas en las que se basa el DLP:
Un agente puede realizar cientos de llamadas a herramientas por minuto. La inspección DLP tradicional no puede seguir el ritmo sin convertirse en un cuello de botella que anula el propósito de la automatización.
Las políticas de DLP clasifican los datos en reposo o en tránsito a través de canales conocidos. Las llamadas a herramientas MCP son dinámicas, programáticas y pasan por endpoints que el equipo de seguridad puede no saber que existen.
La coincidencia de patrones detecta formatos conocidos (números de tarjeta, números de la seguridad social) pero se le escapa la PII que depende del contexto, como afecciones médicas o identificadores repartidos entre varios tokens. Ahí es donde hace falta el NER sobre datos estructurados.
La arquitectura que funciona es una capa de interceptación en tiempo de ejecución entre el agente y sus herramientas. Guard Proxy se sitúa en esa posición. Presidio (el motor NER de código abierto de Microsoft) detecta y tokeniza categorías de PII — nombres, correos electrónicos, números de teléfono, números de la seguridad social, tarjetas de crédito, direcciones IP y números de identificación financiera o gubernamental (cuentas bancarias, permisos de conducir, pasaportes) — antes de que la llamada a la herramienta salga del perímetro. El servidor de la herramienta ve [PERSON_1] en lugar de «Jane Smith». El LLM razona sobre el token. El valor original solo se restaura en la respuesta final al usuario autorizado. No es un escaneo posterior; es una transformación en línea.
El pipeline de transformadores ejecuta cuatro transformadores integrados en un orden fijo — primero la tokenización de PII, luego la inyección de contexto, el enmascaramiento de campos y la validación de esquema. El desglose completo de lo que hace cada uno, qué lo activa y cómo añadir transformadores personalizados está en Los cuatro transformadores de Guard Proxy: qué intercepta cada uno, en orden.
Tres modos de despliegue (alojado en la nube, Docker on-prem, stdio local) cubren toda la gama, desde «apunta tu agente a una URL» hasta «los datos nunca salen de tu VPC».
La tokenización es seudonimización, no anonimización. Según el artículo 4(5) del RGPD, los datos seudonimizados siguen siendo datos personales — el token más la tabla de correspondencia todavía pueden reidentificar al individuo, y varios campos tokenizados pueden combinarse para revelar la identidad incluso sin la tabla de correspondencia. Eso significa que una carga útil tokenizada por Guard sigue estando dentro del ámbito del RGPD; simplemente cambia los controles exigidos.
En la práctica, la tokenización reduce el radio de impacto de una exposición y demuestra los controles de «estado del arte» exigidos por el artículo 32 — pero no elimina los derechos del interesado, las obligaciones de notificación de brechas ni los requisitos de registro de actividades de tratamiento. Un proveedor que afirme que la tokenización hace que la PII «ya no sea un dato personal» está equivocado o está vendiendo algo. Nosotros no.
Cada interceptación de PII queda registrada en el libro de auditoría encadenado por hash de Vault — qué se envió, qué se tokenizó, qué se devolvió, cuándo, con qué identidad de agente y contra qué herramienta. Cuando un auditor pregunta «¿adónde fueron los datos de este cliente?», la respuesta es una línea temporal verificable criptográficamente, no una captura de pantalla de una herramienta de monitorización. La verificación de la cadena detecta manipulaciones; las exportaciones se corresponden directamente con los requisitos de registro de actividades de tratamiento del artículo 30 del RGPD.
El manual de procedimiento para el día en que falle la verificación de la cadena — el endpoint, la forma de la respuesta, los pasos de investigación — está en Verificar una cadena de Vault: un manual para el día en que se rompe la integridad.
El sector sanitario es el caso de uso más exigente para la protección de PII en el límite entre el agente y la herramienta. El historial de aplicación de la OCR de 2025 muestra que los hallazgos de análisis de riesgos dominan los acuerdos en una proporción de 3:1, con multas medias de alrededor de 291.000 $, más obligaciones de supervisión de 2 años. La tokenización de Guard, el libro de auditoría de Vault y el bucle de puntuación a nivel de agente se combinan en una postura que resiste esa auditoría — integrada en la superficie vertical de sanidad con configuraciones predeterminadas alineadas con la HIPAA activadas de forma predeterminada.
Tokens. Guard Proxy tokeniza la PII en el límite de interceptación — nombres, correos electrónicos, números de teléfono, números de la seguridad social, tarjetas de crédito, direcciones IP, números de identificación financiera y gubernamental (cuentas bancarias, permisos de conducir, pasaportes) — y el LLM razona sobre el token. Los servidores de herramientas reciben el token. El valor original solo se restaura en la respuesta final al usuario autorizado; nada aguas abajo ve texto en claro.
El mapa vive dentro del despliegue de Guard Proxy del tenant y nunca se envía por la red junto con la carga útil tokenizada. En modo alojado en la nube, está protegido por cifrado específico del tenant; en modo Docker on-prem, nunca sale de tu red. El formato del token solo es reversible con esa clave, de modo que una llamada a herramienta interceptada filtra el token, no el valor que hay detrás.
Es uno de los controles. La tokenización en el límite de la llamada a la herramienta mantiene la PHI fuera del contexto del LLM, fuera de los servidores de herramientas MCP que no controlas, y la lleva al libro de auditoría encadenado por hash de Vault para que el registro del flujo de datos sobreviva a una auditoría. La postura completa de cumplimiento de la HIPAA también necesita BAA con los servidores de herramientas posteriores, manifiestos firmados en los propios agentes (Passport) y procesos operativos en torno a la respuesta ante brechas. La tokenización en tiempo de ejecución cierra la mayor brecha técnica; el resto es papeleo y operaciones.
La redacción destruye el valor (irreversible) — bien para telemetría y registros, inútil cuando la herramienta necesita el dato para funcionar. El enmascaramiento oculta parcialmente (los últimos 4 dígitos de una tarjeta) — bueno para superficies legibles por humanos. El bloqueo impide la llamada por completo — adecuado para infracciones de política graves. La tokenización preserva la utilidad a la vez que elimina el secreto — la única de las cuatro en la que el servidor de la herramienta puede seguir haciendo un trabajo útil sin ver el valor original. Guard admite las cuatro; la elección es por categoría de dato y por política.
Sí — esa es su superficie principal. Guard Proxy es una capa de interceptación de MCP transparente con tres modos de despliegue (alojado en la nube, Docker on-prem, stdio local). El cliente MCP de tu agente apunta a Guard Proxy en lugar de directamente al servidor de la herramienta; Guard Proxy reenvía la llamada sin la PII y devuelve la respuesta. Sin cambios en el código del agente.
Sí — la misma maquinaria de tokenización cubre ambos casos. Además de los datos personales, el detector reconoce formatos de credenciales — tokens de GitHub, claves de OpenAI, claves de AWS, tokens de Slack, claves de GCP, claves de Stripe, JWT y bloques de clave privada — y los tokeniza de la misma manera que tokeniza un nombre o un número de la seguridad social. Una clave de API filtrada camino de una llamada a herramienta se intercepta antes de que salga de tu perímetro, no solo un número de la seguridad social filtrado.
Los tokens caducan tras un TTL configurable — una hora por defecto — y están limitados a un tenant y una sesión concretos, de modo que un token creado para una conversación no puede reproducirse en otra. Los valores originales se cifran en reposo (cifrado simétrico Fernet), y cada rehidratación de vuelta a texto en claro queda registrada para auditoría. Un token que se filtra por sí solo es inútil sin la clave de cifrado y una sesión activa y limitada.
Recorre toda la estructura. El tokenizador de Guard recorre de forma recursiva cada diccionario y lista en los argumentos de una llamada a herramienta — y en el cuerpo de la respuesta — de modo que la PII enterrada en `data.customer.email` o dentro de una lista de registros se tokeniza igual que un campo de nivel superior. Una versión anterior solo inspeccionaba el nivel superior, lo que dejaba pasar sin redactar la PII anidada en las formas típicas de las cargas útiles MCP; esa brecha se cerró como una corrección crítica.
Guard Proxy no requiere ningún cambio en el código de tu agente. Apunta tu cliente MCP a Guard Proxy en lugar de al servidor de la herramienta; Guard Proxy reenvía la llamada sin la PII y devuelve la respuesta. El nivel gratuito de Gate te da visibilidad sobre el inventario y el flujo de eventos primero — para que puedas ver el problema antes de activar la solución.