Un skill qui en télécharge d’autres : ce que j’ai vu sous le capot

Avant d’entrer dans le sujet, deux mots pour cadrer. Je ne suis pas expert AI security. Je suis en reconversion cybersécurité et j’apprends, donc ce qui suit est mon avis du moment, pas une analyse de référence.

Petite précision aussi : je prépare en ce moment la certification ISO 27001 Lead Implementer, donc ce genre de cas concret m’aide à mobiliser les normes que je rencontre dans le cursus. C’est pour ça que je cite ISO 27001, NIS2 et l’IA Act un peu plus loin. Ce n’est pas un placage de jargon, c’est ma manière de faire travailler ce que j’apprends sur un sujet d’actualité.

Ce qui me motive ici, c’est un réflexe que je traîne partout : me poser les questions “mais pourquoi ?” et “comment ça fonctionne ?”. J’essaie de l’appliquer au maximum à ce que je touche, en tech comme ailleurs. Avec l’engouement actuel pour l’IA, je vois beaucoup de monde télécharger des skills et brancher des MCP sans vraiment regarder ce qu’il y a sous le capot. Et ça me gêne, parce que ma manière naturelle d’aborder les sujets techniques c’est le security by design : la sécurité comme premier réflexe, pas comme couche ajoutée à la fin.

Le cas que je vais décrire est un exemple intéressant. Un simple skill, en apparence anodin, qui pose vite des questions de supply chain et de gouvernance en entreprise. Si tu vois quelque chose à corriger ou à compléter, j’écoute volontiers.

Le contexte

Je suis tombé sur un fichier SKILL.md publié par Vercel. Il s’appelle find-skills. Sa promesse : quand l’utilisateur demande à son agent IA “tu sais faire X ?”, l’agent va chercher dans un registre public si un skill correspond, puis l’installe.

C’est élégant sur le papier. Un npm pour les skills d’agents. Une démocratisation de l’extension d’agents IA. Sauf que quand j’ai regardé ce qui se passait vraiment derrière, plusieurs choses m’ont gêné. Je voulais poser ça à l’écrit.

D’abord, c’est quoi un skill, et c’est quoi un MCP

J’ai eu la question posée en ces termes : “c’est un skill ou il y a du MCP derrière ?”. Bonne question, parce que les deux sont souvent confondus.

Un skill est un fichier markdown. Du texte. Avec un frontmatter qui donne un nom et une description, et des sections qui expliquent à l’agent IA “quand utiliser ce skill” et “comment l’utiliser”. L’agent lit ce texte comme un humain lit une fiche réflexe. Il en déduit quoi faire. Pas de processus qui tourne, pas d’API, pas d’exécution autonome. Juste du contenu qui guide.

Un MCP server est tout autre chose. C’est un vrai processus, qui tourne en local ou en remote, et qui expose des fonctions (appelées “tools”) via un protocole standardisé (JSON-RPC). L’agent appelle ces fonctions avec des arguments typés et reçoit des retours structurés. C’est une interface programmatique. Avec un schema. Avec des contrats.

La différence est importante pour le modèle de menace. Sur un MCP, on peut imaginer du sandboxing, une validation d’arguments, des permissions par tool. Sur un skill, on a du texte qui dit à l’agent “lance cette commande shell”. L’agent l’exécute via son outil bash standard. Pas de sandbox protocole, pas de typage.

find-skills est un skill. Et c’est précisément ce skill qui est l’objet d’étude ici.

Ce que fait vraiment ce skill

Quand l’utilisateur demande quelque chose qui ressemble à “tu peux faire X ?”, le SKILL.md dit à l’agent de :

1. Consulter le leaderboard sur skills.sh pour voir si un skill connu couvre la demande
2. Lancer npx skills find <query> pour chercher dans le registre
3. Vérifier la “qualité” du candidat : install count, source, étoiles GitHub
4. Proposer à l’utilisateur
5. Installer avec npx skills add <owner/repo@skill> -g -y

Le flag -g installe au niveau utilisateur global. Le flag -y skippe la confirmation interactive.

C’est cette dernière ligne qui m’a fait tiquer. Je vais revenir dessus.

Cinq maillons, et un flag qui pose problème

