14 min read Chaine d'approvisionnement IA

Neuf marketplaces MCP sur onze n'ont rien relu, et le registre officiel écrit à qui il délègue la revue

Neuf marketplaces MCP sur onze n'ont rien relu, et le registre officiel écrit à qui il délègue la revue

Entre novembre 2025 et avril 2026, les chercheurs d'OX Security ont soumis un serveur MCP de démonstration à onze registres et marketplaces publics. Neuf des onze ont accepté la soumission sans revue, et un seul registre, celui géré par GitHub, a bloqué l'envoi. Le 3 septembre 2026, Tenable a annoncé le CyberAgents Exchange AI Inspector, un processus de revue de sécurité construit avec les modèles cyber d'OpenAI et appliqué aux agents, skills, serveurs MCP et playbooks multi-agents soumis à son registre, ouvert en août 2026 et crédité de plus de cent composants communautaires après un évènement de construction à Black Hat USA. Les deux faits se lisent ensemble : un éditeur de sécurité industrialise la revue de composants communautaires parce que la revue, dans le reste de la chaîne, n'a personne.

Devant ce genre de chiffre, le premier réflexe est de chercher le bon registre, celui qui filtre correctement. La documentation du registre officiel MCP répond à cette question, et la réponse n'est pas celle que l'on attend : le registre déclare déléguer le scan de sécurité aux registres de paquets sous-jacents, npm, PyPI, Docker Hub, et aux agrégateurs en aval, c'est-à-dire aux marketplaces. Lui se concentre sur l'authentification de namespace et l'hébergement de métadonnées. Les marketplaces en aval, elles, sont précisément celles que l'expérience d'OX Security a trouvées sans contrôle d'entrée. La délégation forme une boucle, et il n'y a pas de relecteur résident dedans. L'exposition n'est donc pas un mauvais registre à éviter, c'est une fonction de revue que personne dans la chaîne n'a jamais revendiquée.

Un composant agent tiers se comporte comme une dépendance de build. Il arrive dans votre poste de développement ou votre runtime d'agents, il s'exécute avec les droits de la session, et il modifie le comportement du modèle. Ce que vos équipes appliquent depuis dix ans à un paquet npm ou à une image de conteneur, soit un inventaire, une version figée, une signature vérifiée et une revue à l'entrée, ne s'applique presque nulle part à un serveur MCP ou à un skill communautaire. L'article du 20 août sur le contrôle qui existe sur le papier mais ne s'exécute pas décrivait un garde-fou inactif pendant onze mois sans produire une seule alerte. Ici, le garde-fou n'est pas inactif : il n'a jamais été écrit, et chaque acteur de la chaîne suppose de bonne foi qu'un autre l'a fait.

Une boucle de flèches fermée entre trois groupes d'éléments, enfermant un cercle en pointillés entièrement vide.
Le registre délègue au registre de paquets et aux marketplaces. Les marketplaces, elles, ont accepté neuf soumissions sur onze sans revue.

Ce qu'un composant agent tiers n'a pas, et qu'un paquet npm a depuis dix ans

Le registre officiel MCP ne distribue pas de code. Il distribue un fichier de métadonnées, server.json, qui porte le nom unique du serveur, l'endroit où le trouver, et les instructions d'exécution : la ligne de commande, les arguments, les variables d'environnement. Le code vit ailleurs, sur npm, PyPI ou Docker Hub. Le registre vérifie que le nom appartient bien à son propriétaire, par vérification DNS ou par un compte GitHub prouvé, ce qui règle l'usurpation de namespace. Il ne dit rien du contenu, et sa documentation ne prétend pas le faire.

Cette architecture a une conséquence directe sur ce que vous pouvez vérifier à l'installation. La vérification de namespace vous dit qui publie, pas ce que le paquet fait. C'est utile, et ce n'est pas une revue de code. La recherche d'OX Security a montré pourquoi l'écart compte : dans les SDK officiellement maintenus, en Python, TypeScript, Java et Rust, le champ command d'un serveur MCP en transport STDIO est exécuté sans condition, avant toute vérification que le sous-processus lancé est bien un serveur MCP. Une commande injectée qui se termine immédiatement renvoie une erreur au client, pendant que le processus continue en arrière-plan. Le périmètre estimé par les chercheurs porte sur plus de cent cinquante millions de téléchargements et jusqu'à deux cent mille instances exposées, avec une trentaine de divulgations coordonnées et une dizaine de CVE.

Les mots du composant agent tiers

Serveur MCP : composant qui expose des outils à un agent via le Model Context Protocol. Il déclare une liste d'outils avec leurs noms, descriptions et paramètres, et s'exécute soit localement en sous-processus, soit à distance derrière une URL.

