Resumen Técnico: Defendiendo contra la Inyección de Prompts con DataFilter

1. Declaración del Problema

El artículo aborda la vulnerabilidad crítica de seguridad de la inyección de prompts en agentes de Modelos de Lenguaje Grande (LLM). A medida que los LLM se despliegan cada vez más para automatizar tareas (por ejemplo, navegación web, llamada a herramientas) e interactuar con datos externos no confiables (documentos, correos electrónicos, salidas de herramientas), los atacantes pueden inyectar instrucciones maliciosas en estos datos. Estas inyecciones anulan el prompt original de confianza del usuario, redirigiendo al agente para realizar acciones no deseadas y potencialmente dañinas, como la filtración de datos o la ejecución de malware.

Las defensas existentes sufren de compromisos significativos:

• Defensas a nivel de sistema: Requieren un rediseño de sistema no trivial y a menudo resultan en una pérdida sustancial de utilidad porque restringen el control del flujo de datos.
• Defensas a nivel de modelo (Fine-tuning): Requieren acceso a los pesos del modelo, lo que las hace inaplicables a modelos propietarios de caja negra.
• Defensas basadas en detección: A menudo incurren en altas tasas de falsos positivos, lo que provoca la degradación de la utilidad al rechazar entradas benignas.
• Defensas basadas en prompts: Generalmente ofrecen una seguridad débil, con tasas de éxito de ataque (ASR) que a menudo superan el 40%.

Los autores identifican una brecha para una defensa que sea agnóstica al modelo (funciona con cualquier backend, incluyendo los propietarios), preservadora de la utilidad y altamente segura sin requerir un rediseño del sistema.

2. Metodología: DataFilter

Los autores proponen DataFilter, un mecanismo de defensa agnóstico al modelo y en tiempo de prueba. A diferencia de los sistemas de detección que rechazan entradas completas, DataFilter actúa como un filtro que se sitúa entre la fuente de datos no confiable y el LLM de backend.

Mecanismo Central

DataFilter toma dos entradas:

1. Instrucción de Confianza ($u$): El prompt original del usuario.
2. Datos No Confiables ($x$): Los datos externos que potencialmente contienen inyecciones.

La tarea del filtro es producir una versión saneada de los datos ($x_{clean}$) que elimine las instrucciones maliciosas mientras preserva el contenido benigno relevante para la instrucción de confianza. Esto se enmarca como un problema de generación de secuencia a secuencia condicional.

Proceso de Entrenamiento (Supervised Fine-Tuning)

El modelo de filtro (basado en Llama-3.1-8B-Instruct) es entrenado mediante Supervised Fine-Tuning (SFT) en un conjunto de datos personalizado construido a partir del conjunto de datos de ajuste de instrucciones Alpaca. La estrategia de entrenamiento involucra cuatro objetivos de diseño clave para asegurar la robustez:

1. Preservación Benigna: El modelo es entrenado con muestras sin inyecciones para aprender que, si los datos son benignos, deben producirse sin cambios.
2. Prevención de Alucinaciones: Para evitar que el modelo "complete" el texto después de eliminar una inyección (un comportamiento común de los LLM), los datos de entrenamiento incluyen muestras donde los datos benignos están truncados. El modelo aprende a producir los datos truncados exactamente como son, sin generar nuevos tokens.
3. Prevención de Repetición Infinita: Se introduce un token especial de fin de secuencia (<|end_of_data|>) y se entrena para asegurar que el filtro detenga la generación inmediatamente después de los datos limpios, evitando bucles infinitos.
4. Generalización Posicional: Las inyecciones se simulan en posiciones aleatorias (inicio, medio, final) dentro de los datos para asegurar que el filtro pueda identificar y eliminar inyecciones independientemente de su ubicación.

El objetivo de entrenamiento minimiza la log-verosimilitud negativa de generar los datos limpios reales dado el par de prompt y datos inyectados:
$$L(\theta) = -\log p_\theta(x_{clean} | \langle u, x \rangle)$$

Manejo de Datos Estructurados

Para aplicaciones agénticas donde los datos son estructurados (por ejemplo, JSON), DataFilter analiza la estructura, filtra recursivamente el contenido de texto de las claves y valores, y reconstruye el objeto. Esto evita la generación de JSON sintácticamente inválidos.

3. Contribuciones Clave

