SkillMutator : l'attaque cachée entre le texte et le code d'une skill d'agent
Un benchmark de juin 2026 montre qu'une skill d'agent peut être malveillante dans l'interaction entre ses instructions en langage naturel et ses scripts — passant à la fois la détection d'injection de prompt et la revue de code, tout en poussant l'agent à exfiltrer des fichiers.
En bref Un benchmark publié en juin 2026 (arXiv:2606.14154) cible un angle mort dans la façon dont les skills d’agent sont vérifiées. Une skill associe une spécification en langage naturel à des scripts exécutables : une skill malveillante n’a donc besoin ni d’un prompt piégé ni d’un code manifestement piégé — elle peut dissimuler la nuisance dans l’interaction entre les deux. Le texte décrit un flux de travail anodin tandis que des directives implicites poussent l’agent à exfiltrer des fichiers sensibles, alors même que chaque script, lu isolément, paraît inoffensif. SkillMutator est le premier benchmark de détection à l’installation de ces attaques cross-modales langage-et-code, et il fournit un scanner déployable localement, entraîné à les repérer.
De quoi s’agit-il ?
Les skills d’agent sont un mécanisme d’extension en pleine croissance. Comme l’a décrit Anthropic en publiant le format comme standard ouvert en décembre 2025, une skill est un dossier contenant un fichier SKILL.md — des instructions en langage naturel plus des scripts, modèles et ressources optionnels — qu’un agent découvre et charge à l’exécution pour mieux accomplir une tâche précise. L’agent lit le texte pour décider quoi faire et exécute le code embarqué pour le faire réellement.
C’est précisément cette double nature que la recherche de juin 2026 sonde. Parce que le comportement réel d’une skill dépend à la fois de ses instructions en langage et de son code exécutable, juger de sa sûreté exige un raisonnement sur les deux modalités en même temps. Le papier parle d’une surface d’attaque cross-modale langage-et-code, et soutient qu’elle est restée largement non mesurée : les travaux antérieurs traitaient une skill soit comme un vecteur d’injection de prompt (regarder le texte), soit comme un artefact de code statique (scanner les scripts), et passaient donc à côté des menaces qui n’existent que dans la combinaison des deux.
Comment ça marche
L’attaque vit dans l’écart entre lire et exécuter. Un attaquant diffuse une skill dont le SKILL.md présente un flux de travail plausible et anodin, tout en y intégrant des directives implicites qui redéfinissent la façon dont l’agent doit utiliser les scripts fournis. Lus isolément, ces scripts peuvent ressembler à des utilitaires ordinaires ; lus à la lumière des instructions en langage naturel, ils deviennent le mécanisme de quelque chose que l’utilisateur n’a jamais demandé — par exemple collecter et exfiltrer discrètement des fichiers sensibles pendant ce qui est présenté comme une tâche de routine.
Un scanner d’injection de prompt purement textuel ne voit pas le chemin de code qui s’arme. Un scanner de code purement statique ne voit pas l’intention encodée dans le texte. Chaque contrôle mono-modal valide la skill, et la composition malveillante franchit la revue à l’installation.
Pour mesurer le problème, les auteurs ont construit SkillMutator, qu’ils décrivent comme le premier benchmark de détection à l’installation des attaques cross-modales langage-et-code sur les skills d’agent. Il émule un processus adverse de mutation de skills couvrant 13 catégories d’attaque et réécrit itérativement les skills malveillantes à partir des retours du scanner qu’il cherche à déjouer — le benchmark éprouve ainsi les détecteurs face à des variantes évasives et affinées, plutôt qu’à un jeu d’échantillons faciles et figés.
Côté défense, le papier propose un cadre de distillation de trajectoires de raisonnement en quatre phases. Il prend les traces de raisonnement d’un puissant modèle « enseignant » de frontière et les distille, à travers quatre étapes de raisonnement structurées, dans des modèles à poids ouverts plus petits. Il en résulte un scanner capable de tourner localement au moment de l’installation, ce qui compte pour deux raisons pratiques soulignées par les auteurs : cela évite d’envoyer le contenu potentiellement sensible d’une skill à un tiers, et cela évite le coût d’API consistant à faire passer chaque installation de skill par un modèle de frontière.
Pourquoi c’est important
Les skills deviennent un canal de distribution — partagées dans des dépôts, intégrées à des produits, échangées entre équipes. La décision de confiance se prend à l’installation, et aujourd’hui cette décision repose souvent sur une lecture humaine rapide ou un scan mono-modal. Ce travail montre qu’aucun des deux ne suffit : une skill peut être façonnée de manière adverse pour se lire proprement et se scanner proprement tout en restant nuisible à l’usage. À mesure que les places de marché de skills se développent, la porte à l’installation est l’endroit où une skill empoisonnée est soit interceptée, soit installée comme une capacité permanente au sein de l’agent.
Cela reformule aussi la vérification. « Le texte ne contient pas d’injection » et « le code ne contient pas de motif connu comme malveillant » sont deux feux verts distincts qui, ensemble, ne prouvent toujours pas qu’une skill est sûre. La propriété qui compte est cross-modale : que fait faire à l’agent ce texte plus ce code ?
Défenses
- Vérifiez les skills de manière cross-modale, à l’installation. Évaluez ensemble les instructions en langage naturel et les scripts embarqués, en vous demandant quel comportement la combinaison induit — et non chaque modalité isolément. C’est précisément l’écart que le benchmark existe pour mesurer.
- Privilégiez un scanner local pour la revue des skills. Exécuter la détection localement à l’installation évite d’exposer le contenu des skills à des tiers et supprime le coût d’un modèle de frontière par installation — le compromis exact que vise le scanner distillé à poids ouverts du papier.
- Traitez les skills installées comme du code non fiable doté d’une intention. Appliquez la discipline supply chain : figez et relisez les versions, restreignez les skills qu’un agent peut charger, et confinez l’exécution des skills pour qu’un script ne puisse atteindre ni secrets ni réseau sauf si la tâche l’exige réellement.
- Contraignez les capacités que le texte peut invoquer. Le moindre privilège sur l’accès aux fichiers et la sortie réseau limite ce qu’un script d’apparence anodine, armé par des directives cachées, peut effectivement exfiltrer.
- Éprouvez les détecteurs face à des variantes évasives. Un scanner qui attrape les skills manifestement malveillantes peut échouer face à celles affinées à partir de ses propres retours. Évaluez la détection sur des skills mutées de façon adverse, pas sur un corpus figé.
Statut
| Élément | Référence | Date | Notes |
|---|---|---|---|
| Papier SkillMutator | arXiv:2606.14154 | 2026-06 | Premier benchmark de détection à l’installation des attaques cross-modales langage-et-code sur les skills d’agent |
| Surface d’attaque | arXiv:2606.14154 | 2026-06 | 13 catégories d’attaque ; skills malveillantes affinées itérativement à partir des retours du scanner |
| Défense | arXiv:2606.14154 | 2026-06 | Distillation de trajectoires de raisonnement en quatre phases vers des modèles à poids ouverts → scanner déployable localement |
| Format Agent Skills | Anthropic engineering | 2025-12 | Les skills associent les instructions en langage naturel de SKILL.md à des scripts exécutables ; standard ouvert |
La leçon n’est pas que les skills d’agent sont dangereuses à utiliser. C’est que la sûreté d’une skill est une propriété de son langage et de son code considérés ensemble, et que le moment de la vérifier est avant l’installation — avec une revue qui raisonne sur les deux modalités, et non deux passes mono-modales qui la laissent chacune passer.