El filtrado de salida vence a la autodefensa del modelo: 20 000 ataques adaptativos, un solo superviviente

¿De qué se trata?

El 26 de abril de 2026, Priyal Deep y sus coautores de Swept AI y la Universidad de Michigan publicaron Evaluation of Prompt Injection Defenses in Large Language Models en arXiv (2604.23887). El artículo fue revisado el 12 de mayo de 2026 (v2). Su método es duro en el buen sentido: un atacante adaptativo que evoluciona durante cientos de rondas, probado frente a nueve configuraciones defensivas, en más de 20 000 ataques. El hallazgo es contundente: toda defensa que dependa de que el propio modelo se controle termina por ceder. La única configuración que aguantó fue el filtrado de salida — reglas codificadas en código de aplicación separado que inspeccionan la respuesta del modelo antes de que llegue al usuario. En 15 000 ataques contra esa configuración, el número de fugas fue cero.

No es “otro paper de jailbreak”. Es una respuesta sistemática a la pregunta que los equipos repiten una y otra vez: de las defensas que ya estamos desplegando, ¿cuáles sobreviven realmente a un atacante que se adapta?

Cómo funciona

El modelo de amenaza supone un usuario hostil, una aplicación LLM que mantiene un secreto en su system prompt (clave de API, instrucción interna, registro de cliente) y un defensor libre de combinar las mitigaciones estándar. El atacante no es un script con un payload fijo. Es a su vez un bucle dirigido por un LLM que observa la respuesta, refina su estrategia y vuelve a intentarlo. El artículo ejecuta ese bucle durante cientos de rondas contra cada defensa y reporta la tasa acumulada de fugas.

Se probaron nueve configuraciones defensivas, agrupadas en dos familias:

# Taxonomía conceptual — ilustrativa, no es un exploit.
# A. Defensas del lado del modelo (se le pide al modelo que rechace)
#    1. System prompt simple con "no reveles el secreto"
#    2. Spotlighting / delimitadores alrededor de la entrada no confiable
#    3. Prompts con jerarquía de instrucciones
#    4. Autorreflexión: "¿Tu última salida contenía el secreto?"
#    5. Defensas por paráfrasis / sandwich
#    6. Clasificador a nivel de prompt (el modelo decide si la entrada es maliciosa)
#    7. Pila combinada del lado del modelo (varias de las anteriores juntas)
#
# B. Defensas del lado de la aplicación (código fuera del modelo)
#    8. Filtro de entrada vía clasificador separado
#    9. FILTRO DE SALIDA: comprobaciones regex/cadena codificadas en duro sobre
#       la respuesta antes de entregarla al usuario — cero fugas en 15 000 ataques

La asimetría es lo esencial. Una defensa de la familia A pide al propio sistema atacado que decida si el ataque tuvo éxito. Con suficientes rondas, el atacante adaptativo acaba encontrando una formulación que el modelo del defensor acepta. La familia B trata al modelo como un componente no confiable y valida su salida de forma independiente. El filtro de salida del artículo no es una IA ingeniosa: es código de aplicación determinista que conoce la forma del secreto y se niega a emitir respuestas que lo contengan.

Por qué importa

Es el tercer artículo independiente en dieciocho meses que apunta en la misma dirección. The Instruction Hierarchy (OpenAI, 2024) admitía que el modelo por sí solo no puede imponer una jerarquía bajo presión adversarial. ARGUS (Weng et al., 5 de mayo de 2026) movió la decisión a un grafo de procedencia fuera del modelo. Deep et al. generalizan ahora el resultado negativo: cualquier defensa que termine con “…y el modelo decide” acaba perdiendo frente a un atacante adaptativo. El corolario es constructivo: las fronteras de seguridad pertenecen a código que no se ejecuta dentro del LLM.

Para los equipos que despliegan aplicaciones LLM hoy, esto redefine lo que debería significar “mitigación de prompt injection” en una hoja de ruta. Spotlighting, sandwiching, prompts con jerarquía de instrucciones y autorreflexión son útiles para la UX en tráfico limpio, pero no son la frontera. La frontera es lo que se ejecuta tras la respuesta del modelo — y antes de que esa respuesta toque una llamada a una herramienta, una escritura en base de datos o la pantalla del usuario.

Defensas

Implicaciones prácticas extraídas directamente del artículo y del trabajo concurrente citado:

1. Nunca coloque en el system prompt un secreto que no publicaría. Si se filtra, ¿qué se rompe? Si la respuesta es “mucho”, sáquelo del prompt y póngalo detrás de una herramienta que el modelo pueda invocar con permisos limitados.
2. Implemente filtros de salida deterministas. Regex, coincidencia de cadenas, validación estructural JSON, listas de denegación de tokens sensibles conocidos. Ejecútelos en código de aplicación antes de la entrega. Cualquier coincidencia debe ser un rechazo duro, no una advertencia.
3. Apile filtrado de entrada y filtrado de salida. El filtrado de entrada reduce la superficie de ataque; el de salida atrapa lo que se cuela. Las configuraciones combinadas del artículo rinden mejor cuando hay filtrado en ambos lados.
4. Audite cualquier defensa “autoverificada”. Si la mitigación consiste en que el mismo modelo se pregunte “¿fue seguro?”, suponga que un atacante adaptativo puede derrotarla. Úsela para UX, no para seguridad.
5. Restrinja los agentes con operaciones sensibles a personal de confianza hasta que sus defensas de salida hayan sido verificadas de forma independiente. Los autores plantean esto explícitamente como una postura provisional.

Estado

Elemento	Referencia	Fecha	Notas
Paper (v1)	arXiv:2604.23887v1	2026-04-26	14 páginas, 9 figuras, cs.CR / cs.AI
Paper (v2 — actual)	arXiv:2604.23887v2	2026-05-12	Última revisión
Defensas probadas	§3 del paper	2026-04-26	9 configuraciones, lado modelo y lado aplicación
Presupuesto de ataque	§4	—	20 000+ ataques adaptativos, cientos de rondas
Mejor defensa	Filtrado de salida	—	0 fugas en 15 000 ataques
Relacionado: ARGUS	arXiv:2605.03378	2026-05-05	Misma dirección: defender fuera del modelo

Lectura de fondo: la inyección de prompt no es un problema del modelo que un mejor modelo resolverá. Es un problema de sistema y, como todo problema de sistema en seguridad, la respuesta es validar la salida no confiable en código que usted controla.