Cuando el agente ignora las precondiciones de un skill: el estudio SLBench

¿Qué es esto?

El 13 de julio de 2026, Xuan Chen, Chengpeng Wang, Lu Yan y Xiangyu Zhang publicaron en arXiv (cs.CR / cs.SE) el artículo SLBench: Evaluating How LLM Agents Follow Logical Relations in Skills. Examina una parte de la pila agéntica que ha crecido deprisa y se ha auditado despacio: los skills de agente — esos procedimientos reutilizables, conjuntos de herramientas y flujos de trabajo especializados que se entregan a un agente para que realice una tarea para la que el modelo base nunca fue ajustado.

La observación de partida de los autores es sencilla y, una vez enunciada, difícil de ignorar. Un archivo de skill no es una lista plana de pasos. Sus instrucciones se relacionan lógicamente entre sí: algunos pasos solo tienen sentido cuando ha pasado una comprobación previa, y otros solo son seguros si se realizan de una manera concreta. Si el agente ejecuta el skill sin honrar esas relaciones, puede llevar a cabo una acción que el propio skill fue escrito para prohibir, aparentando, paso a paso, que sigue las instrucciones. SLBench sirve para medir con qué frecuencia ocurre eso.

Cómo funciona

El artículo presenta un marco llamado SkillLogic que analiza las relaciones lógicas dentro de un archivo de skill y las convierte en pruebas ejecutables. Su taxonomía cubre ocho tipos de relación. Dos se nombran de forma explícita y bastan para ver la forma del problema: las precondiciones, que determinan si una acción es válida, y las restricciones, que limitan cómo puede realizarse una acción permitida.

Conviene leer esas dos categorías como lógica de seguridad, no como mera ergonomía. Una precondición es la diferencia entre «elimina los archivos temporales» y «elimina los archivos temporales después de confirmar que la copia de seguridad terminó». Una restricción es la diferencia entre «envía el resumen» y «envía el resumen solo al solicitante». La instrucción que el agente debe obedecer no es el imperativo aislado, sino el imperativo con su guarda. SLBench construye sus casos de prueba directamente a partir de las relaciones del skill: un fallo se define frente a la intención declarada del skill — al agente no se le juzga con un reglamento externo, sino por si respetó la lógica que se le entregó.

Este texto describe un método de evaluación, no un exploit. Aquí no hay payload: la contribución es una lente para detectar dónde un agente deja caer en silencio la cláusula de guarda y ejecuta la acción desnuda.

Por qué importa

Los skills se están convirtiendo en una superficie de cadena de suministro. Se descargan de registros, se comparten entre equipos y cada vez los redactan otros modelos; cada uno es un bloque de instrucciones en lenguaje natural que el agente seguirá con la autoridad del usuario. La mayor parte del trabajo existente sobre seguridad de skills se ha centrado en el skill como portador de contenido malicioso — inyección de prompt oculta, permisos demasiado amplios, descripciones manipuladas. SLBench señala un fallo más silencioso que no requiere ningún atacante: un skill perfectamente benigno cuyas precondiciones y restricciones el agente simplemente no aplica.

Ese fallo agrava los que la comunidad ya vigila. Un agente que ignorase de forma fiable las restricciones convertiría un modesto punto de apoyo de inyección indirecta en uno mayor, porque las barreras de «haz X solo del modo Y» escritas en skills de confianza no se sostendrían de verdad. Y como la brecha tiene que ver con el seguimiento lógico de instrucciones y no con texto obviamente dañino, se escapa de los escáneres que buscan contenido malo en lugar de condiciones omitidas.

Defensas

La lección práctica es tratar las relaciones lógicas de un skill como política aplicable, no como sugerencias corteses que el modelo puede resumir y olvidar. En concreto: extraer las precondiciones y restricciones de un skill antes de ejecutarlo, y hacer cumplir las más importantes en una capa determinista alrededor del agente en lugar de confiar en la memoria del modelo a mitad de la trayectoria — una compuerta que rechaza la llamada «eliminar» hasta observar el estado «copia confirmada» no depende de la atención del modelo.

Segundo, probar los skills como hace SLBench antes de desplegarlos: generar comprobaciones ejecutables a partir de las relaciones propias de cada skill y confirmar que el agente honra precondiciones y restricciones en condiciones realistas, incluidas ejecuciones largas o interrumpidas donde es fácil olvidar las guardas anteriores. Tercero, mantener el mínimo privilegio por debajo de todo ello, para que, cuando se suelte una guarda, el radio de impacto quede acotado por lo que el agente ya podía hacer. Un benchmark así es más útil como puerta de regresión: un skill que hoy pasa puede dejar de pasar sin aviso en cuanto cambien el modelo base, el arnés o el texto del skill.

Estado

Elemento	Detalle
Tipo	Investigación académica (benchmark de evaluación), no una vulnerabilidad de producto
Fuente	arXiv:2607.09016 [cs.CR / cs.SE], anunciado el 13 de julio de 2026
Contribución	Marco SkillLogic + benchmark SLBench para las relaciones lógicas de los archivos de skills
Taxonomía de relaciones	Ocho tipos, incluidas precondiciones (validan una acción) y restricciones (limitan cómo se ejecuta)
CVE	Ninguno — sin fallo de producto específico