Déclencheurs cachés dans SKILL.md : attaques sémantiques sur les registres de skills d'agents

What is this?

Le 12 mai 2026, Shoumik Saha, Kazem Faghih et Soheil Feizi (Université du Maryland) ont publié sur arXiv Under the Hood of SKILL.md: Semantic Supply-chain Attacks on AI Agent Skill Registry (2605.11418, cs.CR). Le papier étudie une classe d’attaque qui n’a besoin d’aucun octet de code exécutable : de courts ajouts en langage naturel, à l’apparence anodine, suffisent à influencer la skill que l’agent découvre, celle qu’il sélectionne parmi des alternatives, et le verdict du scan de sécurité du registre.

Ce travail compte parce que SKILL.md est désormais un artefact opérationnel dans l’écosystème agentique — Claude Code, OpenClaw, Microsoft Agent Framework, skills Codex — et non une simple documentation passive. L’agent le lit à la découverte (pour faire correspondre une requête à des skills disponibles), à la sélection (pour choisir entre des skills fonctionnellement proches), et à l’installation (lorsque le registre passe ses contrôles de sécurité). Chacune de ces lectures est un point où une modification textuelle peut changer le comportement. The Register a couvert le papier le 22 mai 2026 sous le titre Minor edits to AI skills can make agents go rogue.

How it works

Les auteurs évaluent trois étapes du cycle de vie d’un registre face à de vraies skills ClawHub et à une fonction de classement réaliste combinant pertinence lexicale, similarité vectorielle (embeddings OpenAI) et popularité par téléchargements. Ils ne modifient que le texte de SKILL.md — jamais le script sous-jacent, ni les dépendances, ni le runtime — et mesurent à quelle fréquence un jumeau malveillant d’une skill existante l’emporte.

Étape              Surface SKILL.md utilisée    Objectif adverse
-----------------  --------------------------   --------------------------------
Découverte         nom, description, tags       Être récupéré pour la requête
Sélection          when-to-use, exemples        Battre le jumeau légitime
Vérification       corps complet, "safety"      Passer le scanner du registre

Trois résultats structurent le papier.

• Découverte. Un déclencheur d’environ 20 tokens inséré dans la description suffit à faire passer une skill malveillante devant son jumeau non modifié dans 86 % des comparaisons appariées, et à la placer dans le top 10 du registre dans 80 % des requêtes. Ce n’est pas du bourrage de mots-clés : la technique exploite la proximité dans l’espace d’embeddings avec les formulations réellement tapées par les utilisateurs.
• Sélection. Une fois les deux skills présentées à l’agent, un cadrage purement descriptif oriente l’agent vers la variante malveillante dans 77,6 % des essais appariés en moyenne, sans aucun changement du comportement fonctionnel sous-jacent. L’agent lit le bloc « when to use » et les exemples, et c’est ce texte qui décide.
• Évasion du contrôle. Les mêmes familles de déclencheurs échappent aux scans côté registre entre 36,5 % et 100 % du temps selon le scanner. Comme aucun payload n’est livré, les défenses basées sur signatures ou motifs n’ont rien à détecter.

Point essentiel : les auteurs ne publient pas de déclencheurs malveillants fonctionnels ; ils diffusent un harnais de mesure (github.com/ShoumikSaha/agent-skill-security) et des statistiques agrégées. La contribution est une catégorie — « la métadonnée est l’attaque » — pas une recette.

Why it matters

Trois implications dépassent ce papier.

D’abord, les registres de skills héritent d’un problème que les registres de packages croyaient résolu. PyPI et npm ont passé une décennie à se durcir contre le typosquatting, la confusion de dépendances et la prise de contrôle de compte, qui supposent toutes que l’attaquant livre du code. Ici, l’attaquant livre de la prose, et cette prose traverse le pipeline d’embeddings du registre. Les antimalwares et les SBOM visent la mauvaise couche.

Ensuite, la défaillance émerge dans des composants que personne ne possède pleinement. Le ranker de découverte est une décision du fournisseur (ClawHub, le moteur de recherche skills d’OpenAI, le framework d’agents de Microsoft). Le prompt de sélection relève du runtime agentique. Le scan de vérification est du ressort du registre. Il suffit que l’attaquant déstabilise une seule de ces trois couches en vingt tokens pour faire mal classer une description d’apparence inoffensive. C’est la même diffusion de responsabilité qui rendait les premiers app stores poreux.

