SkillVetBench: un LLM-juez que ve lo que los escáneres de skills pasan por alto
Un artículo de arXiv del 14 de junio de 2026 muestra que los escáneres de skills a nivel de código omiten entre el 89 % y el 100 % de las amenazas a nivel de instrucción, mientras un LLM-juez detecta las 78 skills maliciosas de prueba sin ningún falso positivo.
¿Qué es esto?
SkillVetBench es un sistema de evaluación de seguridad para los skills de agentes de IA, publicado en arXiv el 14 de junio de 2026 (arXiv:2606.15899) por Ismail Hossain, Sai Puppala, Md Jahangir Alam, Tanzim Ahad y Sajedul Talukder del SUPREME Lab de la Universidad de Texas en El Paso. Es la contraparte pública de un artículo de benchmark (arXiv:2606.00925) que aporta el corpus etiquetado tras sus cifras.
Un skill es la unidad de extensibilidad de los agentes modernos: un paquete que reúne instrucciones en lenguaje natural, scripts y declaraciones de herramientas/permisos (la familia SKILL.md). Marketplaces abiertos como ClawHub y OpenClaw alojan ya decenas de miles de skills aportados por la comunidad. La tesis central del artículo es incómoda: los escáneres en los que confían esos marketplaces miran en el lugar equivocado. El peligro de un skill malicioso suele residir en sus instrucciones, no en código inspeccionable, y ahí es justo donde las herramientas a nivel de código están ciegas. Es la misma superficie de ataque de cadena de suministro que mide MalSkillBench y que explota el secuestro por cumplimiento semántico.
Cómo funciona
SkillVetBench hace pasar un LLM-juez (LLM-as-Judge) sobre el artefacto completo del skill (instrucciones, código, configuración, declaraciones de herramientas, divididos en segmentos tipados) y emite tres señales deliberadamente separadas por skill, nunca fusionadas en un solo número:
- Un veredicto de tres niveles — Benigno / Sospechoso / Malicioso — con una puntuación de confianza en [0,1].
- Un vector CVSS v4.0 completo, donde el juez asigna los valores categóricos de las métricas (AV, PR, VC, etc.) y la función de puntuación estándar calcula el número de forma determinista.
- SARS (Skill Agentic Risk Score), una métrica original de 0 a 10 diseñada para sistemas que siguen instrucciones.
SARS puntúa cinco dimensiones de 0 a 3 y las pondera:
SARS = (2·IFR + 1.5·DG + 1.5·AI + 2·BR + 2·CA) / 2.7 # 0–10
IFR Instruction Fidelity Risk — ¿puede el texto del usuario sobrescribir las instrucciones del skill?
DG Data Gravity — público → interno → confidencial → secretos restringidos
AI Action Irreversibility — solo lectura → reversible → difícil → DELETE/envío/pago
BR Blast Radius — uno mismo → equipo → plataforma → entre sistemas / propagable (gusano)
CA Chain Amplification — ¿se vuelve un multiplicador encadenado con otros skills?IFR, BR y CA cargan el peso más alto (2×) precisamente porque son los ejes que un escáner de código no puede ver: la susceptibilidad al secuestro de instrucciones, el alcance del daño y la amplificación en una cadena multi-skill. Etiquetas: Crítico ≥9,0; Alto 7,0–8,9; Medio 4,0–6,9; Bajo <4,0.
El sentido de mantener CVSS y SARS separados es que la brecha entre ambos es la señal. En los datos del artículo, un skill «Data Exposure» obtiene solo CVSS 1,84 y «Supply Chain» solo 2,30 —ambos por debajo del umbral Medio— y, sin embargo, cada uno presenta dimensiones SARS elevadas y recibe un veredicto Sospechoso. El mismo artefacto que parece inofensivo como código es peligroso como actor agéntico.
Un punto crucial: los autores son honestos sobre el alcance. El juez solo lee contenido estático. No ejecuta el skill, no lo lanza en sandbox, no observa los argumentos en tiempo de ejecución. Cada veredicto evalúa el comportamiento declarado e inspeccionable, no el observado.
Por qué importa
El resultado principal es la medición de la ceguera de los detectores. Sobre un conjunto controlado de 100 skills (78 confirmados maliciosos, 22 benignos), la etapa LLM-juez alcanza cero falsos negativos y cero falsos positivos, mientras que la mejor referencia estática (SkillSieve) aún omite el 15 %. En las categorías a nivel de instrucción la brecha es un abismo: las herramientas convencionales omiten entre el 89 % y el 100 % de las amenazas, y CodeBERT no detecta ninguno de los nueve skills de envenenamiento de memoria. Si su pipeline de revisión de skills es un comparador de firmas o un analizador estático, es estructuralmente incapaz de ver los ataques de skills más comunes —inyección de prompts y envenenamiento de memoria— por bien ajustado que esté.
El resultado que mantiene la honestidad: la tasa de detección oscila del 35 % al 95 % según cuatro LLM-jueces distintos. Un LLM-juez no es una bala de plata; un juez débil es su propio punto ciego. Esa varianza es el argumento del artículo a favor de una puntuación por ensamble en lugar de confiar en el veredicto de un solo modelo.
Defensas
Evalúe los skills a nivel de instrucción, no solo a nivel de código. Trate cada skill de terceros a la vez como código ejecutable y como una instrucción que dirige a su agente. Un escaneo estático limpio no le dice casi nada del riesgo de inyección de prompts o envenenamiento de memoria. Añada una etapa de revisión semántica que lea juntas las directivas en lenguaje natural, las herramientas declaradas y los permisos.
Puntúe el alcance agéntico (blast radius), no solo el CVSS. Tome prestados los ejes de SARS aunque no adopte la herramienta: para cada skill, pregunte si el texto del usuario puede sobrescribir sus instrucciones (IFR), cuán sensibles son los datos que toca (DG), si sus acciones son reversibles (AI), hasta dónde se propaga el daño (BR) y si amplifica al encadenarse (CA). Un CVSS bajo en un skill con alto blast radius y alta amplificación de cadena es una trampa, no una luz verde.
Use un ensamble de jueces y registre qué modelo juzgó. Dada la diferencia del 35 al 95 % entre evaluadores, dirija los skills de alto riesgo a más de un modelo y trate el desacuerdo como una señal para escalar a revisión humana. Fije y registre la identidad del evaluador para que los veredictos sigan siendo comparables en el tiempo.
Mantenga una barrera humana para Alto/Crítico y no confíe en veredictos puramente estáticos. Como el juez solo lee lo estático, un atacante decidido aún puede ocultar comportamiento tras condiciones de ejecución. Combine la revisión semántica con controles en tiempo de ejecución —permisos deny-by-default y monitorización runtime como en SkillGuard— para que un skill que se cuele no pueda actuar fuera de su alcance declarado.
No confíe en la insignia de «aprobado» de un marketplace. La vista dual de ClawHub de SkillVetBench existe justamente porque el veredicto oficial del marketplace y una revisión independiente discrepan con frecuencia. Reevalúe los skills usted mismo antes de instalar, y en cada subida de versión.
Estado
| Elemento | Referencia | Fecha | Notas |
|---|---|---|---|
| Artículo (leaderboard) | arXiv:2606.15899 | 2026-06-14 | LLM-juez, SARS + CVSS v4.0 + veredicto |
| Benchmark complementario | arXiv:2606.00925 | 2026-06 | Corpus etiquetado / resultados de detección |
| Detección controlada | 78 maliciosos + 22 benignos | — | LLM-juez: 0 FN, 0 FP |
| Mejor referencia estática | SkillSieve | — | Aún omite el 15 % |
| Brecha a nivel instrucción | Inyección de prompts, envenenamiento de memoria | — | Herramientas convencionales omiten 89–100 % |
| Varianza de evaluadores | 4 LLM-jueces | — | Detección 35–95 % → se aconseja ensamble |
| Límite de alcance | Solo análisis estático | — | Sin ejecución / observación en runtime |
La conclusión no es «use este leaderboard». Es que la evaluación de skills debe moverse al nivel de instrucción —y que ningún juez único, humano o modelo, debería ser la única barrera frente a código que su agente va a ejecutar.