• Una Nueva Arquitectura de Defensa: DataFilter es la primera defensa agnóstica al modelo que combina la seguridad de los enfoques a nivel de sistema con la facilidad de despliegue de los enfoques a nivel de modelo, sin requerir los pesos del modelo de backend.
• Lógica de Filtrado Sofisticada: Al condicionar el filtro a la instrucción de confianza del usuario, el sistema puede distinguir entre oraciones imperativas que son inyecciones maliciosas y aquellas que son contexto benigno (por ejemplo, listas de "TODO" en correos electrónicos), una distinción con la que los métodos anteriores tuvieron dificultades.
• Evaluación Exhaustiva: El artículo evalúa la defensa a través de múltiples benchmarks (SEP, InjecAgent, AgentDojo, AlpacaEval2) y contra diversos vectores de ataque (Directo, Ignorar, Completar, Multiturno y Ataques de Contexto).

4. Resultados Experimentales

Los autores evaluaron DataFilter contra líneas base que incluyen PromptGuard, DataSentinel, Sandwich prompting, Spotlighting, Tool Filter y el trabajo concurrente PromptArmor.

Rendimiento de Seguridad (Tasa de Éxito de Ataque - ASR)

• AgentDojo: DataFilter redujo el ASR a un promedio de 0.4% (máximo 1.2%) en varios tipos de ataque, superando a PromptArmor (promedio 0.7%) y superando significativamente a las defensas basadas en detección y en prompts (que a menudo tenían un ASR > 20%).
• InjecAgent: DataFilter logró un ASR de 2.0% (Ataque Base) y 0.0% (Ataque Mejorado) en gpt-4o, y 2.1% y 1.2% en Llama-3.1-8B-Instruct.
• SEP (Seguimiento de Instrucciones): DataFilter mantuvo un bajo ASR en los seis tipos de ataque tanto para gpt-4o como para Llama-3.1-8B-Instruct. Notablemente, fue una de las pocas defensas efectivas contra el ataque de Contexto, que imita instrucciones legítimas.
• Ataques Adaptativos: Incluso bajo ataques adaptativos diseñados por humanos y fuertes ataques adaptativos basados en LLM (usando algoritmos genéticos), DataFilter mantuvo el ASR más bajo entre todas las defensas probadas (83% vs 93% para PromptArmor en el peor escenario de LLM basado en la situación), aunque los autores señalan que ninguna defensa es actualmente inmune a los ataques adaptativos más sofisticados.

Rendimiento de Utilidad

• AgentDojo: DataFilter preservó el 79.4% de la utilidad benigna (solo una caída de ~2% en comparación con el modelo sin defender), mientras que las defensas basadas en detección como DataSentinel sufrieron una severa pérdida de utilidad (36.6%) debido a falsos positivos.
• AlpacaEval2: DataFilter mantuvo puntuaciones de utilidad comparables a la línea base sin defender (54.1% para gpt-4o), demostrando que el proceso de filtrado no degrada la calidad de las respuestas para tareas benignas.

Compromiso (Trade-off)

Como se ilustra en las figuras del artículo, DataFilter logra un compromiso de Seguridad-Utilidad superior, acercándose más al "defensa ideal" (ASR cero con caída de utilidad cero) que cualquier método anterior.

5. Significado y Reivindicaciones

El artículo afirma que DataFilter ofrece una defensa práctica y plug-and-play para asegurar los LLM comerciales de caja negra contra la inyección de prompts. Su importancia radica en:

1. Accesibilidad: No requiere acceso a los pesos del modelo, lo que lo hace desplegable para desarrolladores de terceros que utilizan APIs propietarias.
2. Efectividad: Mitiga con éxito una amplia gama de ataques de inyección, incluyendo aquellos que son contextualmente relevantes y difíciles de detectar.
3. Preservación de la Utilidad: Evita el problema del "sobre-rechazo" común en los sistemas basados en detección, asegurando que los agentes sigan siendo funcionales para tareas legítimas.

Los autores reconocen que, si bien DataFilter es robusto contra los vectores de ataque actuales, aún puede ser vulnerable a los ataques adaptativos más sofisticados, una limitación compartida por todas las defensas existentes. Sin embargo, posicionan a DataFilter como una solución sólida e inmediata a corto y mediano plazo para asegurar los agentes de LLM de nivel de producción.