Skill : paquet d'instructions et de fichiers qui étend le comportement d'un agent sur une tâche donnée. Il porte en général un fichier de consignes en langage naturel, parfois des scripts, et s'installe depuis un registre communautaire.

Playbook multi-agents : séquence orchestrée qui enchaîne plusieurs agents et plusieurs outils pour traiter un cas complet. Son périmètre d'accès est l'union de celui de ses composants, ce qui le rend plus difficile à cadrer qu'un outil isolé.

SBOM : nomenclature logicielle, soit la liste exhaustive des composants et versions qui entrent dans un livrable. Sans elle, personne ne peut répondre à la question de savoir où une dépendance compromise est installée dans le parc.

Pinning de version : fait de figer une dépendance sur une version précise, et idéalement sur une empreinte immuable, plutôt que sur une plage de versions qui laisse passer la mise à jour suivante sans décision humaine.

Le projet OWASP Agentic Skills Top 10, en version 1.0 pour l'édition 2026, classe la compromission de chaîne d'approvisionnement en deuxième risque, juste après les skills malveillants, et la dérive de mise à jour en septième. Ses recommandations vont dans le même sens que celles d'un dépôt logiciel classique : signature cryptographique et empreinte de contenu pour établir la provenance, verrouillage des dépendances imbriquées sur des empreintes immuables plutôt que sur des plages de versions, analyse comportementale au moment de la publication et de l'installation, et interdiction d'exécuter une configuration contrôlée par un dépôt avant une confirmation de confiance explicite. Rien de cette liste ne demande une technologie à inventer. Tout y demande un propriétaire nommé.

Ce que les registres de skills ont déjà produit

Les chiffres disponibles ne portent pas sur un risque théorique, ils portent sur des registres en production. En février 2026, Snyk a publié l'audit ToxicSkills sur 3 984 skills collectés depuis ClawHub et skills.sh. Les résultats : 534 skills, soit 13,4 %, portent au moins un problème de niveau critique, et 1 467, soit 36,8 %, au moins un défaut de sécurité. Soixante-seize charges malveillantes ont été confirmées, dont huit étaient encore accessibles publiquement au moment de la publication, et 10,9 % des skills de ClawHub contenaient des secrets en dur. Dans les échantillons malveillants confirmés, 91 % combinaient du code malveillant classique et de l'injection de prompt.

La même semaine, Antiy Labs a documenté la campagne ClawHavoc, détectée le 1er février 2026, qui visait le marché de skills du même écosystème. Le rapport identifie au moins 1 184 skills malveillants présents historiquement sur le registre, dont 677 attribués à un seul auteur, répartis sur douze identifiants de publication. La technique relevait de l'ingénierie sociale plutôt que de l'exploit : les instructions malveillantes étaient logées dans la documentation d'installation du skill, en présentant le téléchargement d'un fichier ou l'exécution d'une commande comme un prérequis. Les charges visaient les portefeuilles de cryptomonnaie, les identifiants de développeur et les clés d'API. La plupart des skills ont été retirés après la découverte, mais certains sont restés accessibles, l'un d'eux avec de l'ordre de quatorze mille téléchargements.

Les deux travaux ne mesurent pas la même chose, et l'écart mérite d'être nommé plutôt que lissé. Snyk compte les défauts dans un échantillon de skills publiés, Antiy compte les soumissions d'une campagne sur l'historique d'un registre, et une analyse tierce de l'écosystème retient un périmètre plus réduit, autour de neuf cents skills armés sur quatre mille cinq cents. La fourchette utile se situe donc entre plusieurs centaines et plus de mille soumissions malveillantes sur un seul registre communautaire, en quelques mois. Pour une décision d'admission, l'ordre de grandeur suffit : le taux de base n'est pas marginal.

Le cas qui change la nature du contrôle est ailleurs, et il est antérieur. Bishop Fox l'a documenté en mai 2026 à propos de postmark-mcp, un serveur MCP d'envoi d'e-mails qui a fonctionné normalement pendant quinze versions. La version 1.0.16 a ajouté une copie cachée vers une adresse contrôlée par l'attaquant sur chaque message sortant, et l'auteur de la modification était le développeur du composant lui-même. Une revue à l'installation aurait validé ce serveur quinze fois de suite, à juste titre. Ce qu'une revue à l'installation ne couvre pas, c'est la seizième version.

