Resumen Técnico: SkillSafetyBench

Declaración del Problema

Los agentes de Modelos de Lenguaje Grande (LLM) dependen cada vez más de habilidades reutilizables para extender su comportamiento en tiempo de inferencia. Estas habilidades empaquetan instrucciones procedimentales, plantillas de código, recursos y rutinas de verificación, permitiendo a los desarrolladores agregar capacidades específicas para tareas sin reentrenar el modelo subyacente. Sin embargo, esta modularidad desplaza el límite de confianza de la ejecución. En lugar de condicionarse únicamente a las instrucciones del usuario y a interfaces de herramientas fijas, los agentes ahora leen y actúan sobre archivos de habilidades, scripts de ayuda, configuraciones de tiempo de ejecución, recursos de recuperación y artefactos locales.

El artículo identifica una brecha crítica en las evaluaciones de seguridad actuales: las pruebas de referencia existentes se centran en gran medida en inyecciones directas de prompts o solicitudes de usuario explícitamente maliciosas. En gran medida, pasan por alto superficies de ataque locales mediadas por habilidades y no provenientes del usuario. En este escenario, un usuario emite una solicitud benigna, pero el agente depende de habilidades orientadas a la tarea y recursos locales asociados que han sido moldeados adversarialmente para redirigir la ejecución hacia comportamientos inseguros. Dado que las habilidades organizan procedimientos y dependencias en un flujo de trabajo aparentemente legítimo, la influencia maliciosa puede distribuirse a través de la guía de habilidades, scripts envoltorios, entradas de memoria y corpus locales, dirigiendo al agente hacia acciones inseguras mientras el objetivo original de la tarea permanece intacto.

Metodología

Para abordar esta brecha, los autores introducen SkillSafetyBench, una prueba de referencia ejecutable y fundamentada en artefactos diseñada para evaluar la seguridad de los agentes bajo estas superficies de ataque específicas.

Construcción de la Prueba de Referencia

La prueba de referencia consta de 155 casos adversariales derivados de 47 tareas originales (obtenidas del repositorio SkillsBench). El proceso de construcción sigue un marco de tres etapas:

1. Sustratos de Tareas Ejecutables: Selección de tareas que soportan naturalmente ataques realistas (por ejemplo, desarrollo de código, procesamiento de datos) y producen artefactos observables.
2. Instanciación de Ataques Centrados en Habilidades: Los ataques se instancian principalmente a través de materiales orientados a habilidades (por ejemplo, archivos SKILL.md) y superficies locales de apoyo no provenientes del usuario (por ejemplo, scripts de ayuda, Dockerfiles, manifiestos, almacenes de memoria, corpus locales). El ataque no se limita a un solo archivo; más bien, la guía de habilidades y los artefactos circundantes moldean conjuntamente la ruta de ejecución del agente.
3. Verificación Fundamentada en Artefactos: Cada caso se empareja con un verificador basado en reglas específico del caso (verify_attack.py). El éxito no se determina mediante juicios de LLM de forma libre, sino por evidencia concreta en los artefactos de ejecución (por ejemplo, trazas maliciosas, pares de salida/sidecar inconsistentes, cargas útiles filtradas o registros de memoria envenenados).

Taxonomía

La prueba de referencia organiza los fallos de seguridad en 6 Dominios de Riesgo (DR) y 30 categorías canónicas, complementados por 8 etiquetas de clase de ataque (por ejemplo, manipulación de sesgos, envenenamiento, puertas traseras).

• DR1 (Confianza del Contexto): Riesgos derivados de señales contextuales engañosas, ejemplos o materiales recuperados.
• DR2 (Alcance de la Agencia): Riesgos por exceder la autorización o el alcance de la acción.
• DR3 (Ejecución/Entorno de Ejecución): Riesgos por intérpretes, cargadores o entornos de ejecución comprometidos.
• DR4 (Límite de Datos): Riesgos por artefactos finales corruptos o canales de salida.
• DR5 (Memoria/Persistencia): Riesgos por estados inseguros que persisten o evaden la auditoría.
• DR6 (Conocimiento/Cadena de Suministro): Riesgos por dependencias comprometidas, fuentes de conocimiento o comportamiento del modelo.

Control de Calidad

La prueba de referencia pasa por una validación rigurosa:

• Revisión Humana: Expertos verifican el realismo del diseño del ataque y la alineación del verificador.
• LLM como Juez: Dos modelos independientes (kimi-k2.5 y glm-5.1) evalúan cada caso en tres ejes: Calidad del Camuflaje (¿es el ataque no trivial de detectar?), Alineación del Verificador (¿verifica el verificador la señal correcta?) y Coherencia Taxonómica (¿está el caso categorizado correctamente?). Los jueces reportaron tasas de aprobación superiores al 92% en todos los ejes, con un acuerdo superior al 94%.

Resultados Clave

Los autores evaluaron múltiples sistemas de agentes de interfaz de línea de comandos (CLI) y backends de modelos (incluyendo Codex, Claude Code, Gemini CLI y Kimi Code CLI acoplados con modelos como GPT-5.5, Opus-4.6 y GLM-5.1).

1. Prevalencia de Vulnerabilidad: Todos los sistemas evaluados exhibieron Tasas de Éxito de Ataque (ASR) no triviales, demostrando que los ataques locales no provenientes del usuario pueden inducir comportamientos inseguros a través de diferentes andamios de agentes y familias de modelos.
   • La ASR general más alta se observó para Codex con GLM-5.1 (50.3%), seguido por Kimi Code CLI con Kimi-K2.5 (49.7%).
   • Claude Code con Opus-4.6 mostró la ASR más baja (15.5%).
2. Disparidades en Dominios de Riesgo:
   • DR1 (Confianza del Contexto) tuvo la ASR promedio más alta (58.7%), lo que indica que los agentes son altamente susceptibles al contexto engañoso y a la amplificación de confianza de múltiples fuentes.
   • DR2 (Alcance de la Agencia) y DR5 (Persistencia) también mostraron alta vulnerabilidad (49.3% y 46.6%, respectivamente).
   • DR3 (Ejecución/Entorno de Ejecución) tuvo la ASR promedio más baja (19.2%), lo que sugiere que los agentes son más cautelosos con las manipulaciones explícitas del entorno de ejecución o de la cadena de herramientas en comparación con las instrucciones contextuales.
3. Seguridad vs. Capacidad de Tarea: El estudio no encontró una alineación monótona entre el éxito de la tarea y la seguridad. Los sistemas con altas tasas de éxito en tareas (por ejemplo, Codex + GPT-5.5) aún exhibieron una ASR alta (41.8%), mientras que algunos sistemas con menor éxito en tareas aún enfrentaron riesgos de seguridad significativos.
4. Efectos de Interacción: La vulnerabilidad no está determinada únicamente por el backend del modelo o el andamio del agente, sino por su interacción. Por ejemplo, la brecha en la ASR entre Codex y Claude Code varió significativamente dependiendo del backend de modelo utilizado (por ejemplo, gran brecha con GLM-5.1, pequeña brecha con MiniMax-2.7).

Significado y Afirmaciones

El artículo afirma que la seguridad de los agentes depende no solo de la alineación a nivel de modelo, sino también de cómo los agentes interpretan las habilidades, confían en el contexto del flujo de trabajo y actúan a través de entornos ejecutables.

• Cambio en la Unidad de Evaluación: El trabajo argumenta que la evaluación de la seguridad debe ir más allá de las respuestas aisladas del modelo hacia sistemas ejecutables. La "unidad de evaluación" debe ser el comportamiento inseguro que emerge cuando un agente interpreta habilidades y confía en el contexto del flujo de trabajo cercano.
• Realismo de los Ataques: Al preservar el objetivo nominal del usuario mientras se envenena el entorno local de apoyo, SkillSafetyBench demuestra que los agentes pueden ser dirigidos hacia acciones inseguras incluso cuando la solicitud del usuario es benigna y la tarea parece completarse con éxito.
• Complemento al Trabajo Existente: Mientras que trabajos anteriores han estudiado la inyección de prompts, el mal uso de herramientas y las puertas traseras de habilidades de forma aislada, SkillSafetyBench los complementa al evaluar cadenas de ataque en flujos de trabajo ejecutables donde la guía orientada a habilidades se acopla con diversos materiales locales.

Los autores concluyen que, a medida que los agentes dependen cada vez más de habilidades reutilizables, archivos locales, memoria y cadenas de herramientas, las evaluaciones de seguridad deben tener en cuenta el contexto operativo confiable en el que se toman y materializan las decisiones de los agentes.