Resumen Técnico: Contención sobre Detección para la Defensa contra la Inyección de Prompts

Declaración del Problema

La inyección de prompts representa una vulnerabilidad crítica en los sistemas de modelos de lenguaje de gran tamaño (LLM) agénticos, donde el contenido adversarial incrustado en la entrada del usuario anula las restricciones del sistema, lo que conduce a la exfiltración de datos, la escalada de privilegios o la ejecución de código no autorizado. Los sistemas de producción actuales, particularmente aquellos que se integran con almacenes de datos sensibles y entornos de ejecución de código (sandboxes), dependen fuertemente de las defensas basadas en la detección (filtrado de palabras clave, clasificadores aprendidos, análisis de perplejidad).

Los autores argumentan que el paradigma de la detección sufre un fallo fundamental: intenta resolver un problema de clasificación semántica (distinguir instrucciones maliciosas de datos legítimos) que es inherentemente ambiguo en el lenguaje natural. Este enfoque crea un compromiso inevitable entre precisión y latencia. Los clasificadores de alta precisión introducen retrasos en la inferencia y requieren un reentrenamiento continuo, mientras que incluso los detectores altamente precisos (por ejemplo, 99%) fallan porque el atacante solo necesita un éxito para comprometer el sistema. Además, los mecanismos de detección suelen producir falsos positivos, rechazando consultas legítimas de usuarios que contienen un fraseo de tipo instructivo.

Metodología: La Arquitectura de Contención

El artículo propone un cambio de la detección hacia la contención. En lugar de intentar identificar y rechazar la entrada maliciosa, el sistema la vuelve estructuralmente inerte mediante la imposición de un límite criptográfico entre las instrucciones y los datos. Esto se logra a través de una arquitectura de defensa compuesta de cuatro capas:

1. Generación de Tokens Criptográficos Efímeros:
   Al iniciar el contenedor, se genera un token ($\tau$) criptográficamente seguro con 256 bits de entropía. Este token se codifica como una cadena base64 segura para URL (43 caracteres). Crucialmente, $\tau$ nunca se persiste en disco, registros (logs) o variables de entorno, y se rota al reiniciar el contenedor, asegurando la seguridad hacia adelante (forward secrecy).

2. Canonicidad de la Entrada:
   Antes del envoltorio, la entrada del usuario se somete a un proceso de canonicidad para eliminar vectores de evasión basados en la codificación. Este proceso elimina caracteres de control Unicode (categorías Cc) y separadores específicos de línea/párrafo (Zl/Zp, por ejemplo, U+2028, U+2029) que podrían ser interpretados de manera diferente por los tokenizadores frente a la lógica de validación. Esto asegura que la entrada sea normalizada antes de la imposición del límite.

3. Envoltorio de Token Autenticado:
   La entrada canonicalizada se envuelve en un sobre de tipo XML: <untrusted_input id="{token}">...</untrusted_input>.

   • Validación en el Lado del Servidor: Se realiza una verificación de seguridad crítica antes del envoltorio. El sistema rechaza cualquier entrada que ya contenga el token $\tau$ o la estructura de la etiqueta del sobre. Esto evita que un atacante cierre prematuramente la etiqueta del sobre para inyectar instrucciones fuera del límite.
   • Garantía Determinista: El límite es criptográficamente impredecible; un atacante no puede construir una etiqueta de cierre válida sin conocer $\tau$.

4. Anclaje de Comportamiento del Prompt (Behavioral Prompt Grounding):
   El prompt del sistema instruye explícitamente al LLM para que trate el contenido dentro de las etiquetas <untreated_input> estrictamente como datos para ser procesados, no como instrucciones ejecutables. El prompt enfatiza que el lenguaje de tipo instructivo encontrado dentro del sobre debe tratarse como texto literal. Los autores señalan que se prefiere un fraseo neutral sobre advertencias alarmantes para evitar rechazos falsos de consultas legítimas.

Principales Contribuciones

El artículo realiza cuatro contribuciones primordiales:

1. Garantía de Seguridad Formal: Los autores proporcionan una prueba formal (Teorema 1) que demuestra que, bajo un modelo de atacante de caja negra (sin acceso a un oráculo al token de tiempo de ejecución), la probabilidad de que un atacante diseñe un escape de límite válido es despreciable ($\le 2^{-256}$).
2. Arquitectura de Defensa Componible: Un sistema de cuatro capas con interfaces formalmente especificadas y aislamiento de modos de falla, que opera en la capa de preprocesamiento de entrada independientemente del comportamiento del modelo.
3. Metodología de Pruebas Basadas en Propiedades: Los autores utilizaron el marco de trabajo Hypothesis para definir 15 invariantes de seguridad verificables por máquina. Este enfoque identificó con éxito tres errores críticos de producción (incluyendo un error de no idempotencia en la canonicidad y un problema de desbordamiento de búfer) que las pruebas convencionales basadas en ejemplos pasaron por alto.
4. Validación Empírica: Una evaluación exhaustiva contra 547 patrones adversariales extraídos de cuatro corpus de ataques establecidos (Garak, OWASP LLM Top 10, HarmBench y un conjunto multilingüe personalizado).

Resultados

La defensa fue evaluada en un sistema agéntico de producción que sirve a aproximadamente 200 analistas con acceso a bases de datos, intérpretes de código y bases de conocimiento RAG.

• Tasa de Contención: El sistema alcanzó una tasa de contención sintáctica del 94.3%. En estos casos, la entrada adversaria fue envuelta con éxito y el modelo la trató como datos.
• Fallos Residuales: La tasa de fallo del 5.7% consistió enteramente en jailbreaks semánticos a nivel de modelo. En estos casos, la entrada estaba sintácticamente contenida dentro del sobre, pero el modelo, no obstante, siguió las instrucciones inyectadas (por ejemplo, mediante reencuadre cognitivo o sufijos adversariales). Los autores clasifican estos como ortogonales a la defensa de la capa de entrada.
• Falsos Positivos: La defensa produjo 0% de falsos positivos. Debido a que el sistema nunca rechaza la entrada basándose en el contenido (solo la envuelve), las consultas legítimas que contienen fraseo de tipo instructivo se procesaron correctamente.
• Latencia: El sobrecoste de tiempo de ejecución se midió en <0.5ms por solicitud, superando significativamente a los clasificadores aprendidos (180ms) y evitando la hinchazón de tokens de las defensas de tipo "sándwich".
• Descubrimiento de Errores: Las pruebas basadas en propiedades descubrieron fallos críticos, incluyendo un problema de no idempotencia en la canonicidad donde ciertos caracteres Unicode podían evadir la validación en pasadas repetidas, y un error de búfer de registro que descartaba los eventos más recientes (forensemente relevantes) bajo carga.

Significado y Reivindicaciones

El artículo afirma que el enfoque de contención altera fundamentalmente el objetivo de seguridad para los LLM agénticos. Al cambiar de una clasificación semántica probabilística a una imposición de límites sintácticos deterministas, la defensa elimina el compromiso entre precisión y latencia inherente a los sistemas basados en detección.

Los autores enfatizan que, si bien la capa de contención proporciona una base criptográficamente sólida que evita el escape estructural, no resuelve el problema de los jailbreaks a nivel de modelo. El 5.7% de la tasa de fallo residual representa el límite de la defensa de la capa de entrada; abordar esto requiere salvaguardas complementarias a nivel de modelo (entrenamiento de seguridad, modelos de guardrails). Sin embargo, la capa de contención asegura que el límite de la entrada sea inforjable, permitiendo que las defensas de nivel superior operen sobre un sustrato seguro.

El trabajo posiciona las pruebas basadas en propiedades como un estándar esencial para la infraestructura de LLM con criticidad de seguridad, demostrando su superioridad para descubrir casos de borde vulnerables que las pruebas basadas en ejemplos pasan por alto. El armazón de evaluación y las especificaciones de propiedades se publican como código abierto para facilitar la reproducibilidad.