Resumen Técnico: PIIGuard

Declaración del Problema

Los Modelos de Lenguaje Grandes (LLM) modernos equipados con capacidades de navegación (mediante MCPs, llamadas a herramientas o interfaces web) crean un nuevo vector de ataque para la recolección de Información de Identificación Personal (PII). Los atacantes pueden enviar consultas de búsqueda de contactos a un asistente habilitado para la navegación, el cual luego recupera el HTML sin procesar de páginas web objetivo y reproduce la PII (nombres, números de teléfono, correos electrónicos, direcciones) de forma literal en su respuesta.

Las defensas existentes se despliegan principalmente en las capas de modelo, servicio o agente (por ejemplo, filtros de tiempo de ejecución, prompts enmascarados), lo que requiere acceso privilegiado que los propietarios ordinarios de páginas web no poseen. Las defensas a nivel de página que existen (por ejemplo, sustitución de caracteres o Inyección de Prompts Indirecta básica) a menudo fallan frente a ataques avanzados donde el atacante emplea un "sanitizador" LLM auxiliar para preprocesar y eliminar el contenido sospechoso del HTML recuperado antes de que el modelo objetivo lo procese. Este artículo aborda la brecha en las defensas a nivel de página web capaces de resistir tanto el acceso directo al HTML como la sanitización adversaria.

Metodología: PIIGuard

PIIGuard es un mecanismo de defensa a nivel de página web que incrusta fragmentos de HTML optimizados y ocultos (Inyecciones de Prompts Indirectas, o IPI) en el DOM de una página web. Estos fragmentos están diseñados para desviar al LLM de la divulgación literal o reconstruible de PII de contacto. El sistema opera mediante un pipeline evolutivo de cinco pasos:

1. Selección de Semillas: Inicializa un grupo de candidatos con instrucciones de defensa diversas y redactadas a mano, emparejadas con ranuras de inserción permitidas (por ejemplo, after, footer, meta, contact_block).
2. Puntuación Basada en Reglas: Evalúa los candidatos utilizando una métrica de fuga rápida y basada en reglas ($\ell_R$) que compara los campos extraídos con la verdad fundamental. En configuraciones de ataque avanzadas, esta puntuación agrega la fuga del peor caso a través de ambas rutas de HTML sin procesar y sanitizado.
3. Clasificación de Utilidad Compuesta: Los candidatos se clasifican no solo por la fuga media, sino por una función de utilidad compuesta ($U$) que prioriza:
   • Supresión completa (cero fuga en todos los campos).
   • Baja fuga promedio.
   • Robustez (fracción de páginas con fuga mínima).
4. Mutación Evolutiva: Un LLM objetivo actúa como mutador, reescribiendo el texto de las instrucciones, sustituyendo ranuras o hibridando padres de alto rendimiento para generar nuevos candidatos. Este bucle itera para minimizar la fuga basada en reglas.
5. Evaluación de Recuperabilidad Basada en Jueces: Los supervivientes finales se someten a una evaluación rigurosa utilizando un LLM "Juez". Este paso prueba la recuperabilidad semántica: incluso si la PII no está presente explícitamente, ¿puede el Juez reconstruir los identificadores originales a partir de la respuesta del modelo? Solo se seleccionan los fragmentos que cumplen tanto con los criterios basados en reglas como con los basados en jueces.

El marco admite dos configuraciones de ataque distintas:

• Ataque Básico: El modelo recupera el HTML sin procesar directamente.
• Ataque Avanzado: Un LLM sanitizador del lado del atacante preprocesa el HTML para eliminar las inyecciones sospechosas antes de que el modelo objetivo lo lea. PIIGuard co-optimiza los fragmentos para sobrevivir a esta sanitización.

Contribuciones Clave

