El trilema de la defensa: por qué los wrappers anti-inyección no pueden ser completos

¿Qué es esto?

El 7 de abril de 2026, un equipo dirigido por Manish Bhatt y Sarthak Munshi publicó The Defense Trilemma: Why Prompt Injection Defense Wrappers Fail? (arXiv:2604.06436, revisado el 11 de abril). El artículo no describe un nuevo ataque. Demuestra un límite: ningún wrapper de defensa continuo que preserve la utilidad puede hacer que todas las salidas de un modelo de lenguaje sean seguras. Aquí, un «wrapper» es cualquier defensa que preprocesa la entrada antes de que el modelo la vea: un saneador, un parafraseador, un prompt de guarda, una etapa de delimitadores (spotlighting) o una reescritura constitucional.

La inyección de prompts ocupa el puesto n.º 1 del OWASP Top 10 para aplicaciones LLM, y la respuesta más común de la industria es precisamente este tipo de wrapper. El trilema afirma que este enfoque popular tiene un techo matemático: una defensa puede ser continua (los prompts similares reciben un trato similar), preservar la utilidad (los prompts seguros pasan sin cambios) y ser completa (toda salida es segura), pero solo se pueden tener dos de las tres a la vez. Algo inusual en la investigación de seguridad: todo el argumento está verificado por máquina en Lean 4.

Cómo funciona

Modelemos la seguridad del modelo mediante una puntuación continua f(x) sobre el espacio de prompts, con un umbral τ: los prompts por debajo de τ son seguros, los que están por encima son inseguros, y exactamente en τ se halla la frontera de decisión. Una defensa D reasigna los prompts antes de la puntuación. Las tres propiedades producen tres resultados, cada uno demostrado bajo una hipótesis más fuerte.

La fijación de la frontera (teorema 4.1) es el núcleo, y la intuición cabe en una frase. Una defensa que preserva la utilidad deja intacto cada prompt seguro, por lo que su conjunto de puntos fijos es cerrado; pero la región segura es abierta (es la preimagen de un intervalo abierto bajo una puntuación continua). En un espacio de prompts conexo, un conjunto abierto propio no vacío no puede ser también cerrado, de modo que los puntos fijos deben desbordarse sobre la propia frontera. Traducción: algunos prompts situados exactamente sobre la línea seguro/inseguro atraviesan la defensa sin modificación. La defensa no puede limpiar las entradas más cercanas al borde.

La restricción ε-robusta (teorema 5.1) extiende esto de un punto a una región. Bajo un supuesto de regularidad de Lipschitz (la defensa no puede mover las puntuaciones arbitrariamente rápido), toda una banda de medida positiva de prompts cercanos a la frontera permanece cerca del umbral tras la defensa. No se puede empujar uniformemente ese vecindario hacia la seguridad.

La región insegura persistente (teorema 6.3) es el resultado más fuerte: bajo una condición de transversalidad —cuando la superficie de alineamiento sube más rápido de lo que la defensa puede rebajarla— un conjunto de medida positiva de entradas permanece estrictamente inseguro tras ejecutarse la defensa. No al límite; inseguro.

Los autores presentan la conclusión como un resultado «no free lunch» para las defensas, análogo al teorema clásico de Wolpert según el cual ningún optimizador domina en todos los problemas. También extienden la imposibilidad a las conversaciones multironda, a las defensas estocásticas (aleatorizadas) y a los pipelines de agentes no lineales, donde señalan que las llamadas a herramientas amplifican el fallo en lugar de contenerlo.

Por qué importa

El resultado es un diagnóstico preciso de por qué el reflejo de «sanear la entrada» decepciona una y otra vez. Dos de las tres propiedades del trilema son cosas que los defensores quieren activamente: la continuidad (para un sistema predecible) y la preservación de la utilidad (para no bloquear a los usuarios legítimos). Sosteniendo ambas, la completitud queda matemáticamente fuera de alcance: siempre existirá un conjunto de medida positiva de entradas que el wrapper deja pasar. A un atacante solo le hace falta que ese conjunto no esté vacío.

Esto enlaza con nuestra cobertura de la integridad contextual y por qué separar datos de instrucciones es un error de categoría: un artículo sostiene semánticamente que la línea datos/instrucciones es el marco equivocado, el otro demuestra topológicamente que el wrapper construido sobre ella no puede ser completo. Ambos apuntan en la misma dirección: parchear el flujo de entrada es estructuralmente insuficiente.

Las fechas ayudan a ponderar el resultado. El preprint es del 7 de abril de 2026 y, como afirmación de métodos formales, su credibilidad descansa en las pruebas, no en un estado de revisión por pares: el desarrollo en Lean 4 declara 45 archivos, ~350 teoremas, cero instrucciones sorry (prueba admitida) y tres axiomas estándar, con un artefacto publicado abiertamente. La sección empírica valida las predicciones en tres modelos —Llama-3-8B, GPT-OSS-20B y GPT-5-Mini— midiendo las bandas de fallo cercanas a la frontera que predice la teoría.

Una advertencia sobre el alcance, que los autores subrayan: los teoremas restringen únicamente un wrapper continuo individual D: X → X sobre un espacio de prompts conexo. No son una prueba de que los LLM no puedan defenderse.

Defensas

El valor del artículo para los defensores es que indica con exactitud qué espacio de diseño está muerto y cuál sigue abierto. De manera crucial, la imposibilidad no abarca:

• El alineamiento en el entrenamiento — RLHF, DPO, entrenamiento constitucional que modifica f en sí, en lugar de envolver su entrada.
• Los cambios arquitectónicos del modelo.
• Las defensas discontinuas — listas de bloqueo estrictas y clasificadores discretos autorizados a rechazar, no a reasignar. Renunciar a la continuidad es una salida legítima del trilema.
• Los filtros de salida, los conjuntos (ensembles) y la revisión humana.
• Los sistemas multicomponente que rechazan o redirigen entradas en vez de preservar la utilidad en cada prompt, es decir, sistemas dispuestos a rechazar algunas entradas de apariencia legítima.

La «prescripción de ingeniería» de los autores se deriva de las matemáticas: aplanar la frontera (reducir la confianza del modelo cerca de τ), reducir la constante de Lipschitz (limitar la velocidad de variación de las puntuaciones), reducir la dimensión efectiva del espacio de prompts que la defensa debe cubrir y vigilar la frontera, no eliminarla — aceptar que existe una región residual e instrumentarla en lugar de fingir que un wrapper la cerró.

La lección práctica coincide con la ortodoxia de la defensa en profundidad, ahora con una prueba debajo: no apueste la seguridad a un único saneador de entrada. Trate los wrappers como una sola capa superficial, traslade la seguridad real al entrenamiento y la arquitectura, y diseñe los pipelines de agentes asumiendo que algunas entradas inyectadas llegarán al modelo, de modo que el daño de una inyección exitosa quede acotado por permisos mínimos de herramientas y controles de salida, y no por la promesa del wrapper de interceptarlo todo.

Estado

Elemento	Detalle
Artículo	The Defense Trilemma: Why Prompt Injection Defense Wrappers Fail? (arXiv:2604.06436)
Publicado	2026-04-07 (revisado el 2026-04-11)
Resultado	Continuidad + preservación de la utilidad + completitud no pueden coexistir en un wrapper
Verificación	Lean 4 + Mathlib: 45 archivos, ~350 teoremas, cero sorry, tres axiomas estándar
Empírico	Llama-3-8B, GPT-OSS-20B, GPT-5-Mini
Alcance	Solo wrappers continuos sobre espacios de prompts conexos; defensas en entrenamiento y arquitectura no afectadas