¿Qué hace peligrosa la «capa de control» para los agentes LLM?
Los modelos de lenguaje modernos rara vez trabajan en solitario. Con mayor frecuencia se despliegan dentro de un arnés de agente — una capa intermedia que otorga al modelo acceso a herramientas, extensiones, memoria a largo plazo, permisos y acciones externas. Es precisamente esta capa la que decide qué puede hacer el modelo y qué no.
El problema es que los benchmarks de seguridad existentes suelen verificar únicamente escenarios de ataque aislados o un conjunto limitado de condiciones operativas. Debido a esto, resulta difícil comprender en qué etapa exacta del funcionamiento del arnés se produce el fallo: durante la configuración, en el momento de la invocación de una herramienta o al recuperarse de un incidente. Los investigadores propusieron HarnessRisk, un benchmark que examina la seguridad del arnés de agente en su totalidad, en todas las etapas de su ciclo de vida.
Seis fases del ciclo de vida del arnés
Los autores del trabajo dividieron la seguridad del arnés en seis fases operativas:
- Harness Configuration — configuración de parámetros y derechos de acceso;
- Capability Extension — conexión de nuevas capacidades y extensiones;
- Runtime Operation — ejecución de tareas en tiempo real;
- State Persistence — guardado y restauración del estado;
- Action Control — control sobre las acciones y herramientas;
- Incident Recovery — reacción ante fallos y recuperación tras incidentes.
Cada fase es responsable de su propia área de responsabilidad, y las vulnerabilidades pueden manifestarse en cualquiera de ellas. Es precisamente esta división la que permite comparar cómo distintos arneses manejan ataques en condiciones idénticas.
Qué hay dentro de HarnessRisk: escenarios y métricas
El benchmark reúne 128 escenarios aislados. Cada escenario está diseñado de forma ingeniosa: ante el modelo se plantea una tarea de usuario segura, pero dentro de un artefacto no confiable del flujo de trabajo se oculta una instrucción hostil. El modelo debe cumplir el objetivo legítimo sin sucumbir al ataque incrustado en el artefacto.
Cada trayectoria se evalúa según cuatro métricas:
- Utility — qué tan bien se ha completado la tarea original;
- Attack Success Rate — proporción de ataques ejecutados con éxito;
- Persistence — cuánto tiempo persiste el efecto del ataque;
- Detection — con qué eficacia el sistema detecta los riesgos.
Este enfoque permite ver no solo «fue vulnerado o no», sino también el costo de la seguridad para la utilidad del modelo.
Qué mostraron las pruebas
Los experimentos se llevaron a cabo en tres arneses, seis modelos de lenguaje y 14 combinaciones de modelos y arneses. Los resultados resultaron heterogéneos: la tasa de éxito de los ataques varió del 12,6% al 80,9%, mientras que Utility se mantuvo en un rango del 75,0% al 97,6%. En términos simples, un mismo modelo puede ser casi invulnerable en una configuración y abiertamente débil en otra.
La fase más vulnerable en los tres arneses es Harness Configuration. Los ataques suelen tener éxito no por exploits complejos, sino porque dentro del flujo de trabajo «permitido» se pueden modificar parámetros que afectan la seguridad. Esta es una señal alarmante: incluso un arnés de apariencia correcta puede permitir que un atacante cambie las reglas del juego.
Un resultado curioso está relacionado también con el reconocimiento de riesgos. Algunas configuraciones detectan ataques en más del 90% de las ejecuciones, pero aun así permiten una proporción significativa de ataques exitosos. Es decir, el modelo «comprende» que está ocurriendo algo peligroso, pero no convierte esa comprensión en un comportamiento seguro. La conciencia de la amenaza por sí sola no protege el sistema.
Conclusiones: la seguridad no se puede medir «en promedio»
La principal lección de HarnessRisk es que la seguridad de los sistemas de agentes depende en gran medida de la combinación específica de modelo y arnés. Las evaluaciones promedio de «el modelo es seguro» o «el arnés es seguro» dicen poco si no se tiene en cuenta en qué configuración operan.
Es necesario evaluar a los agentes de inmediato en varias áreas de responsabilidad del arnés — desde la configuración inicial hasta la recuperación tras incidentes. Y verificar por separado cómo se comporta el modelo ante un ataque incrustado en un artefacto de trabajo habitual. Solo así se pueden detectar los puntos débiles que en los benchmarks clásicos quedan fuera de escena.