1. Expansión del Modelo de Amenazas: El artículo es el primero en caracterizar sistemáticamente un escenario de ataque avanzado donde el atacante utiliza un sanitizador LLM para limpiar el HTML recuperado, un modelo de amenazas previamente no abordado por las defensas a nivel de página.
2. Marco PIIGuard: Una defensa novedosa a nivel de página web que utiliza un pipeline evolutivo de cinco pasos (selección de semillas, puntuación basada en reglas, clasificación compuesta, mutación LLM y reevaluación basada en jueces) para generar instrucciones ocultas optimizadas.
3. Protocolo de Evaluación de Dos Etapas: Un método de validación riguroso que combina la coincidencia rápida de campos basada en reglas con una evaluación de recuperabilidad semántica basada en jueces más lenta, para asegurar que las defensas prevengan tanto la exposición directa como la reconstrucción.
4. Validación Estrés-Probada: Evaluación en tres condiciones realistas:
   • HTML Directo: Entrada de HTML sin procesar al modelo.
   • Modo URL: Despliegue en el mundo real a través de sitios estáticos accedidos mediante interfaces de navegación estándar.
   • Modo Sanitizador: Preprocesamiento por un filtro LLM del lado del atacante.

Resultados Experimentales

El sistema se evaluó en tres modelos objetivo: GPT-5.4-nano, Claude-haiku-4.5 y DeepSeek-chat.

• Éxito de la Defensa: Bajo acceso directo al HTML, PIIGuard logró una Tasa de Éxito de Defensa (DSR) de al menos 97.0% (a menudo 100.0%) en todos los modelos y posiciones de inserción, tanto para métricas basadas en reglas como basadas en jueces.
• Utilidad Benigna: La defensa no degradó la capacidad del modelo para responder preguntas benignas (por ejemplo, tareas NewsQA), manteniéndose las métricas de utilidad (MAF1, BCR) comparables a las líneas base sin defensa.
• Robustez ante Sanitizadores: En la configuración de ataque avanzada, la robustez varió según la posición de inserción. La ranura footer_notice resultó ser la más estable, logrando hasta un 86.00% de DSR frente a varios prompts de sanitizador, mientras que contact_block y bio_tail mostraron una resiliencia menor.
• Despliegue en URL: Cuando se desplegó como sitios estáticos en vivo accedidos mediante herramientas de navegación, el rendimiento se mantuvo alto para la posición footer, pero se degradó significativamente para la posición meta, lo que indica que las cadenas de herramientas de navegación pueden eliminar estructuralmente ciertos sitios de inyección.
• Transferencia de Modelo: Los fragmentos optimizados para Claude-haiku-4.5 (un modelo altamente cumplidor de instrucciones) se generalizaron bien a otros modelos, lo que sugiere que las restricciones de optimización más estrictas generan defensas más robustas.

Significado y Afirmaciones

El artículo argumenta que los propietarios de páginas web pueden mitigar eficazmente la fuga de PII desplegando fragmentos de HTML ligeros y optimizados sin requerir cooperación de los proveedores de modelos.

• Cambio en el Paradigma de Defensa: PIIGuard demuestra que las defensas del lado de la página pueden ir más allá de la simple ofuscación (que falla frente a la reconstrucción semántica) hacia la dirección activa del comportamiento del modelo mediante Inyección de Prompts Indirecta.
• Capacidad del Modelo como Aliado: Contrario a la intuición de que los modelos más capaces son más difíciles de defender, los resultados sugieren que los modelos más capaces (por ejemplo, GPT-5.4-mini frente a GPT-5.4-nano) siguen las instrucciones inyectadas de manera más confiable, convirtiéndolos en defensores más fuertes cuando se despliega PIIGuard.
• Limitaciones y Trabajo Futuro: Los autores reconocen que la supervivencia ante sanitizadores es actualmente una "afirmación de existencia positiva" en lugar de una garantía universal, ya que el espacio de los prompts de sanitizador es abierto. También señalan que las evaluaciones actuales dependen de jueces de un solo modelo y sitios estáticos sintéticos, sugiriendo que el trabajo futuro debería explorar conjuntos de múltiples jueces y despliegues en el mundo real.

En general, PIIGuard posiciona los fragmentos del lado de la página como una capa de defensa práctica y de primera línea que complementa las salvaguardias a nivel de sistema, ofreciendo a los propietarios de contenido un mecanismo unilateral para proteger la información de contacto en la era de los LLM habilitados para la navegación.