Cartographions la chaîne de confiance, parce que c’est elle qui compte quand on parle supply chain :

Cinq maillons. Chacun avec son modèle de menace. Et au bout, du code qui s’installe sur le poste de l’utilisateur, au niveau global, sans confirmation interactive si on suit la recommandation du SKILL.md.

Le -y me dérange particulièrement. C’est le seul moment où l’humain a une chance d’arrêter une installation douteuse. C’est sa dernière friction. La supprimer, c’est basculer de “semi-autonome” à “full autonome” sur une action qui installe du code tiers. Sur un cas d’usage à fort coût d’erreur (sécurité), on devrait faire l’inverse : ajouter de la friction, pas en retirer.

Là où ça peut être vérolé

Plusieurs angles d’attaque, classés par ordre de probabilité subjective.

Le repo cible compromis. N’importe quel owner GitHub peut publier un skill et le faire référencer. Le SKILL.md lui-même est inerte (du markdown), mais rien n’interdit d’embarquer des fichiers exécutables, des hooks postinstall npm qui s’exécutent automatiquement à l’installation, ou tout simplement des instructions dans le SKILL.md qui poussent l’agent à exécuter des commandes douteuses sous prétexte de “faire son job”. C’est de la prompt injection appliquée à un skill, et c’est un sujet en soi.

Compromission d’un mainteneur populaire. On a déjà vu ce film. En mars 2024, le projet xz-utils, une bibliothèque de compression utilisée massivement par OpenSSH, s’est révélé compromis par un mainteneur unique qui avait construit sa crédibilité pendant trois ans avant d’injecter une backdoor. Découverte par accident par un ingénieur Microsoft qui avait remarqué une latence anormale sur SSH. Si ça arrive sur une lib aussi exposée, ça peut arriver sur un skill populaire. Et la popularité ne protège pas. Elle aggrave l’impact.

Typosquatting. Standard sur npm et pip. vercel-lab/skills au lieu de vercel-labs/skills. L’utilisateur lit une réponse plausible, l’agent installe, personne ne remarque.

Le registre skills.sh comme point de centralisation. Compromettre le registre, c’est manipuler les résultats de recherche de tous les agents qui l’utilisent. Pas besoin de compromettre 1000 repos.

Heuristiques sociales prises pour des contrôles. Le SKILL.md recommande de vérifier install count et stars GitHub. C’est mieux que rien. Mais ça reste de la popularité, pas de la fiabilité. xz-utils était populaire. Event-stream, ua-parser-js, node-ipc, ctx : tous populaires au moment de leur compromission.

Aucune de ces attaques n’est théorique. Toutes ont des précédents documentés sur des écosystèmes voisins.

On a déjà vu le film côté supply chain logicielle

Les écosystèmes npm, pip, Docker Hub, extensions navigateur, tous ont vécu leurs incidents. Et tous ont fini par mettre en place les mêmes types de contre-mesures :

• Registry privé ou proxy interne (Artifactory, Nexus, Verdaccio côté npm)
• Scan de sécurité automatisé (Snyk, Trivy, Grype, pip-audit)
• Signature des paquets (Sigstore, Cosign, Notary)
• Lockfile et pinning de versions
• 2FA obligatoire sur les comptes mainteneurs
• SBOM (Software Bill of Materials)

Aucune de ces contre-mesures n’est mature dans l’écosystème des skills agents IA aujourd’hui. C’est jeune. Et c’est précisément parce que c’est jeune qu’on a une fenêtre pour ne pas refaire les mêmes erreurs.

Ce qui change avec les skills, par rapport au cas npm classique :

Le vecteur d’exécution n’est plus un développeur humain qui lance npm install. C’est un agent IA qui chaîne find puis add -y en quelques secondes, sans pause de réflexion. La vélocité de l’IA, qui est par ailleurs un atout, devient ici un facteur aggravant. Un humain peut s’arrêter, ouvrir le repo dans son navigateur, lire le code. Un agent qui veut “être utile” et “ne pas faire attendre” est mal placé pour faire ça.

Et puis il y a la couche prompt injection. Un skill peut contenir des instructions qui ne sont pas du code malveillant au sens classique, mais qui détournent l’agent. Par exemple en lui demandant d’envoyer un fichier sensible vers une URL, ou de modifier un autre skill déjà installé. C’est une surface d’attaque nouvelle, qui n’existait pas sur npm.

