Probar la seguridad de agentes autónomos con especificaciones y trayectorias
Un marco de junio de 2026 genera tareas de seguridad a partir de especificaciones de riesgo y evalúa toda la trayectoria de ejecución —no solo la respuesta final— para detectar llamadas a herramientas peligrosas antes de que se manifiesten.
¿Qué es esto?
En junio de 2026, un artículo titulado SeClaw: Spec-Driven Security Task Synthesis for Evaluating Autonomous Agents (arXiv:2606.02302) propuso una forma de construir y ejecutar pruebas de seguridad para agentes LLM con herramientas. Los autores describen su trabajo como preliminar y todavía en curso, pero el planteamiento merece atención desde ahora, porque aborda un problema de medición que la mayoría de los equipos que despliegan agentes ya tienen. Los agentes modernos ya no se limitan a responder: leen archivos, invocan herramientas, mantienen memoria persistente y acceden a servicios externos. Esa autonomía ampliada es justamente lo que hace difícil medir su seguridad.
El argumento del artículo es que los benchmarks de seguridad de agentes existentes comparten tres debilidades. Se apoyan en tareas curadas manualmente, difíciles de escalar y limitadas por lo que un anotador humano pensó en escribir. Cubren solo una parte del panorama de amenazas, porque un conjunto fijo de instancias no puede ampliarse con facilidad a nuevos riesgos. Y juzgan a un agente sobre todo por su respuesta final, cuando un comportamiento peligroso suele ser una secuencia de acciones que ocurre antes de que aparezca nada en el último mensaje. SeClaw responde a esas tres carencias.
Cómo funciona
Aquí se describe un marco de evaluación, no un ataque, y no se incluye ningún payload. SeClaw tiene dos partes.
La primera es la síntesis de tareas guiada por especificación. Los autores organizan el riesgo de los agentes en cuatro fuentes: los recursos (prompts de sistema, skills, memoria, servidores MCP), las tareas del usuario, la realimentación del entorno (páginas web, salidas de herramientas, archivos) y los defectos intrínsecos del modelo o del framework. Un experto humano, asistido por un agente de código, redacta una especificación estructurada para un riesgo objetivo: el punto de riesgo, el rol del agente, la tarea vista por el usuario, el origen del peligro, el comportamiento inseguro a probar y las restricciones de seguridad. Un pipeline multiagente convierte luego esa especificación en un prototipo de tarea, la instancia en una tarea ejecutable con un espacio de trabajo real, servicios simulados, archivos y herramientas configuradas, y ejecuta un bucle de validación que solo conserva las tareas resolubles, reproducibles y que realmente discriminan entre modelos débiles y fuertes.
La segunda parte es la evaluación basada en ejecución. Cada tarea se ejecuta en un entorno aislado (sandbox) de Docker, con un contenedor nuevo por instancia, de modo que el estado no se filtra de una ejecución a otra. SeClaw registra toda la trayectoria —prompts, decisiones del modelo, llamadas a herramientas, respuestas de servicios, operaciones de archivos y artefactos finales— y no solo la respuesta. La puntuación es deliberadamente bidimensional: un término de cobertura, para cuántos objetivos de seguridad distintos se alcanzan, y un término de fiabilidad, para con qué constancia se activan las condiciones peligrosas, combinados mediante una media armónica. Los autores insisten en que esta puntuación está orientada al riesgo: un valor más alto significa que el modelo evaluado es más vulnerable, no más capaz.
Por qué importa
Una evaluación centrada en el resultado supone de forma implícita que el peligro de un agente es visible en su respuesta final. A menudo no lo es. Un agente puede filtrar una credencial, sobrescribir un archivo o encadenar dos herramientas benignas en una acción dañina varios pasos antes de producir un resumen que un evaluador vaya a leer. Puntuar la trayectoria permite atribuir un fallo a una etapa concreta —interpretación del modelo, selección de acción, invocación de herramienta o respuesta del entorno—, lo que hace que un resultado sea reproducible y comparable entre agentes.
La parte de síntesis importa igual. Las amenazas a los agentes evolucionan más rápido de lo que los benchmarks escritos a mano pueden seguir, y un marco que genera tareas frescas y específicas de un escenario, a partir de una taxonomía de riesgos, se acerca más a cómo evoluciona la exposición real. Es el mismo giro hacia una evaluación con estado, a nivel de proceso, que se ve en trabajos contemporáneos como SABER, y que prolonga el enfoque de entorno-en-el-bucle que estableció AgentDojo para la inyección de prompts.
Defensas
Puntúe el proceso, no solo la respuesta. Si su evaluación de agentes solo comprueba la salida final, está ciega ante la cadena de llamadas a herramientas que la produjo. Registre y puntúe toda la trayectoria para que una invocación peligrosa se detecte incluso cuando el mensaje final parece limpio.
Aísle cada ejecución de prueba. Use sandboxes por tarea, con un contenedor por instancia, límites de recursos y control de permisos, para que un estado residual no contamine la siguiente ejecución y una prueba que se descontrola no pueda tocar el host.
Cubra las cuatro fuentes de riesgo. Recursos, tareas, entorno y defectos intrínsecos fallan de forma distinta. Una batería que solo prueba la inyección indirecta desde la web pasa por alto el abuso de privilegios, la denegación de servicio por abuso de recursos y el encadenamiento peligroso de herramientas que nacen en otro sitio.
Mantenga humanos en los controles de calidad. La síntesis automática escala la cobertura, pero el significado de seguridad de cada tarea —qué cuenta como inseguro, y por qué— exige revisión humana. Trate las pruebas generadas como candidatas que superan comprobaciones explícitas, no como verdad establecida.
Haga la evaluación continua. Un benchmark congelado caduca. Regenere las tareas a medida que aparecen nuevas clases de riesgo y vuelva a ejecutarlas con cada actualización de agente y de modelo, en lugar de certificar un agente una sola vez.
Estado
| Elemento | Referencia | Fecha | Notas |
|---|---|---|---|
| Artículo | arXiv:2606.02302 | junio 2026 | Síntesis de tareas guiada por especificación + evaluación por trayectoria; descrito como trabajo preliminar en curso |
| Taxonomía de riesgo | Recursos, tareas, entorno, intrínseco | — | Cuatro fuentes de riesgo de agente usadas para guiar la generación de tareas |
| Método | Síntesis multiagente → ejecución en sandbox Docker → registro de trayectoria → puntuación orientada al riesgo | — | Un contenedor por instancia; cobertura + fiabilidad combinadas por media armónica |
| Relacionados | SABER; AgentDojo | 2024–2026 | Evaluación de seguridad de agentes con estado / entorno-en-el-bucle |
SeClaw no afirma volver seguros a los agentes: sostiene que no se puede gestionar lo que no se mide, y que medir la seguridad de un agente significa observar toda la ejecución, no solo la última línea. Para los equipos que despliegan agentes con herramientas, la lección es estrecha y verificable: construya la evaluación en torno a trayectorias y ejecución aislada, cubra fuentes de riesgo más allá de la que ya teme, y regenere las pruebas sin cesar a medida que la superficie de ataque se mueve.