Trazas de moderación simuladas: jailbreak a LLM con herramientas
Un artículo de julio de 2026 muestra que se puede hacer jailbreak a LLM con llamada a funciones simulando un flujo de auditoría de seguridad entre turnos — prueba de que el filtrado a nivel de prompt no basta.
¿Qué es esto?
El 1 de julio de 2026, los investigadores Junlong Liu, Haobo Wang, Weiqi Luo y Xiaojun Jia publicaron en arXiv (cs.CR) un artículo que sostiene que la investigación sobre jailbreaks está mirando la capa equivocada. Los trabajos previos estudian ataques y defensas a nivel de un único prompt. Pero las aplicaciones modernas casi nunca entregan al modelo un prompt limpio y aislado: ejecutan bucles de llamada a funciones, donde los esquemas de herramientas definidos por el desarrollador, los argumentos estructurados y las salidas de herramientas no confiables se entrelazan en un mismo contexto compartido, turno tras turno.
Los autores muestran que esta arquitectura genera una debilidad estructural independiente de cualquier cadena maliciosa concreta. Para demostrarlo introducen SMT (Simulated Moderation Traces), un ataque de caja negra que reparte la intención adversaria a lo largo de una trayectoria de llamadas a herramientas multiturno en lugar de concentrarla en una sola petición. La contribución es defensiva por vocación: expone dónde son blandos los sistemas con herramientas para que quienes los construyen puedan endurecerlos.
Cómo funciona
La idea central es arquitectónica, no una frase mágica. En una aplicación con llamada a funciones, el contexto del modelo mezcla dos cosas que deberían permanecer separadas: la lógica de control confiable (los esquemas de herramientas y la estructura de argumentos que definió el desarrollador) y los datos no confiables (todo lo que devuelve una herramienta, más la conversación acumulada). Cuando ambas conviven en un contexto indiferenciado, un atacante puede hacer que el contenido no confiable se haga pasar por lógica de control.
SMT lo consigue disfrazando toda la conversación de auditoría de moderación legítima — presentando al modelo como pieza de un pipeline de pruebas red team cuya tarea es ayudar a «evaluar» contenido peligroso. Lo decisivo es que la trayectoria trata luego cada rechazo de seguridad no como una respuesta correcta sino como un fallo de ejecución que hay que «corregir», provocando refinamientos que erosionan gradualmente las restricciones del modelo turno tras turno, hasta que se cuela una salida dañina. Ningún mensaje aislado parece manifiestamente malicioso; la intención se distribuye por el camino y se blanquea mediante el pretexto de un proceso de seguridad. (Este resumen omite deliberadamente la plantilla de traza y el procedimiento paso a paso.) Evaluada en caja negra contra LLM comerciales de cinco proveedores distintos sobre dos benchmarks de seguridad estandarizados, la técnica alcanza la mayor tasa de éxito media y el mayor HarmScore requiriendo un número de consultas casi mínimo.
Por qué importa
La conclusión es tajante: la sola desinfección a nivel de prompt — filtros de entrada, clasificadores por mensaje, listas de bloqueo por regex — es estructuralmente insuficiente para los sistemas con herramientas. El ataque no reside en ningún prompt único; vive en la conversación y el estado de herramientas acumulados, de modo que una defensa que solo inspecciona el último mensaje del usuario nunca lo ve venir.
Quien despliega agentes o asistentes con bucles de herramientas multiturno hereda esta superficie, y el encuadre de «auditoría de moderación» es especialmente corrosivo porque secuestra el vocabulario de la propia seguridad: se convence al modelo de bajar la guardia en nombre de hacer trabajo de seguridad. A medida que la llamada a funciones se vuelve el patrón de integración por defecto, las defensas diseñadas para la era del prompt único envejecen mal.
Defensas
Validar todo el estado, no el último mensaje. La recomendación central del artículo es una validación sensible al contexto que abarque esquemas, argumentos, salidas de herramientas y conversación acumulada — la frontera que el ataque borra es justamente la que su defensa debe reconstruir.
Tratar las salidas de herramientas y el metaencuadre como datos no confiables. Una conversación nunca debería poder reclasificarse a sí misma como sesión autorizada de auditoría, red team o evaluación. «Solo estamos probando la seguridad» afirmado dentro del chat no es una autorización.
No dejar que los rechazos se conviertan en fallos reintetables. Limite la resolicitud de una petición bloqueada y detecte el patrón de escalada en que la misma intención denegada se reformula y reenvía a lo largo de los turnos.
Supervisar trayectorias, no solo turnos. Puntúe el camino multiturno buscando deriva hacia salidas dañinas; las defensas por mensaje pierden la intención diluida en muchos pasos.
Aislar los modos de evaluación reales fuera de banda. Si realmente ejecuta flujos de red team o moderación, autorícelos por un canal separado y autenticado — nunca un rol que la conversación pueda simplemente reclamar.
Estado
| Elemento | Referencia | Notas |
|---|---|---|
| Publicación | arXiv:2607.00481, 1 de julio de 2026 | «Beyond the Prompt», framework de ataque SMT (cs.CR / cs.AI) |
| Autores | Mismo artículo | Junlong Liu, Haobo Wang, Weiqi Luo, Xiaojun Jia |
| Alcance | Mismo artículo | LLM con llamada a funciones / herramientas; trayectoria multiturno |
| Evaluación | Mismo artículo | LLM comerciales de cinco proveedores, dos benchmarks de seguridad estandarizados |
| Resultado | Mismo artículo | Mayor tasa de éxito media y HarmScore, consultas casi mínimas |
| Código | GitHub (liujlong27/SMT) | Publicado por los autores |
La enseñanza duradera es una frontera, no un benchmark: en un sistema con llamada a funciones, la lógica de control y los datos no confiables comparten un mismo contexto, y la seguridad debe aplicarse sobre todo el estado acumulado — esquemas, argumentos, salidas de herramientas e historial de conversación — en lugar de un prompt a la vez.