Sur le terrain, les équipes qui ont déjà vécu un incident de dépendance savent où le temps se perd. Ce n'est pas dans le retrait du composant, qui prend une heure. C'est dans la question posée juste après par la direction : où d'autre est-il installé. Un parc qui ne tient pas d'inventaire des serveurs MCP et des skills installés par poste et par environnement répond à cette question en interrogeant ses développeurs un par un, sur plusieurs jours, avec un résultat déclaratif. C'est le même scénario que celui d'une bibliothèque compromise, à ceci près que personne n'a encore outillé l'inventaire.

Schéma comparant les résultats de deux audits de registre et une frise de seize versions dont seule la dernière est compromise.
Les chiffres publiés en février 2026 sur un seul registre de skills, et le cas qui montre pourquoi la revue d'entrée ne suffit pas.

Le manifeste d'outils est une surface d'instruction, pas une documentation

Un serveur MCP déclare ses outils avec un nom, des paramètres et une description en langage naturel. Cette description n'est pas un commentaire destiné à un humain, c'est du texte qui entre dans le contexte du modèle et qui y porte la même autorité qu'une consigne système. La note de recherche de la Cloud Security Alliance sur l'empoisonnement de descriptions d'outils, publiée en juillet 2026, le formule en une phrase : le protocole mélange instructions et données dans le même canal, donc les métadonnées d'un outil pèsent autant sur le comportement de l'agent que le prompt système. Et ces descriptions ne sont presque jamais affichées à l'utilisateur, qui voit un résumé tronqué dans son interface.

La mesure existe. Le benchmark MCPTox, publié en août 2025, a testé vingt agents sur quarante-cinq serveurs MCP réels et trois cent cinquante-trois outils authentiques, avec 1 312 cas malveillants répartis en dix catégories de risque. Le taux de succès d'attaque monte à 72,8 % sur le modèle le plus vulnérable du panel, et les auteurs relèvent un résultat qui va contre l'intuition : les modèles les plus capables sont souvent les plus exposés, parce que l'attaque exploite précisément leur aptitude à suivre une instruction. Le taux de refus le plus élevé du panel reste sous les 3 %. Attendre que le modèle se protège lui-même d'un manifeste hostile n'est pas une stratégie.

Les mots de la revue de manifeste

Manifeste d'outils : la liste que le serveur MCP présente à l'agent au moment de la connexion, avec pour chaque outil son nom, sa description en langage naturel et le schéma de ses paramètres. C'est l'objet à relire, et c'est aussi l'objet qui change à chaque montée de version.

Tool poisoning : technique qui consiste à placer des instructions cachées dans la description ou les paramètres d'un outil, pour détourner le comportement de l'agent sans toucher au code exécuté. Elle ne laisse aucune trace dans une revue de code classique.

Dérive de mise à jour : écart entre la version d'un composant que vous avez relue et celle qui s'exécute réellement, introduit par une mise à jour automatique ou par une plage de versions laissée ouverte dans la configuration.

La conséquence opérationnelle est précise : l'objet de votre revue n'est pas le dépôt du composant, c'est son manifeste, et le différentiel de ce manifeste entre deux versions. La recommandation de la note CSA est de traiter un changement de description comme une modification de code en production, avec revue humaine explicite du différentiel, puis de verrouiller ces descriptions sous contrôle de version et d'y chercher les formulations impératives. C'est le seul endroit où une revue de trente minutes attrape une attaque qu'aucune analyse statique ne voit, parce qu'il n'y a pas de code à analyser.

Sept points d'admission, et un propriétaire nommé pour chacun

La décision d'installer un composant agent tiers ne se prend pas une fois pour le parc, elle se prend composant par composant, et elle se réinstruit à chaque montée de version. Sept points suffisent à couvrir ce que les travaux cités mettent en évidence, à condition que chacun ait un responsable nommé plutôt qu'une mention dans une politique.

La provenance d'abord. Exigez un propriétaire identifié et un namespace vérifié, et traitez cette vérification pour ce qu'elle est : une preuve d'identité de l'éditeur, pas une revue de contenu. Relevez dans le même geste où le code réside réellement, puisque le registre ne fait que pointer vers npm, PyPI ou une image de conteneur, et que c'est cette source que vous devrez surveiller.

Le manifeste ensuite. Extrayez la liste des outils exposés avec leurs descriptions complètes, lisez-les comme des consignes et non comme de la documentation, et refusez tout composant dont les descriptions contiennent des instructions adressées à l'agent plutôt qu'au lecteur. Conservez ce manifeste dans votre dépôt, c'est votre référence pour le différentiel de la prochaine version.

