Brancher un outil sur un agent prend aujourd'hui trente secondes. On cherche un serveur d'outillage dans un catalogue, on copie trois lignes de configuration, on redémarre, et l'agent sait lire vos tickets, interroger votre base ou envoyer un message. Le geste est si court qu'il ne ressemble pas à une installation de logiciel. C'en est une.
Ce que l'on installe, c'est du code tiers qui s'exécute sur votre poste ou dans votre infrastructure, avec les droits que vous lui donnez, et qui écrit dans le contexte du modèle. Cette dernière propriété n'a aucun équivalent dans les chaînes d'approvisionnement logicielles classiques, et c'est elle qui rend la revue habituelle insuffisante.
Le principe du protocole d'outillage est décrit dans Le protocole d'outillage : standardiser l'accès aux outils. Cet article-ci traite la question d'après, celle que personne ne pose avant de coller les trois lignes : qu'est-ce qui a été vérifié, et par qui ?
Ce que le registre garantit, et ce qu'il dit ne pas garantir
Le registre officiel des serveurs d'outillage a une qualité rare : il documente ses propres limites, en clair, sur sa page de présentation. Deux phrases méritent d'être lues avant toute installation.
La première : le registre « délègue l'analyse de sécurité » aux registres de paquets sous-jacents — les mêmes que ceux du monde JavaScript, Python ou conteneur — et aux agrégateurs situés en aval, catalogues et places de marché. La seconde résume la position : il « se concentre sur l'authentification d'espace de noms et l'hébergement de métadonnées, en s'appuyant sur l'écosystème au sens large pour l'analyse de sécurité du code effectif des serveurs ».
Ajoutons une troisième, qu'on lit rarement jusqu'au bout : le registre « est actuellement en préversion », et « des changements incompatibles ou des remises à zéro des données peuvent survenir avant la disponibilité générale ».
| Ce que le registre fait | Ce qu'il délègue | Ce que personne ne fait à votre place |
|---|---|---|
| Authentifie l'espace de noms (le publieur est bien qui il prétend être) | L'analyse de sécurité du code, aux registres de paquets | Lire ce que fait réellement l'outil |
| Héberge des métadonnées normalisées : nom, emplacement, instructions d'exécution | La curation et les notes, aux agrégateurs en aval | Décider si l'outil mérite vos droits |
| Retire manuellement pourriels et serveurs malveillants signalés | Vous prévenir qu'une version a changé après votre revue |
Rien de tout cela n'est un défaut de conception : c'est une répartition explicite. Le problème n'est pas ce que le registre ne fait pas — c'est que la plupart des équipes croient qu'il le fait. Un catalogue officiel, un nom propre, une fiche bien remplie : le tout ressemble à un magasin d'applications, et un magasin d'applications, dans l'imaginaire commun, examine ce qu'il publie.
L'empoisonnement d'outil : la description est du contexte
Voici le point qui distingue cette chaîne d'approvisionnement de toutes les autres. Quand un serveur d'outillage déclare ses outils, il fournit pour chacun un nom, des paramètres et une description en langage naturel. Cette description n'est pas de la documentation : elle est injectée dans le contexte du modèle, pour qu'il sache quand appeler l'outil. Elle est donc, littéralement, une instruction lue par le modèle — écrite par le publieur du serveur.
Le référentiel public de risques du protocole a donné un identifiant à ce mécanisme : MCP03:2025 — Tool Poisoning. Sa définition part du schéma : « l'empoisonnement de schéma survient lorsqu'un adversaire altère le contrat ou les définitions de schéma qui gouvernent les interactions agent-outil ». L'effet recherché est de faire correspondre une opération d'apparence anodine à une action destructrice, de sorte qu'un agent de confiance exécute une commande dangereuse sans le savoir.
C'est une variante de l'injection décrite dans Injection de prompt : la faille de sécurité sans correctif, mais elle arrive par un canal que la plupart des défenses ne surveillent pas : non pas la donnée que l'agent lit, mais l'outillage qu'on lui a installé. Et elle s'apparente, côté chaîne, à ce que décrit Empoisonnement & portes dérobées : la chaîne d'appro d'un modèle — sauf qu'ici la charge tient en une phrase, sans réentraînement ni poids modifiés.
L'ampleur du problème n'est pas théorique : un banc d'essai public de l'empoisonnement d'outil a été construit sur 45 serveurs réels en fonctionnement et 353 outils authentiques, ce qui donne la mesure d'un écosystème assez vaste pour qu'une revue à l'œil ne tienne pas à l'échelle. Le référentiel de risques des applications agentiques publié pour 2026 range d'ailleurs le mauvais usage et l'exploitation des outils parmi ses menaces majeures, aux côtés de l'abus d'identité et de privilège traité dans l'article précédent.
Le décalage entre ce que vous avez revu et ce qui s'exécute
Deuxième asymétrie, plus banale mais tout aussi coûteuse. Le registre héberge des métadonnées qui pointent vers un paquet : la fiche dit « ce serveur, c'est ce paquet, à cette version ». Le code, lui, vit dans le registre de paquets, avec ses propres règles de publication.
Conséquence directe : la revue que vous faites aujourd'hui porte sur une version, et rien dans le geste d'installation par défaut ne vous garantit d'exécuter demain celle que vous avez lue. Les recommandations du référentiel vont exactement dans ce sens — signature numérique des schémas, registre immuable et versionné, métadonnées de provenance (auteur, empreinte, signature, horodatage), attestation du schéma et vérification à l'exécution. Autrement dit : ce qui a été approuvé doit être ce qui tourne, et il faut un moyen de le prouver au démarrage.
En attendant que ces mécanismes se généralisent, la parade est artisanale et efficace : épinglez la version, ne laissez aucune configuration chercher « la dernière », et conservez l'empreinte du paquet approuvé. Une mise à jour devient alors une décision, pas un effet de bord d'un redémarrage.
Le cloisonnement, faute de certificat
Puisque personne ne certifiera le code à votre place, la ligne de défense qui reste est celle de l'exécution : ne donnez à l'outillage ni plus de droits ni plus de portée que la tâche n'en réclame. C'est le sujet de Où s'exécute le code que votre agent écrit, et la même discipline s'applique au code que votre agent appelle.
Trois décisions suffisent à couvrir l'essentiel. Un : un serveur d'outillage qui touche à des données sensibles ne tourne pas sur le poste d'un développeur, où il voisine avec ses clés personnelles. Deux : les jetons qu'il utilise sont les siens, à sa taille, révocables — ce qui suppose le modèle d'identité décrit dans l'article précédent, et non un secret partagé recopié dans un fichier de configuration. Trois : les appels d'outils sont journalisés côté agent, avec leurs arguments. Sans ce journal, un empoisonnement réussi ne laisse aucune trace exploitable.
Ces trois décisions prolongent ce que décrit Connecter un agent IA à vos outils et vos données sans lui ouvrir toutes les portes, et complètent les défenses présentées dans Sécuriser ses agents contre l'injection de prompt.
Le protocole, à exécuter chez vous
- Inventoriez ce qui est déjà branché, poste par poste. Comptez les serveurs d'outillage installés, et pour chacun, la dernière date à laquelle quelqu'un a lu sa description d'outils. La colonne « jamais » sera la plus remplie.
- Extrayez les descriptions de tous les outils déclarés et passez-y une recherche automatique sur les indicateurs listés plus haut, caractères de largeur nulle compris. C'est mécanique et ça prend une heure.
- Épinglez les versions partout, et conservez les empreintes. Toute configuration qui récupère « la dernière » est à corriger avant d'aller plus loin.
- Rejouez la revue sur une mise à jour : mettez à jour un serveur volontairement, et vérifiez que la différence des descriptions vous est présentée avant application. Si personne ne voit cette différence, votre revue initiale ne protège rien.
- Testez le journal : déclenchez trois appels d'outils et retrouvez-les, avec leurs arguments, dans vos traces. Sinon, vous êtes aveugle au moment où ça compte.
- Décidez d'une liste courte autorisée, et faites du reste une demande explicite. Le catalogue ouvert est confortable ; il n'est pas gouvernable.
Trois articles, trois moments d'une même bascule : l'agent emprunte votre session, puis reçoit ses propres clés, puis tire du code que personne n'a lu. Si vous n'en retenez qu'une règle, prenez celle-ci — tout ce que vous ne cloisonnez pas explicitement, vous l'accordez. Pour reprendre la série depuis le début, l'article L'agent navigue dans votre session, pas dans la sienne ouvre la question. Les mouvements du domaine sont suivis dans le radar IA et dans le bulletin Nouveautés.
Une question, un projet IA ?
Vous voulez une liste courte de serveurs d'outillage autorisés, et une revue qui tienne à l'échelle de vos équipes ? Échangeons sur votre contexte.
Prendre contact →