Quand on fait de la GRC, ça change quoi

C’est l’angle qui me parle le plus dans ma trajectoire actuelle, donc je le développe.

Si demain je suis dans une PME ou un ETI sous obligation NIS2, qu’un développeur ou un consultant arrive avec un agent IA équipé de find-skills et installe du code tiers en mode -y sur un poste qui a accès au SI, on a un problème de cartographie d’actifs (article 21 §2(d) de NIS2 sur la sécurité de la chaîne d’approvisionnement), un problème ISO 27001 sur les relations fournisseurs (A.5.19 et A.5.21), et potentiellement un problème IA Act si on est sur un cas d’usage à haut risque (article 14 sur la supervision humaine, et un -y automatique va à l’encontre du principe).

Concrètement, ce qu’un Architecte sécurité ou un consultant GRC peut poser comme contrôles minimum :

D’abord une allowlist d’origines approuvées. Pas tout GitHub : des sources nommées. Ensuite une procédure de revue pour décider de ce qui rentre dans cette allowlist : qui lit le SKILL.md, qui inspecte le repo, qui tranche. L’interdiction du flag -y dans les procédures opérationnelles fait partie du minimum syndical. La journalisation des installations aussi, parce qu’un audit ISO 27001 va le demander : qui, quoi, quand, sur quel poste. Et le rattachement à la gestion des fournisseurs (A.5.19) et à la gestion des changements (A.8.32), pour ne pas réinventer un processus parallèle. Sur les structures plus grandes, on monte d’un cran avec un registry interne qui mirror les skills approuvés, dans la même logique qu’un Artifactory pour npm.

Rien de tout ça n’est révolutionnaire. Ce sont les bons vieux contrôles supply chain, appliqués à un nouvel objet. C’est même un peu rassurant : on n’invente pas une nouvelle discipline, on étend une discipline existante à un nouveau périmètre.

Ce que j’en retiens

Je ne pense pas que find-skills soit malveillant. Vercel est un acteur sérieux, l’idée d’un écosystème ouvert de skills est plutôt saine, et le SKILL.md lui-même est bien écrit. Mon problème n’est pas avec ce skill précis. Mon problème est avec le pattern qu’il généralise : un agent IA qui télécharge dynamiquement du code tiers, sans audit centralisé, avec une heuristique sociale en guise de contrôle qualité, et un flag par défaut qui supprime la dernière friction humaine.

Sur mon homelab, je peux jouer avec, à condition de retirer le -y et de regarder ce que j’installe. Sur un poste pro, je ne pousserais pas ce pattern sans cadre de gouvernance autour. Pas par paranoïa, par hygiène professionnelle. La supply chain logicielle a saigné assez de fois sur les autres écosystèmes pour qu’on prenne au sérieux les premiers symptômes sur celui-là.

Le sujet plus large, c’est que la sécurité des agents IA ne se réduit pas au modèle. Elle inclut le harness : les skills, les MCP, les outils, les permissions, les chaînes d’approvisionnement de tout ça. C’est un terrain qui se structure en ce moment. Pour qui s’oriente vers la GRC ou la Cloud Security à l’ère de l’IA agentique, c’est un sujet à suivre. Pas demain. Maintenant.

J’aurais aimé conclure avec un point net et synthétique. Mais honnêtement, je trouve qu’on est encore dans la phase où il faut poser les questions plutôt que donner les réponses. Comment on signe un skill ? Qui audite le registre ? Quelle norme couvre spécifiquement la chaîne d’approvisionnement des composants IA agentiques ? Est-ce que le NIS2 actuel suffit ou faut-il un cadre dédié ? Je n’ai pas la réponse. Je sais juste que quand un skill propose à un agent d’en installer d’autres avec -y, ça vaut le coup d’ouvrir le capot avant de cliquer.

Si tu veux creuser, les sources : le SKILL.md de vercel-labs/find-skills, le registre skills.sh, et pour la partie supply chain logicielle classique, l’article Wikipedia sur la backdoor xz-utils est une bonne porte d’entrée.