Explicación de los jailbreaks en LLM: qué cambia un jailbreak y por qué no es abliteración

En julio de 2023, tres investigadores lanzaron 32 prompts dañinos contra GPT-4 y Claude 1.3 mediante 28 ataques distintos. La técnica individual más potente —tres familias de ataques apiladas unas sobre otras— logró abrirse paso en el 94 por ciento del conjunto contra GPT-4 y en el 81 por ciento contra Claude 1.3. Lo que cerró el conjunto no fue un ataque mejor, sino una elección: un adversario al que se le permitió elegir cuál de los 28 funcionaba mejor para cada prompt consiguió que los 32 pasaran en ambos modelos, algo que el artículo reporta como un 1.00 limpio. La lectura incómoda es que un jailbreak no es un defecto que desaparece cuando el modelo se vuelve más inteligente o se comporta mejor. Es una propiedad del prompt, y el prompt pertenece a quien lo envía. Lo que ocurre después de que cesa la negativa —la llamada a la herramienta, la lectura del archivo, la salida que acaba en algún lugar que actúa sobre ella— es la parte que el archivo de incidentes de IA se creó para registrar.

Ese encuadre merece precisión, porque «jailbreak» se usa para varias cosas distintas y las diferencias determinan qué puede siquiera hacer cualquier mitigación. Este artículo abarca qué edita un jailbreak, qué dicen realmente las cifras medidas, por qué no existe una respuesta por modelo a «¿es jailbreakeable?» y dónde la técnica deja de ser una cuestión de seguridad del modelo y pasa a serlo de seguridad del sistema.

Un jailbreak es una modificación del prompt, no del modelo.

El modelo permanece exactamente tal como se distribuye. No se reentrena nada, no se tocan los pesos, no se aplica ningún ajuste fino. El atacante modifica la solicitud para que cumplirla se convierta en la continuación localmente correcta, y el comportamiento de seguridad que se entrenó en el modelo pierde frente a una instrucción competidora que también se le entrenó para seguir.

Esa sola frase descarta una gran categoría de supuestas soluciones. No puedes parchearlo en los pesos — no hay nada malo con los pesos. No puedes enumerarlo, porque el espacio de prompts es abierto. Y no puedes comprobarlo una sola vez, porque la técnica que falla hoy no es la que se probará mañana. Lo que sí puedes hacer es medir una tasa, sobre un conjunto fijo de prompts, contra una versión fija del modelo, y luego observar cómo se mueve esa tasa cuando cualquiera de esos tres cambia.

Lo que realmente midió el experimento de 32 prompts

El estudio es Jailbroken: How Does LLM Safety Training Fail? de Alexander Wei, Nika Haghtalab y Jacob Steinhardt, publicado en arXiv en julio de 2023 como 2307.02483. Su conjunto de pruebas constaba de 32 indicaciones dañinas —la mitad extraídas de una evaluación de GPT-4 publicada y la mitad adaptadas de un trabajo publicado de red teaming sobre Claude—, y su medida de resultado es contundente: un caso se puntúa como éxito cuando la respuesta es a la vez dañina y pertinente para la solicitud original. Cualquier cosa que se detenga, desvíe o responda a una pregunta diferente no cuenta.

Dos propiedades de los resultados son más útiles que cualquier fila individual. La primera es lo desigual que resulta la transferencia de ataques entre modelos. AIM role-play obtuvo 0,75 contra GPT-4 y 0,00 contra Claude 1.3. Few-shot JSON obtuvo 0,53 y 0,00. Mientras tanto, la codificación Base64 presentó el tipo inverso de desigualdad —0,34 en GPT-4 y 0,38 en Claude 1.3—, y los distractores quedaron en 0,44 y 0,47. Una técnica contra la que un proveedor claramente ha entrenado se lee como un cero en ese modelo y no dice nada sobre el modelo que tiene al lado.

El segundo es lo que ocurre cuando se combinan familias. La inyección de prefijos, junto con la supresión de rechazos y Base64, produjo 0,56 frente a GPT-4 y 0,66 frente a Claude 1.3. Añadir inyección de estilo lo llevó a 0,69 y 0,84. Añadir la generación de contenido web y restricciones de formato lo llevó a 0,94 y 0,81. El apilamiento es todo el truco: cada capa es algo para lo que el modelo fue entrenado, y la combinación no deja ninguna posición de token donde negarse sea la continuación más natural.

Los modelos de esa tabla tienen tres años y ya no son lo que está desplegando nadie. Los números no son lo importante; la forma lo es. Todos los mecanismos de la tabla siguen vigentes en todos los modelos posteriores, porque ninguno de ellos fue nunca un error en GPT-4 o Claude 1.3: son consecuencias de cómo interactúan el seguimiento de instrucciones y el entrenamiento en seguridad.

Dos formas en que falla la capacitación en seguridad

La explicación del artículo es inusualmente clara, y es la parte que vale la pena llevar consigo: hay dos modos de fallo, y cada ataque de la tabla es una instancia de uno de ellos.

