SkillVetBench : un LLM-juge qui voit ce que les scanners de skills ratent

De quoi s’agit-il ?

SkillVetBench est un système d’évaluation de sécurité pour les skills d’agents IA, publié sur arXiv le 14 juin 2026 (arXiv:2606.15899) par Ismail Hossain, Sai Puppala, Md Jahangir Alam, Tanzim Ahad et Sajedul Talukder du SUPREME Lab de l’Université du Texas à El Paso. C’est le pendant public d’un papier de benchmark (arXiv:2606.00925) qui fournit le corpus annoté derrière ses chiffres.

Une skill est l’unité d’extensibilité des agents modernes — un paquet réunissant des instructions en langage naturel, des scripts et des déclarations d’outils/permissions (la famille SKILL.md). Des marketplaces ouvertes comme ClawHub et OpenClaw hébergent désormais des dizaines de milliers de skills contribuées par la communauté. La thèse centrale du papier est dérangeante : les scanners sur lesquels ces marketplaces s’appuient regardent au mauvais endroit. Le danger d’une skill malveillante réside le plus souvent dans ses instructions, pas dans du code inspectable — et c’est précisément là que les outils au niveau code sont aveugles. C’est la même surface d’attaque de chaîne d’approvisionnement que mesure MalSkillBench et qu’exploite le détournement par conformité sémantique.

Comment ça marche

SkillVetBench fait passer un LLM-juge (LLM-as-Judge) sur l’artefact complet de la skill (instructions, code, config, déclarations d’outils — découpés en segments typés) et produit trois signaux volontairement séparés par skill, jamais fusionnés en un seul nombre :

• Un verdict à trois niveaux — Bénin / Suspect / Malveillant — avec un score de confiance dans [0,1].
• Un vecteur CVSS v4.0 complet, où le juge attribue les valeurs catégorielles des métriques (AV, PR, VC, etc.) et où la fonction de scoring standard calcule le nombre de façon déterministe.
• SARS (Skill Agentic Risk Score), une métrique originale de 0 à 10 conçue pour les systèmes suivant des instructions.

SARS note cinq dimensions de 0 à 3 et les pondère :

SARS = (2·IFR + 1.5·DG + 1.5·AI + 2·BR + 2·CA) / 2.7   # 0–10

IFR  Instruction Fidelity Risk  — le texte utilisateur peut-il écraser les instructions de la skill ?
DG   Data Gravity               — public → interne → confidentiel → secrets restreints
AI   Action Irreversibility     — lecture seule → réversible → difficile → DELETE/envoi/paiement
BR   Blast Radius               — soi → équipe → plateforme → inter-systèmes / propageable (ver)
CA   Chain Amplification        — devient-elle un multiplicateur enchaînée à d'autres skills ?

IFR, BR et CA portent le poids le plus lourd (2×) précisément parce que ce sont les axes qu’un scanner de code ne peut pas voir — la susceptibilité au détournement d’instructions, la portée du dommage, et l’amplification dans une chaîne multi-skills. Étiquettes : Critique ≥9,0 ; Élevé 7,0–8,9 ; Moyen 4,0–6,9 ; Faible <4,0.

L’intérêt de garder CVSS et SARS séparés est que l’écart entre les deux est le signal. Dans les données du papier, une skill « Data Exposure » n’obtient que CVSS 1,84 et « Supply Chain » que 2,30 — toutes deux sous le seuil Moyen — alors que chacune porte des dimensions SARS élevées et reçoit un verdict Suspect. Le même artefact qui paraît inoffensif en tant que code est dangereux en tant qu’acteur agentique.

Point crucial : les auteurs sont honnêtes sur le périmètre. Le juge ne lit que le contenu statique. Il n’exécute pas la skill, ne la lance pas en bac à sable, n’observe pas les arguments à l’exécution. Chaque verdict évalue le comportement déclaré et inspectable, pas le comportement observé.

Pourquoi c’est important