Le périmètre de secrets, troisième point, parce qu'il est le plus sous-estimé. Un serveur MCP lancé en sous-processus local hérite de l'environnement de la session : clés SSH, identifiants cloud, configurations Kubernetes, mots de passe de base de données, jetons de chaîne d'intégration continue, historique de shell. Bishop Fox a construit un serveur de démonstration dont l'intérêt est précisément de rendre visible cette liste. Décidez quelles variables d'environnement le composant reçoit, en liste d'autorisation et non en liste d'exclusion.

Le pinning et l'interdiction d'auto-mise-à-jour, quatrième point, et c'est la leçon directe de postmark-mcp. Figez la version, idéalement sur une empreinte immuable plutôt que sur un numéro, désactivez toute mise à jour automatique, et faites passer chaque montée de version par la même porte que la première installation. Une plage de versions ouverte dans un fichier de configuration est une délégation de décision à un inconnu.

L'exécution isolée, cinquième point, traité ici en une ligne parce qu'il relève du runtime et non de l'admission : décidez à l'entrée du composant s'il tourne dans un conteneur sans accès réseau sortant par défaut, et faites de cette réponse une condition d'admission plutôt qu'un réglage de poste de travail.

La journalisation des appels d'outils, sixième point. Sans trace des outils appelés, avec quels paramètres et pour quel résultat, vous ne pourrez ni détecter un comportement anormal ni reconstituer un incident. C'est la différence entre un composant que vous pouvez retirer avec un périmètre connu et un composant dont vous devrez supposer le pire.

L'inventaire, septième point, et le seul qui ne se décide pas composant par composant. Tenez la liste des serveurs MCP, skills et playbooks installés, par poste et par environnement, avec leur version. Le test de validité de cet inventaire tient en une question posée à froid : si une alerte publique nomme demain un composant, combien de temps pour savoir où il est installé. Si la réponse se compte en jours, l'inventaire n'existe pas.

L'initiative de Tenable et d'OpenAI est un signal utile à lire dans ce cadre, pas une dispense. Elle apporte une revue industrialisée sur les composants soumis à un registre précis, avec un périmètre de contrôle nommé : défauts logiciels, permissions excessives, traitement des données, faiblesse de la supervision. Elle ne couvre ni les composants que vos équipes installent ailleurs, ni la seizième version de l'un d'eux. Le fait marquant de cette annonce n'est pas la technologie employée, c'est qu'un éditeur de sécurité ait jugé nécessaire d'ajouter cette fonction parce qu'elle manquait.

À mettre en route cette semaine

Faites l'inventaire avant la politique. Demandez à vos équipes de développement la liste des serveurs MCP et des skills actuellement configurés sur leurs postes et dans vos environnements d'agents, avec la version et la source. Une demi-journée, et vous aurez le document qui conditionne tous les autres. Prévoyez d'être surpris par le nombre.

Extrayez le manifeste d'outils des trois composants tiers les plus utilisés dans votre parc et lisez les descriptions complètes, pas les résumés affichés dans l'interface. Cherchez les formulations impératives adressées au modèle. Le même passage vous donne la liste des variables d'environnement que chaque composant reçoit, ce qui est l'autre moitié du sujet.

Coupez les mises à jour automatiques sur ces composants et figez leurs versions, aujourd'hui, avant d'avoir écrit la politique d'admission. C'est l'action qui offre le meilleur rapport entre le temps investi et le risque retiré, et elle ne demande l'accord de personne.

Désignez un propriétaire pour la porte d'admission, et donnez-lui un délai de réponse engageant, de l'ordre de deux jours ouvrés. Une revue sans propriétaire nommé ni délai ne tient pas trois semaines face à un développeur qui a besoin d'un outil pour livrer, et un contournement officieux vaut moins qu'une porte lente mais réelle.

Conclusion

L'expérience d'OX Security sera citée pour son chiffre, neuf marketplaces sur onze, mais le document le plus instructif de ce dossier est la page de documentation du registre officiel MCP, qui écrit sans détour qu'elle délègue le scan de sécurité en amont aux registres de paquets et en aval aux marketplaces. Chaque maillon de la chaîne a été honnête sur ce qu'il ne fait pas, et l'addition de ces honnêtetés produit une absence de revue que personne n'a décidée. Les chiffres de février 2026 sur les registres de skills, plusieurs centaines de composants malveillants sur un seul marché, disent que l'absence est déjà exploitée. Tant qu'aucun acteur de la chaîne ne revendique la fonction, l'admission des composants agents tiers est une compétence interne, au même titre que la revue des dépendances logicielles l'est devenue il y a dix ans.

Sources : As of : Septembre 2026

Godwin AVODAGBE