AI Sec
A network-security concept image
jailbreak

Ataques de jailbreak automatizados y el problema de transferibilidad

Cómo funciona la generación automatizada de ataques —PAIR, GCG y TAP—, por qué los jailbreaks transfieren entre familias de modelos, y qué implica para una evaluación de red team.

Por AI Sec Editorial · ·Actualizado 15 de agosto de 2026 · 8 min de lectura

La investigación sobre jailbreaks dejó de ser un ejercicio de coleccionar prompts hace tiempo. La literatura actual trata sobre generadores: bucles de optimización y modelos atacantes que fabrican prompts funcionales bajo demanda, y la propiedad que los hace portables una vez encontrados. Este artículo cubre el lado de la generación y el problema de transferibilidad. Para la taxonomía de cómo se ven los ataques resultantes, y el estado honesto de la defensa, ver la taxonomía de jailbreak de LLM.

Lo que está en juego es simple: si una evaluación de red team corre una lista estática de prompts, está midiendo la superficie de ataque de 2022. Un atacante con un modelo de pesos abiertos capaz y unas horas puede generar prompts que esa lista nunca ha visto y contra los que el objetivo nunca fue ajustado.

Tres generadores que vale la pena conocer

GCG (Greedy Coordinate Gradient). La línea base de caja blanca, de Zou et al., 2023. GCG añade un sufijo optimizado adversariamente a una solicitud dañina y corre búsqueda por gradiente sobre los tokens del sufijo para maximizar la log-probabilidad de una apertura afirmativa. La cadena resultante parece ruido para un humano y aun así dirige al modelo hacia el cumplimiento. Requiere acceso a gradientes, lo que suena como una precondición dura hasta llegar a la sección de transferibilidad.

PAIR (Prompt Automatic Iterative Refinement). De Chao et al., 2023, la primera demostración ampliamente citada de que un LLM atacante puede reemplazar al gradiente. PAIR enfrenta un modelo atacante contra el objetivo: el atacante propone un candidato, lee la respuesta del objetivo y refina. El resultado destacado es la eficiencia en consultas —jailbreaks encontrados en decenas de consultas en lugar de las decenas de miles que consume una búsqueda por gradiente— y solo necesita acceso API de caja negra.

TAP (Tree of Attacks with Pruning). Mehrotra et al., aceptado en NeurIPS 2024, es la articulación más clara de la arquitectura atacante-LLM. TAP corre el bucle de refinamiento como una búsqueda en árbol: cada nodo es una variante de prompt, el LLM atacante genera nodos hijos refinando cada candidato, y un paso de poda elimina ramas improbables antes de que lleguen al objetivo. El modelo objetivo es consultado solo para candidatos que sobreviven la poda.

El resultado es eficiencia: TAP encuentra jailbreaks para más del 80% de los prompts dañinos probados contra GPT-4-Turbo y GPT-4o, y lo hace consultando el modelo objetivo muchas menos veces que alternativas basadas en gradientes. Contra GPT-4o específicamente, TAP superó al método de caja negra estado-del-arte previo (PAIR) encontrando jailbreaks para 16% más prompts mientras requería 60% menos consultas al objetivo. El paso de poda no es decorativo —es el mecanismo que hace al enfoque práctico a escala—.

El paradigma atacante-LLM también maneja defensas más adaptativamente que prompts estáticos. Cuando un prompt candidato dispara un rechazo, el LLM atacante recibe esa retroalimentación y ajusta. Puede reformular la solicitud, embeberla en un contexto ficticio, añadir framing de legitimidad, o cambiar de fraseo directo a indirecto —el mismo repertorio que un red teamer humano experto—.

Por qué los ataques transfieren entre familias de modelos

Un hallazgo recurrente en la investigación de jailbreak LLM es que los prompts construidos contra un modelo funcionan en otros. TAP logra altas tasas de transferencia entre variantes GPT-4, modelos Claude y Llama 2/3. Esto no es obvio: distintas familias tienen distinto entrenamiento de rechazo, distintos prompts de sistema, y distintos modelos de recompensa RLHF. ¿Por qué funciona el ataque entre ellos?

La encuesta de Yi et al. 2024 atribuye la transferibilidad a propiedades estructurales compartidas de los modelos grandes. Todos los modelos de frontera entrenados con corpus similares y arquitecturas similares aprenden representaciones de características similares para el mismo contenido semántico. Un prompt que alcanza contenido prohibido construyendo un contexto ficticio de investigación no está explotando una peculiaridad específica de GPT; está explotando la propiedad general de que los modelos seguidores de instrucciones priorizan coherencia en contexto.

