Por qué fallan los detectores de inyección de prompts: el problema de la evasión en 2026
De los clasificadores por palabras clave a las sondas de deriva de activación, los detectores de inyección de prompts comparten una debilidad: el adversario adaptativo. Dos estudios reportan hasta ~100 % de evasión. La detección es una capa, nunca la frontera.
En resumen Los «detectores» de inyección de prompts — las barreras de entrada que marcan una instrucción maliciosa antes de que llegue al modelo — están ampliamente desplegados y son fáciles de sobrevender. Dos estudios revisados por pares, Hackett et al. (LLMSec 2025) y Jahed y Alouani (arXiv 2602.00750, febrero de 2026), demuestran que tanto los detectores clásicos de tipo clasificador como los más nuevos basados en activación caen ante un adversario adaptativo, a veces con una evasión cercana al 100 %. La lección es arquitectónica: un detector es un filtro útil, no una frontera de seguridad.
¿Qué es esto?
La inyección de prompts es el riesgo número uno de OWASP para las aplicaciones LLM, y la primera línea de defensa más común es un detector: un modelo o conjunto de reglas independiente que inspecciona la entrada no confiable y bloquea todo lo que parezca una instrucción inyectada. Azure Prompt Shield de Microsoft y Prompt Guard de Meta son ejemplos conocidos.
El resultado incómodo, documentado a lo largo de 2025-2026, es que estos detectores son sistemáticamente evadibles. Hackett, Birch, Trawicki, Suri y Garraghan probaron seis sistemas de protección destacados y reportaron tasas de evasión de hasta el 100 % (arXiv 2504.11168, v1 abril de 2025, aceptado en LLMSec 2025). En febrero de 2026, JR Jahed e Ihsen Alouani apuntaron el mismo foco a la generación más reciente — las sondas de «deriva de tarea» basadas en activación, que leen las capas ocultas del modelo — y también las quebraron (arXiv 2602.00750). La idea de detección cambia; el resultado de evasión se repite.
Cómo funciona
Existen dos familias de evasión distintas, ajustadas a dos diseños de detector. Aquí no se reproduce ningún payload funcional: lo importante es la clase de ataque, no un exploit listo para copiar y pegar.
Contra los detectores de texto/clasificador — la inyección de caracteres. La instrucción inyectada se reescribe de modo que un humano (y el modelo) siga leyéndola, pero la tokenización o la lógica por palabras clave del detector no. Las técnicas publicadas incluyen caracteres de ancho cero y Unicode Tag, sustitución por homoglifos, caracteres de ancho completo (CJK), leetspeak, espaciado de caracteres y envoltura en base64:
El detector ve: tokens distorsionados / codificados / espaciados -> "benigno"
El modelo ve: la misma cadena, normalizada internamente -> sigue la instrucción
Hackett et al. lo combinan con un paso de aprendizaje automático adversario: un ranking de importancia de palabras calculado en un modelo white-box sin conexión hace que los bypasses black-box sean más fiables.
Contra los detectores basados en activación — los sufijos adversarios. Las sondas de deriva no leen caracteres; leen el desplazamiento que una instrucción maliciosa provoca en las activaciones internas del modelo. Jahed y Alouani añaden un sufijo optimizado de forma adversaria a la entrada envenenada, mediante una búsqueda Greedy Coordinate Gradient (GCG) modificada, para encontrar un sufijo universal que engaña a todas las sondas capa por capa a la vez sin perder la eficacia de la inyección. Tasa de éxito reportada para evadir todas las sondas de forma simultánea: 93,91 % en Phi-3 3.8B y 99,63 % en Llama-3 8B.
El hilo común es el adversario adaptativo. Un detector entrenado o ajustado con las cadenas de ataque de ayer es, por construcción, un blanco fijo — y un atacante que pueda consultarlo o modelarlo puede buscar la forma de rodearlo.
Por qué importa
Si su arquitectura asume que «la barrera lo atrapó», una evasión es silenciosa: la instrucción inyectada llega al modelo, y todo lo que viene después — llamadas a herramientas, lecturas de datos, solicitudes salientes — procede como si la entrada fuera confiable. El radio de impacto es todo lo que el agente tiene permitido hacer.
Esto no es motivo para descartar los detectores; un buen filtro aún detiene el 90 % de los ataques perezosos y aporta señal para la supervisión. Sí es motivo para dejar de contarlos como un control que pueda «fallar en modo cerrado». Los proveedores citan puntuaciones F1 en benchmarks estáticos; los estudios anteriores miden otra cosa — la robustez ante un atacante que se adapta — y esa cifra es mucho más baja.
Defensas
La detección es una capa. Diseñe como si fuera a ser eludida.
-
Normalice antes de inspeccionar. La mayoría de los bypasses por inyección de caracteres mueren bajo la canonicalización: normalización Unicode NFKC, eliminación de caracteres de ancho cero y Unicode Tag, plegado de homoglifos, colapso de espacios y decodificación de base64 evidentes. Un informe práctico de marzo de 2026 sobre el escáner open source ClawGuard muestra que un preprocesamiento determinista (incluida la normalización de ancho completo) captura una gran parte de estas variantes con latencia inferior a 10 ms. La normalización va delante de cualquier detector.
-
No convierta al detector en la frontera. Los controles que sobreviven a una detección fallida son arquitectónicos: privilegio mínimo en cada herramienta, separación estricta entre instrucciones confiables y datos no confiables, y evitar la «tríada letal» de acceso a datos privados + contenido no confiable + un canal de exfiltración en el mismo contexto del agente. Ponga un humano en el bucle para las acciones de consecuencia.
-
Apile detectores para que una evasión deba vencerlos a todos. Una etapa determinista de regex/normalización, un clasificador y una sonda de activación fallan ante ataques diferentes. Exija que un bypass derrote toda la pila de forma simultánea, y fije un único punto de operación para medir la cobertura con honestidad en vez de elegir umbrales a conveniencia.
-
Entrene de forma adversaria lo que conserve. Jahed y Alouani proponen la aumentación por sufijos — generar múltiples sufijos adversarios, añadir uno al azar durante el entrenamiento y entrenar la sonda con las activaciones resultantes. Eleva el coste de la evasión; no cierra la brecha.
-
Asuma el fallo y vigile las salidas. Restrinja la salida de red, registre las llamadas a herramientas y alerte ante secuencias de acciones anómalas. La inyección que no detecta en la entrada quizá aún la atrape en la acción.
-
Haga red team a su propia barrera. Ejecute estas clases de evasión publicadas contra su pila con herramientas como garak o promptfoo, a un umbral fijo, antes de que lo haga un atacante.
Estado del arte
| Elemento | Referencia | Fecha | Nota |
|---|---|---|---|
| Evasión por inyección de caracteres + AML, 6 sistemas | arXiv 2504.11168 | abr. 2025 (LLMSec 2025) | Hasta 100 % de evasión; Azure Prompt Shield, Meta Prompt Guard entre los objetivos |
| Evasión por sufijo adversario de sondas de activación | arXiv 2602.00750 | feb. 2026 | 93,91 % (Phi-3 3.8B), 99,63 % (Llama-3 8B) evadiendo todas las sondas |
| Defensa por normalización determinista (ClawGuard) | earezki.com | mar. 2026 | Preprocesamiento regex/NFKC, sub-10 ms; cita 2602.00750 |
| Inyección de prompts = LLM01 | OWASP LLM Top 10 | 2026 | Sigue siendo el riesgo de aplicación n.º 1 |
El encuadre que conviene retener: un detector de inyección de prompts le informa sobre los ataques que el adversario no se molestó en ocultar. Trate un resultado limpio como la ausencia de un ataque perezoso, no como la presencia de seguridad — y ponga sus controles reales donde el modelo actúa, no donde lee.