Los objetivos en conflicto son lo que se obtiene cuando las capacidades de un modelo y sus objetivos de seguridad apuntan en direcciones diferentes. El seguimiento de instrucciones es una capacidad. Cuando la solicitud se envuelve de tal manera que negarse violaría una instrucción que el modelo está fuertemente entrenado para obedecer, el modelo resuelve el conflicto a favor de la instrucción. La inyección de prefijo es la versión mínima: dígale al modelo que su respuesta debe comenzar con «¡Por supuesto! Aquí tienes», y los primeros tokens ya son un compromiso que hace que la negativa sea incoherente. La supresión de negativas ataca la misma costura desde el otro lado, añadiendo reglas de formato que prohíben la oración en la que tendría que formularse una negativa.

Generalización desajustada es lo que se obtiene cuando el entrenamiento de seguridad abarca una distribución de entrada estrecha que la capacidad general del modelo no cubre. El modelo aprendió Base64 durante el preentrenamiento y puede seguir una instrucción codificada perfectamente. El entrenamiento de seguridad, que en su mayoría vio solicitudes en lenguaje natural, nunca le enseñó a reconocer que una solicitud codificada sigue siendo una solicitud. El mismo fallo aparece con la eliminación de vocales, ROT13, leetspeak, la división de la carga útil y las tareas distractoras: cada uno es un formato al que la capacidad generaliza pero el comportamiento de seguridad no.

Una vez que tienes esas dos categorías, los ataques dejan de parecer una mezcla heterogénea de trucos y empiezan a parecer dos familias con una causa raíz común — lo cual también explica por qué se combinan tan bien. Un prompt que suprime el rechazo y oculta su intención en una codificación está explotando ambos modos de fallo a la vez, y 0.94 es lo que eso parece.

¿Por qué no hay una respuesta por modelo a «¿es posible hacerle jailbreak?»

La forma de consulta más común en este ámbito es el nombre de un modelo seguido de la palabra jailbreak. Es la unidad de análisis equivocada, y la razón es la tabla anterior. El éxito depende de al menos cinco cosas a la vez: la capacidad del modelo base, qué entrenamiento de seguridad recibió y sobre qué distribución, el formato del prompt, la configuración de muestreo y cuántos intentos está dispuesto a emplear el atacante.

El último merece su propia frase. Una tasa medida con un intento por prompt y una tasa medida con «mejor de 28» no son la misma medición, y el resultado adaptativo del artículo —1,00 en ambos modelos— es del segundo tipo. Quien cite una tasa de jailbreak sin decir a cuál se refiere no ha citado nada que sea utilizable. La pregunta defensiva realista no es «¿se puede romper?», sino «¿cuántos intentos hacen falta y hay algo en mi stack que note los intentos?».

Se derivan dos consecuencias prácticas. Un modelo que resiste tu conjunto de prompts hoy puede dejar de resistir tras una actualización de versión, un cambio en la capa de seguridad o un cambio de configuración del lado del servicio — el resultado solo es válido para la compilación que probaste, y por eso una prueba sin versión ni fecha no es un resultado. Y el mismo conjunto de prompts ejecutado contra dos modelos te dice sobre cuál es más tolerante tu stack, no cuál es seguro.

Lo que no es un jailbreak: abliteración

Estos dos se confunden constantemente porque ambos acaban con un modelo generando una salida que se le entrenó para no generar. No son la misma edición, y la diferencia es la diferencia entre un control que puedes añadir y una propiedad que no puedes.

• Jailbreak — una edición en la capa de prompt. Los pesos no cambian. La dirección de rechazo sigue presente en el modelo; simplemente se ha dispuesto la solicitud de modo que otros comportamientos la superen en prioridad. Revierte el prompt y el comportamiento se revierte con él.

• Abliteración — una edición a nivel de capas de pesos. La dirección de rechazo se identifica —normalmente como una dirección en el espacio de activación— y se proyecta fuera de los pesos del modelo, de modo que este deja por completo de producir rechazos para esa clase de solicitudes. Es un cambio permanente en el artefacto, y es la razón por la que un checkpoint abliterado se comporta de forma diferente al mismo modelo base con un prompt ingenioso. La mecánica de esa edición se explica en nuestra guía sobre abliteración.

La diferencia operativa importa más que la terminología. Un jailbreak es un evento en tiempo de ejecución: llega con una solicitud y se puede contar, limitar su tasa, filtrar y registrar como cualquier otra solicitud. Un modelo "abliterado" es un evento de la cadena de suministro: el control ya se ha eliminado antes de que lo recibas, y ningún nivel de monitoreo en la capa de prompts lo recupera. Si tu modelo de amenazas es "alguien intentará persuadir al modelo", estás en la primera categoría. Si es "alguien me enviará un modelo con la negativa eliminada", estás en la segunda, y el único control real es la procedencia: saber qué checkpoint está sirviendo realmente el endpoint.

El jailbreak tampoco es inyección de prompts