Le résultat phare est la mesure de l’aveuglement des détecteurs. Sur un jeu contrôlé de 100 skills (78 confirmées malveillantes, 22 bénignes), l’étape LLM-juge atteint zéro faux négatif et zéro faux positif, tandis que la meilleure référence statique (SkillSieve) en rate encore 15 %. Pour les catégories au niveau instruction, l’écart est un gouffre : les outils conventionnels ratent entre 89 % et 100 % des menaces, et CodeBERT ne détecte aucune des neuf skills d’empoisonnement de mémoire. Si votre pipeline de revue de skills est un correspondeur de signatures ou un analyseur statique, il est structurellement incapable de voir les attaques de skills les plus courantes — injection de prompt et empoisonnement de mémoire — quelle que soit sa qualité de réglage.

Le résultat qui maintient l’honnêteté : le taux de détection oscille de 35 % à 95 % selon quatre LLM-juges différents. Un LLM-juge n’est pas une solution miracle ; un juge faible est son propre angle mort. Cette variance est l’argument du papier pour un scoring en ensemble plutôt que la confiance dans le verdict d’un seul modèle.

Défenses

Évaluez les skills au niveau instruction, pas seulement au niveau code. Traitez chaque skill tierce à la fois comme du code exécutable et comme une instruction qui pilote votre agent. Un scan statique propre ne vous dit presque rien du risque d’injection de prompt ou d’empoisonnement de mémoire. Ajoutez une étape de revue sémantique qui lit ensemble les directives en langage naturel, les outils déclarés et les permissions.

Notez la portée agentique (blast radius), pas seulement le CVSS. Reprenez les axes SARS même sans adopter l’outil : pour chaque skill, demandez si le texte utilisateur peut écraser ses instructions (IFR), à quel point les données touchées sont sensibles (DG), si ses actions sont réversibles (AI), jusqu’où le dommage se propage (BR), et si elle amplifie enchaînée (CA). Un faible CVSS sur une skill à fort blast radius et forte amplification de chaîne est un piège, pas un feu vert.

Utilisez un ensemble de juges, et enregistrez quel modèle a jugé. Vu l’écart de 35 à 95 % entre évaluateurs, faites passer les skills à fort enjeu par plus d’un modèle et traitez le désaccord comme un signal d’escalade vers une revue humaine. Épinglez et journalisez l’identité de l’évaluateur pour que les verdicts restent comparables dans le temps.

Gardez une barrière humaine pour Élevé/Critique et ne faites pas confiance aux verdicts purement statiques. Comme le juge ne lit que le statique, un attaquant déterminé peut toujours cacher un comportement derrière des conditions d’exécution. Couplez la revue sémantique à des contrôles d’exécution — permissions deny-by-default et surveillance runtime comme dans SkillGuard — pour qu’une skill passée entre les mailles ne puisse pas agir hors de son périmètre déclaré.

Ne faites pas confiance au badge « approuvé » d’une marketplace. La vue duale ClawHub de SkillVetBench existe justement parce que le verdict officiel de la marketplace et une revue indépendante divergent fréquemment. Réévaluez les skills vous-même avant installation, et à chaque montée de version.

État des lieux

Élément	Référence	Date	Notes
Papier (leaderboard)	arXiv:2606.15899	2026-06-14	LLM-juge, SARS + CVSS v4.0 + verdict
Benchmark compagnon	arXiv:2606.00925	2026-06	Corpus annoté / résultats de détection
Détection contrôlée	78 malveillantes + 22 bénignes	—	LLM-juge : 0 FN, 0 FP
Meilleure référence statique	SkillSieve	—	Rate encore 15 %
Écart niveau instruction	Injection de prompt, empoisonnement mémoire	—	Outils conventionnels ratent 89–100 %
Variance des évaluateurs	4 LLM-juges	—	Détection 35–95 % → ensemble conseillé
Limite de périmètre	Analyse statique seulement	—	Pas d’exécution / observation runtime

À retenir : non pas « utilisez ce leaderboard », mais que l’évaluation des skills doit passer au niveau instruction — et qu’aucun juge unique, humain ou modèle, ne devrait être la seule barrière devant du code que votre agent va exécuter.