La transferibilidad tiene una implicación operacional directa: si un atacante puede acceder a cualquier modelo de pesos abiertos suficientemente capaz, puede usarlo para desarrollar prompts de ataque que funcionen contra modelos cerrados propietarios. No necesita acceso API al objetivo para desarrollar ataques. Lo necesita solo para verificar y desplegar. Esto invierte la suposición usual de que el rate limiting de API y los controles de acceso restringen el desarrollo de ataques: esos controles acotan la fase de verificación, que es la fase barata.

Para GCG la inversión es aún más marcada. La precondición que parecía prohibitiva (acceso a gradientes) la satisface cualquier modelo de pesos abiertos en una GPU de consumo, y la salida es una cadena portable. La optimización de caja blanca contra un sustituto accesible es cómo se atacan objetivos de caja negra.

La transferencia no es universal, y las excepciones son informativas. Los prompts que explotan una estructura específica de prompt de sistema o un esquema de herramientas específico no transfieren, porque son artefactos del despliegue y no propiedades del modelo. Los prompts que explotan la coherencia en contexto sí transfieren, porque todo modelo ajustado a instrucciones tiene esa propiedad. Regla práctica: cuanto más depende un payload de la configuración del objetivo, menos transfiere; cuanto más depende de cómo se comportan los transformers, más lo hace.

Cómo se ve el pipeline automatizado en la práctica

Para un engagement de red team contra un producto basado en LLM, el pipeline automatizado tiene tres etapas:

Etapa 1 — Especificación de objetivos. Define los comportamientos objetivo: qué categorías de contenido está entrenado para rechazar el modelo, qué constituiría una violación de política en este despliegue, cuál es el impacto de negocio de un bypass exitoso. Aquí se define el alcance del engagement.

Etapa 2 — Generación de ataques. Corre un LLM atacante (típicamente un modelo abierto capaz) contra el conjunto de prompts usando un bucle iterativo estilo TAP. El LLM atacante recibe cada rechazo como retroalimentación y genera el siguiente candidato. Rastrea las variantes que tienen éxito para análisis posterior y desarrollo de firmas.

Etapa 3 — Transferencia y verificación. Aplica los prompts de ataque exitosos al objetivo de producción. Mide la tasa de éxito del ataque, anota qué familias de prompt transfieren limpiamente y cuáles requieren refinamiento adicional.

Qué defiende específicamente contra un generador

La postura defensiva general en capas —normalización de entrada, monitoreo a nivel de conversación, clasificación de salida, diversidad de modelos— está cubierta en la taxonomía de jailbreak y aplica aquí sin cambios. Dos controles importan específicamente porque el atacante es un bucle de búsqueda y no una persona, y son los que más a menudo faltan:

Detección de anomalías en la estructura de consultas. Un pipeline automatizado consulta al objetivo muchas veces en rápida sucesión con prompts estructuralmente similares que difieren en pequeñas variaciones sistemáticas. Esa firma es mucho más detectable que cualquier payload individual. Identificar secuencias de prompts casi duplicados por cuenta, por clave y por origen captura la fase de desarrollo, la única ventana en que el defensor va por delante.

Rate limiting anclado a la tasa de rechazo, no al volumen. Un usuario legítimo de alto volumen produce una tasa de rechazo baja. Un bucle de búsqueda produce una alta por construcción, porque está explorando la frontera de rechazo. Estrangular por rechazos-por-sesión en lugar de solicitudes-por-sesión encarece la búsqueda en árbol sin castigar el uso legítimo.

Ninguno de los dos ayuda una vez que el atacante mueve el desarrollo fuera de línea a un modelo sustituto de pesos abiertos, que es exactamente lo que los resultados de transferibilidad abaratan. Ese es el límite honesto: un atacante que desarrolla contra un sustituto y llega con un conjunto pequeño de prompts ya verificados no presenta ningún patrón de consulta anómalo. Contra ese perfil, solo los controles del lado de la salida y de radio de impacto sostienen la defensa.

Fuentes

  1. Tree of Attacks: Jailbreaking Black-Box LLMs Automatically (Mehrotra et al., NeurIPS 2024)
  2. Jailbreaking Black Box Large Language Models in Twenty Queries — PAIR (Chao et al., 2023)
  3. Universal and Transferable Adversarial Attacks on Aligned Language Models — GCG (Zou et al., 2023)
  4. Jailbreak Attacks and Defenses Against Large Language Models: A Survey (Yi et al., 2024)