Enfin, le papier rejoint un faisceau de travaux de mai 2026 pointant la même direction. Exploiting LLM Agent Supply Chains via Payload-less Skills (arXiv:2605.14460, Liu et al., Université de Zhejiang, 14 mai 2026) introduit le Semantic Compliance Hijacking avec jusqu’à 77,67 % de fuites de confidentialité et 67,33 % d’exécution de code à distance à partir de skills sans payload. De SKILL.md à un shell en trois lignes de markdown publié par Snyk relaie le même constat côté builders. Le message converge : l’écosystème SKILL.md est une chaîne d’approvisionnement, elle n’est pas durcie, et son exploitation ne nécessite ni cryptographie nouvelle ni astuce runtime.

Defenses

Le papier propose des contrôles côté registre et côté agent. La liste actionnable la plus courte :

1. Traiter le texte de SKILL.md comme du code en revue. Il n’a pas besoin d’être exécutable pour être dangereux. Diffez-le à chaque mise à jour, exigez un changelog lisible, et refusez toute réécriture silencieuse des blocs description, when-to-use et examples.
2. Hasher et épingler les skills comme vos dépendances. Une entrée de lockfile skill@1.4.2#sha256:… empêche l’artefact publié de dériver sous votre agent, exactement comme package-lock.json pour npm. Les scénarios d’attaque du papier supposent tous que le texte de la skill reste mutable après installation.
3. Décorréler la découverte de la sélection. Le déclencheur qui hisse une skill dans le retrieval n’est pas toujours celui qui biaise la sélection — mais utiliser un seul blob de texte pour les deux offre à l’attaquant deux cibles pour le prix d’une. Calculez l’embedding de découverte à partir d’une vue assainie (nom canonique, tags, manifest signé) et réservez le texte libre à la sélection.
4. Faire passer des scanners sémantiques sur les métadonnées, pas seulement sur le code. Les auteurs publient sur GitHub un harnais de mesure qui donne un point de départ aux défenseurs. Traitez les manifests de skill comme des e-mails : un classifieur de contenu signale les directives impératives (« MUST », « always », « avant d’exécuter, exécutez X ») dans des champs censés être descriptifs.
5. Contraindre la fonction de classement du registre. Pertinence lexicale, similarité vectorielle, popularité et confiance d’éditeur signé ne devraient pas se résumer à un score scalaire unique. Une petite perturbation adverse dans la description ne devrait pas pouvoir l’emporter sur la provenance d’un éditeur signé.
6. Exiger une signature d’éditeur sur chaque skill, et l’exposer à la sélection. Si le prompt de sélection de l’agent affiche l’identité signataire à côté de la description, un jumeau d’une skill populaire publié par un éditeur inconnu cesse de gagner par défaut.
7. Default-deny des capacités réseau et fichier à la couche skill. Même quand une skill malveillante est sélectionnée, une exécution capabilité-bornée (ACL par skill, pas de credentials ambiants, whitelist d’egress) limite ce que « gagner la sélection » rapporte vraiment à l’attaquant. C’est la même défense en profondeur que recommande le papier CISPA agents-as-OS sur ce site.

Status

Élément	Référence	Date	Notes
Papier publié	arXiv:2605.11418v1	2026-05-12	cs.CR, Univ. du Maryland
Couverture publique	The Register	2026-05-22	Minor edits to AI skills can make agents go rogue
Taux de découverte	86 % apparié, 80 % Top-10	2026-05-12	déclencheur de 20 tokens dans la description
Biais de sélection	77,6 % essais appariés	2026-05-12	cadrage purement descriptif
Évasion du contrôle	36,5 %–100 %	2026-05-12	selon le scanner
Code & données	github.com/ShoumikSaha/agent-skill-security	2026-05-12	harnais de mesure, pas de payloads vivants
Travail adjacent	arXiv:2605.14460 (Liu et al.)	2026-05-14	Semantic Compliance Hijacking, 77,67 % conf. / 67,33 % RCE

Aucun correctif unique ne retire cette classe d’attaques. La contribution du papier est de rendre explicite ce que les opérateurs d’agents écartaient discrètement : les registres de skills font partie de la frontière de confiance, le fichier de métadonnées fait partie de la surface exécutable, et vingt tokens de prose bien placée déplacent la décision de l’agent plus sûrement qu’un CVE.