El tercer término que se mezcla es la inyección de prompts, y la pregunta que los distingue es quién es el atacante. Un jailbreak proviene del usuario, que intenta obtener contenido que el modelo fue entrenado para no revelar. La inyección de prompts proviene de contenido —un documento recuperado, una página web, el resultado de una herramienta— que contiene instrucciones que el desarrollador nunca escribió, y funciona tanto si el usuario es hostil como si no. El mismo modelo puede ser inmune a uno y estar completamente vulnerable a la otra, porque se neutralizan en lugares distintos: los jailbreaks, en la entrada y la salida del modelo; la inyección, en el límite de confianza entre los datos y las instrucciones.

¿Qué reduce realmente la tasa?

Nada de esto es una garantía, y cualquier afirmación en sentido contrario es un discurso de ventas. Lo que sigue es el conjunto de controles que cambia las cifras, ordenados según cuánto aportan en relación con el esfuerzo.

• Supón que la capa de prompt falla.Todo control que dependa de que el modelo se niegue está a solo un atacante adaptativo de quedar en cero. Diseña como si la solicitud fuera a terminar pasando, y ubica el control donde ocurriría el daño.

• Restringe lo que puede alcanzar un jailbreak exitoso. El radio de impacto de un asistente con jailbreak es todo lo que permiten sus herramientas, credenciales y alcance de recuperación. El mínimo privilegio en las herramientas y la limitación del alcance de recuperación por inquilino reducen el valor de un jailbreak exitoso de forma mucho más fiable que cualquier filtro de prompts.

• Juzga la salida, no el prompt. Los clasificadores del lado de la salida detectan familias que nunca has visto, porque miran lo que realmente se produjo en lugar de cómo se pidió. También son la única capa que sigue funcionando cuando el formato de entrada es novedoso — lo cual, según el modo de fallo de generalización desajustada, ocurre la mayor parte del tiempo.

• Trata el prompt del sistema como un valor de configuración, no como una barrera de seguridad. Es texto en la misma ventana de contexto que el ataque. Eleva el costo de un intento; no lo detiene.

• Haz visibles los intentos. La única ventaja que tiene un defensor sobre el atacante adaptativo es que el ataque suele repetirse. Los límites de tasa, la detección de repeticiones y el registro convierten una búsqueda de 28 intentos en un evento que puedes ver en lugar de 28 solicitudes que, por separado, cada una parecía estar bien.

• Vuelve a hacer la prueba con cada cambio de modelo. Fijar una versión concreta junto con un conjunto fijo de prompts es lo que convierte «lo probamos una vez» en un número con el que se puede comparar. Sin esa versión fijada, la comparación carece de sentido.

Cómo medir tu propio objetivo

Si el objetivo es un número sobre el que puedas actuar, fija las tres variables que fijó el artículo: el conjunto de prompts, la versión del modelo y el número de intentos. Usa un conjunto de prompts que incluya ambos modos de fallo —instrucciones que hagan que negarse resulte incómodo y codificaciones que oculten la solicitud—, porque un conjunto formado solo por uno favorecerá falsamente a un modelo que es débil frente al otro. Puntúa de forma conservadora: perjudicial y pertinente, no simplemente fuera de tono. Y reporta el resultado como una tasa frente a un número declarado de intentos, nunca como un sí o un no.

Cuando hay varios modelos candidatos en juego, la comparación solo funciona si el mismo conjunto de prompts se ejecuta en cada uno de ellos, y ese es el único punto en el que la infraestructura importa más que la metodología. Ejecutar una única evaluación en los modelos que enrutamos elimina el contrato por proveedor y el trabajo con el cliente del ejercicio; los precios de lista de los proveedores se trasladan sin margen, así que la ejecución cuesta lo que cobran los proveedores y nada más. Lo que evalúa la evaluación es el comportamiento del modelo, no el nuestro — el enrutamiento cambia qué modelo responde, y no hace que ninguno de ellos rechace más.

Donde retoma el registro

Una tasa de éxito medida te dice cuán difícil es derribar la capa de prompts. No te dice qué ocurrió cuando alguien la derribó en producción, y esa segunda pregunta es lo que decide si la tasa importa. Un jailbreak que produce un párrafo grosero es un problema de moderación de contenido. Un jailbreak que produce una llamada a herramienta es un incidente, y la diferencia está enteramente en hasta dónde permitió el sistema que llegara la salida.

Ese archivo es el registro de campo: lo que los agentes hicieron realmente, con una fuente para cada entrada y un veredicto sobre si alguien resultó perjudicado. Contrastado con una medición de jailbreak, responde la pregunta que la medición no puede responder: si el límite que cruzó un prompt es aquel del que depende algo aguas abajo. Si lo es, el jailbreak es un hallazgo de seguridad y el control debe estar en los permisos de las herramientas. Si no lo es, el jailbreak es un resultado de contenido, y lo honesto es registrarlo como tal en lugar de inflarlo hasta convertirlo en una vulnerabilidad.

La nota final es la que respaldan las pruebas. El jailbreaking no se resolverá con un modelo mejor, porque los modos de fallo son estructurales: el seguimiento de instrucciones es una capacidad y el entrenamiento en seguridad es otra más limitada, y la brecha entre ambas es donde vive cada ataque de este artículo. Lo que sí puede resolverse es la consecuencia: asegurándose de que un modelo que deja de negarse siga sin poder hacer gran cosa.