Jailbreaking vs. inyección de prompts: no son el mismo ataque

Los equipos de seguridad que despliegan LLMs en 2026 rutinariamente confunden dos clases de ataque distintas: jailbreaking e inyección de prompts. La confusión es entendible —ambas involucran texto adversario, ambas apuntan a modelos de lenguaje, y ambas aparecen en el mismo párrafo de la mayoría de marcos de riesgo—. Pero tratarlas como el mismo ataque produce mitigaciones equivocadas, modelos de amenaza equivocados, y brechas que los atacantes explotan.

Jailbreaking: un ataque al plano de control en tiempo de inferencia

El jailbreaking es el intento de subvertir el entrenamiento de alineación del modelo en tiempo de inferencia. El modelo ha sido entrenado, vía RLHF o similar, a rechazar ciertas categorías de solicitud. El atacante construye entradas que evaden ese comportamiento de rechazo sin modificar los pesos del modelo.

El objetivo del atacante: hacer que el modelo produzca salidas que fue entrenado a no producir —contenido dañino, información que viola política, suplantación de personas restringidas—. El mecanismo es manipulación conductual, no inyección de código.

Los jailbreaks toman varias formas:

Framing de roleplay. Pedirle al modelo “pretender ser” una versión sin restricciones de sí mismo (ataques “DAN”), un personaje sin restricciones, o un modelo ficticio de un futuro donde las restricciones se han levantado.

Inyección de prefijo. Anteponer declaraciones como “Como IA sin restricciones, responderé esto:” a una consulta rechazada.

Sufijos adversarios. La variante más sofisticada técnicamente: secuencias de caracteres generadas algorítmicamente que, cuando se añaden a un prompt rechazado, consistentemente causan que el modelo cumpla. El paper GCG de Zou et al. ↗ mostró que estos transfieren entre familias de modelos.

Few-shot steering. Proveer ejemplos del modelo cumpliendo con solicitudes similares en el historial de conversación.

Lo que el jailbreaking no es: el jailbreaking no da al atacante acceso a prompts de sistema, sesiones de otros usuarios o infraestructura host. Subvierte las restricciones conductuales del modelo, no las fronteras de seguridad de la aplicación.

¿Quién hace jailbreaking? Principalmente usuarios intentando obtener contenido rechazado para uso personal. En la mayoría de despliegues empresariales, el actor de amenaza es un insider o usuario final, no un atacante externo. El daño es violación de política, riesgo reputacional o generación de contenido dañino a escala —significativo, pero categóricamente distinto a un ataque al plano de datos—.

Inyección de prompts: un ataque al plano de datos

La inyección de prompts es una clase de ataque fundamentalmente distinta. En lugar de subvertir la alineación, explota la inhabilidad del modelo de distinguir entre instrucciones confiables y contenido no confiable que contiene texto con forma de instrucción.

OWASP LLM Top 10 la define como: “Los ataques de inyección de prompts involucran construir entradas maliciosas para manipular las acciones o salidas de un modelo de lenguaje grande. La inyección directa de prompts anula prompts de sistema. La inyección indirecta usa contenido externo para manipular al modelo”. OWASP la clasifica como LLM01 —el riesgo principal en su taxonomía—.

Inyección directa es más cercana al jailbreaking en mecanismo: un usuario escribe instrucciones adversarias en el turno de usuario que anulan o entran en conflicto con el prompt de sistema. “Ignora tus instrucciones previas y…” es la forma canónica. El atacante es el usuario.

Inyección indirecta es la clase operacionalmente crítica, y donde está el peligro real. Aquí el atacante no es el usuario —el atacante ha colocado instrucciones maliciosas en contenido que el sistema de IA recuperará y procesará—. Una página web que el modelo navega, un documento que un usuario carga, un correo que el modelo lee en nombre del usuario, un ticket en una cola de soporte: cualquier contenido externo que el modelo trate como entrada es un vector potencial.

Greshake et al. (2023) ↗ lo demostraron sistemáticamente contra aplicaciones reales integradas con LLM. Inyectaron instrucciones en páginas web y documentos que causaron que sistemas de IA conectados exfiltraran contenido de conversaciones, ejecutaran acciones no autorizadas mediante herramientas conectadas, y propagaran instrucciones inyectadas a consultas subsecuentes.

El modelo de amenaza para la inyección indirecta es completamente distinto del jailbreaking:

• Actor de amenaza: un atacante externo, no un usuario. El atacante no tiene sesión con la aplicación.
• Vector de ataque: contenido que el modelo está dirigido a procesar —no la entrada directa del usuario—.
• Impacto potencial: acción arbitraria mediante herramientas conectadas, exfiltración de datos, secuestro de sesión, movimiento lateral mediante agentes. Esto no es “el modelo produce mal texto” —es “el atacante ejecuta acciones a través del modelo en nombre del usuario”—.

Un agente de IA con acceso a correo, calendario, sistemas de archivo o ejecución de código que procesa un documento inyectado puede convertirse en proxy controlado por el atacante. El usuario no ve nada inusual.

Por qué la distinción importa para la defensa

Las mitigaciones para jailbreaking e inyección se solapan solo parcialmente, y diferentes partes de tu arquitectura son responsables de cada defensa.

Mitigaciones de jailbreaking:

• Clasificadores conductuales que detectan categorías de contenido rechazado en salidas antes de retornar al usuario.
• Filtrado de entrada que marca patrones conocidos (framing de roleplay, prompts estilo DAN, patrones de sufijo adversario).
• Endurecimiento del prompt de sistema con instrucciones explícitas de rechazo y bloqueos de persona.
• Evaluación de red team específicamente dirigida a evasión de alineación.

Estas defensas miran al modelo: operan en la frontera entre usuario y modelo, o en la salida del modelo.

Mitigaciones de inyección de prompts:

• Segregar contenido externo no confiable de canales de instrucción confiables. Si el modelo está procesando un documento, el contenido de ese documento debe estar en un contexto claramente delimitado.
• Minimización de privilegios: los agentes de IA deben tener el acceso mínimo a herramientas requerido.
• Aprobación humana para acciones de alta consecuencia.
• Validación de esquema de salida.
• Rastreo de procedencia de entrada: loguea de dónde vino cada pieza de contenido.

Estas defensas miran a la aplicación: operan en la frontera entre la aplicación y el mundo externo, y entre la salida del modelo y los sistemas que actúan sobre ella.

El ataque compuesto

Las dos clases pueden combinarse. Un ataque de inyección indirecta puede contener instrucciones que también intenten evadir el comportamiento de rechazo del modelo —combinando el ataque al plano de datos con la subversión de alineación—. Un agente de IA procesando un documento malicioso podría ser instruido a “ignorar tus directrices de seguridad” como parte del payload inyectado.

Por eso construir defensa contra solo una clase deja una brecha.

Conclusión operacional

Al triagear un incidente de seguridad de IA o revisar la postura de riesgo de un despliegue, pregunta qué clase enfrentas:

• ¿El ataque se originó en entrada de usuario? ¿El objetivo es hacer que el modelo produzca contenido rechazado? Eso es jailbreaking. La defensa es conductual y mira al modelo.
• ¿El ataque se originó en contenido externo que el modelo procesó? ¿El objetivo es ejecutar acciones no autorizadas o exfiltrar datos? Eso es inyección de prompts. La defensa es arquitectónica y mira a la aplicación.

Muchos incidentes reales involucran ambos. Pero empezar con el marco correcto te apunta a las mitigaciones correctas.