La brecha de seguridad en frío: el agente es menos seguro en el primer turno

¿Qué es esto?

Un preprint publicado en arXiv el 5 de junio de 2026 (2606.07867) expone una propiedad contraintuitiva de los agentes LLM que invocan herramientas: no son igualmente seguros a lo largo de una conversación. Un agente es más vulnerable en el primer turno de una sesión y se vuelve medible­mente más difícil de manipular tras completar unas pocas tareas ordinarias y anodinas. Los autores —Chung-En Sun, Linbo Liu y Tsui-Wei Weng, del Trustworthy-ML-Lab— denominan a este fenómeno la brecha de seguridad en frío (cold-start safety gap).

La magnitud de la brecha no es marginal. En 7 modelos de 4 familias, el rechazo de solicitudes dañinas mejora entre un 9 % y un 52 % a medida que el número de tareas anodinas previas pasa de cero a veinte. El mismo modelo, con el mismo prompt de sistema, se deja empujar mucho más fácilmente hacia un uso dañino de las herramientas cuando la solicitud maliciosa llega primero, antes de cualquier trabajo normal en la sesión.

Cómo funciona

Para medir el efecto con limpieza, el artículo introduce un banco de pruebas llamado SODA (Safety Over Depth for Agents). SODA varía una sola variable: cuántas tareas agénticas ordinarias completa el agente antes de encontrar una solicitud crítica para la seguridad, admitiendo profundidades de hasta 20 tareas previas. Al mantener fija la solicitud dañina y variar solo la profundidad, los autores aíslan la profundidad de la conversación como causa, en lugar de la redacción del prompt o la versión del modelo.

El mecanismo es visible en las representaciones internas del modelo. Un análisis de representaciones muestra que los estados ocultos se desplazan hacia una región alineada con la seguridad del espacio de activación a medida que las tareas anodinas se acumulan en el contexto: el modelo, en efecto, «entra en calor» hacia un modo de funcionamiento más seguro. Los autores diseccionan luego qué parte de la conversación previa hace el trabajo, y la respuesta es precisa: las tareas ordinarias en sí son el motor principal de la ganancia de seguridad, mientras que las respuestas previas del propio agente aportan poco a la seguridad pero son necesarias para preservar la utilidad posterior. Si se eliminan las tareas anodinas, la seguridad recae al nivel del arranque en frío; si se eliminan las respuestas del agente, permanece seguro pero pierde capacidad en el trabajo posterior.

Los resultados se reproducen en bancos de pruebas independientes y públicos —AgentHarm y Agent Safety Bench para la seguridad, y BFCL y API-Bank para la utilidad—, lo que distingue este trabajo de una curiosidad propia de un único montaje. Aquí no se reproduce ninguna cadena de jailbreak; la contribución es diagnóstica. Se inscribe en la línea establecida de trabajos de medición del abuso de agentes, como AgentHarm (2410.09024), que ya había mostrado que los agentes basados en modelos de frontera son sorprendentemente dóciles ante tareas maliciosas, incluso sin jailbreak.

Por qué importa

La mayor parte de la evaluación de seguridad de los agentes se hace en una sesión nueva y de un solo turno: se instancia el agente, se envía el prompt dañino y se anota si rechaza. Este artículo señala que ese protocolo mide al agente en su punto de seguridad más desfavorable y luego lo lleva a producción. Una validación de red team obtenida en el primer turno no describe el comportamiento del agente en el turno diez y, sobre todo, un atacante que alcanza al agente primero, antes de cualquier uso legítimo, lo golpea justo donde es más débil.

Esto tiene consecuencias directas sobre cómo se exponen los agentes. Un agente recién instanciado y entregado directamente a una entrada no confiable —una sesión nueva disparada por un correo entrante, un webhook, un mensaje de cliente o un agente efímero que arranca en frío en cada solicitud— se encuentra por diseño en la zona de arranque en frío. Las mismas arquitecturas que se adoptan para el aislamiento (un agente nuevo por tarea, sin historial compartido) pueden maximizar la exposición que describe este artículo.

Defensas

• Caliente al agente antes de exponerlo a entradas no confiables. La recomendación principal del artículo: hacer que el agente complete unas pocas tareas agénticas ordinarias y anodinas al inicio de la sesión antes de que pueda recibir solicitudes críticas. Esto lo desplaza hacia la región de representación más segura preservando su plena capacidad, sin reentrenamiento.
• Deje de evaluar la seguridad solo en el primer turno. Trate la profundidad de la conversación como un eje de evaluación explícito. Mida las tasas de rechazo en la profundidad 0 y en profundidades de operación realistas, y condicione el despliegue a la cifra de arranque en frío, pues es lo que afronta un atacante temprano.
• Sea deliberado con los agentes efímeros por solicitud. Crear un agente nuevo y frío en cada solicitud entrante es bueno para el aislamiento pero coloca cada solicitud en el estado de seguridad más débil. Si usa este patrón, combínelo con una secuencia de calentamiento o con un filtrado externo reforzado en los primeros turnos.
• Mantenga la seguridad fuera del modelo durante la ventana en frío. Como la brecha es máxima antes de que se acumule contexto, no confíe solo en el rechazo a nivel de modelo al inicio de la sesión. Coloque el filtrado de entrada/salida, el control de permisos de herramientas y la validación humana en los primeros turnos, los de mayor riesgo.
• Vuelva a validar tras cada actualización. La magnitud de la brecha variaba entre los 7 modelos probados; la profundidad de calentamiento que basta para un modelo puede no transferirse. Vuelva a medir la relación profundidad/seguridad en la build exacta que despliega.

Estado

Elemento	Detalle
Artículo	«The Cold-Start Safety Gap in LLM Agents»
ID arXiv	2606.07867 (cs.CL)
Publicado	5 de junio de 2026
Autores	Chung-En Sun, Linbo Liu, Tsui-Wei Weng (Trustworthy-ML-Lab)
Banco de pruebas	SODA (Safety Over Depth for Agents), hasta 20 tareas previas
Alcance	7 modelos, 4 familias
Resultado clave	La seguridad mejora entre 9 % y 52 % de 0 a 20 tareas anodinas previas
Motor del efecto	Las tareas anodinas (no las respuestas del agente) impulsan la ganancia de seguridad
Verificaciones cruzadas	AgentHarm, Agent Safety Bench (seguridad); BFCL, API-Bank (utilidad)
Naturaleza	Estudio de medición defensiva — código publicado, sin payloads de explotación