Sécuriser les serveurs MCP que vos équipes installent

Vos équipes installent déjà des connecteurs MCP et des compétences d'agent depuis des dépôts publics. Comme elles installaient des paquets en 2018 : on cherche, on copie, ça marche. Le geste est le même, l'objet ne l'est pas. Voici ce qui change, et par où je commence. Si le protocole ne vous parle pas encore, je l'explique dans MCP, la prise standard entre l'IA et vos outils.

Pourquoi un serveur MCP n'est pas une bibliothèque comme les autres ?

Parce qu'une bibliothèque vous donne du code que vous appelez, quand vous le décidez, avec vos propres arguments. Un serveur MCP fait l'inverse. Il déclare des outils, décrit en langage naturel ce qu'ils font, et c'est le modèle qui décide de les appeler. Le modèle lit cette description comme une consigne, au même titre que la vôtre. Vous n'installez pas une fonction, vous installez une voix de plus dans la tête de votre agent.

La conséquence est simple. La revue de code et le gel des versions, qui vous protègent d'un paquet malveillant, ne couvrent pas ce cas : le serveur peut être irréprochable et sa description d'outil, elle, piégée. Ce qui décide n'est pas le fichier qu'inspectent vos outils d'analyse, c'est le texte que le modèle reçoit avant d'agir. C'est le terrain de la prompt injection, déplacé d'un cran plus haut.

Qu'est-ce qu'un serveur piégé peut faire, en clair ?

Quatre familles reviennent dans ce qui a été documenté en 2025 et en 2026. Aucune ne demande de piratage. Il suffit qu'un texte lu par le modèle ressemble à un ordre, et qu'un outil soit là pour l'exécuter.

• L'empoisonnement d'outil : la description contient une instruction cachée, que le modèle lit et suit avant même d'appeler l'outil.
• La redéfinition silencieuse : le serveur est honnête le jour de l'adoption, puis change de comportement à une mise à jour, sans nouvelle validation.
• L'outil qui en masque un autre : un serveur installé influence l'usage d'un serveur voisin, dans le même agent, sans y avoir été autorisé.
• La trifecta mortelle : des données privées, du contenu non fiable et un canal de sortie réunis dans le même agent. Séparément, les trois sont banales.

Ce ne sont pas des scénarios de laboratoire. En mars 2026, une porte dérobée est passée dans le paquet LiteLLM, très présent dans l'outillage IA ; l'avis de sécurité publié à la détection parle d'environ 47 000 téléchargements. La CVE-2025-6514, notée 9,6 sur l'échelle publique CVSS, décrit une exécution de code à distance chez le client, déclenchée par le seul fait de se connecter à un serveur MCP malveillant. Le top dix des applications agentiques publié en 2026 par l'OWASP, la référence ouverte en sécurité applicative, rattache l'injection de prompt à six de ses dix catégories. Je cite ces cas parce qu'ils sont publics, pas pour dramatiser.

La sécurité est-elle vraiment le premier frein ?

Oui, et ce sont les responsables techniques qui le disent. Dans l'étude sectorielle State of MCP in Software 2026, menée auprès de responsables américains et britanniques, la sécurité arrive en tête des freins à l'adoption, à 64 %. La même étude donne l'autre moitié du tableau : près d'une entreprise logicielle sur deux déclare un usage en production, mais 19 % seulement en production large. Le blocage n'est pas l'intérêt, c'est l'échelle. Un pilote se surveille à la main. Cent serveurs, non.

Qu'est-ce que la spécification a durci en juillet 2026 ?

La révision du 28 juillet 2026 s'attaque à l'authentification, autrement dit à la question de savoir qui parle à qui. C'est le morceau le plus mûr du sujet. Trois changements comptent.

• La validation de l'émetteur du jeton : le client vérifie d'où vient l'autorisation qu'on lui présente.
• Les identifiants client liés à l'émetteur : un identifiant valable chez l'un ne l'est plus chez l'autre.
• L'enregistrement dynamique de client, déprécié : un client inconnu ne s'inscrit plus tout seul en cours de route.

Ce que cette révision ne résout pas, elle ne prétend pas le résoudre. L'authentification dit qui parle, pas si ce qu'il dit est honnête : une description piégée passe toujours, avec un jeton parfaitement valide. Ni signature de code ni bac à sable obligatoires dans la spécification, et le registre officiel reste en préversion, avec quelques milliers de serveurs indexés d'après son propre compteur public. L'outillage progresse ailleurs : l'Agents SDK d'OpenAI a intégré le bac à sable nativement en avril 2026, d'après l'annonce de l'éditeur, avec une poignée de fournisseurs référencés.

Les skills posent-elles le même problème ?

Oui, parfois de façon plus crue. Une skill, c'est un dossier d'instructions et de scripts que le modèle charge et suit. Les relevés publiés début 2026 sur les registres publics vont d'une skill sur quatre à plus d'une sur trois porteuse d'au moins une faille, selon le périmètre retenu. Je les prends comme un ordre de grandeur, pas comme un taux. Là non plus, la spécification n'impose ni signature ni bac à sable. Le mécanisme complet, je le détaille dans les agent skills expliqués.

Que regarde-t-on avant d'autoriser un serveur ou une skill ?

Cinq points, et aucun ne demande de lire le code ligne à ligne. Le premier travail est de refuser l'installation par défaut : un composant tiers entre par une décision, pas par une commande copiée dans un terminal. C'est le métier de la fiabilité en production : on ne vise pas l'infaillible, on vise le contenable.

• L'origine et la version : qui publie, depuis quel dépôt, et quelle version est épinglée. Une mise à jour automatique, c'est une redéfinition silencieuse offerte.
• Les descriptions d'outils, lues comme du texte : ce que le modèle reçoit mot pour mot, et non ce que raconte le fichier de présentation.
• Le périmètre des droits : quelles données le serveur atteint, en lecture ou en écriture, et ce qu'il ne doit jamais atteindre.
• La sortie : par où une donnée peut quitter l'agent, et si les trois pièces de la trifecta se retrouvent au même endroit.
• L'exécution : où tourne le serveur, dans quel bac à sable, et ce que ses journaux permettent de reconstituer après coup.

Quelles questions poser à vos équipes, sans être technique ?

Quatre questions suffisent à savoir si le sujet est tenu ou subi. Aucune ne demande de connaître le protocole. Ce qu'elles demandent, c'est une réponse précise tout de suite. Comme pour évaluer un prestataire IA : la netteté de la réponse en dit plus long que son contenu.

• Qui a autorisé les serveurs MCP en place, et où est la liste ?
• Les versions sont-elles épinglées, ou une mise à jour peut-elle changer le comportement sans que personne ne revalide ?
• Quelles actions un agent déclenche-t-il seul, et lesquelles passent par une validation humaine ?
• Si une description d'outil était piégée demain, qu'est-ce qui limiterait les dégâts ?

Une revue ne prouve pas l'absence de faille. Elle prouve qu'un humain a regardé, et qu'on sait déjà quoi couper le jour où ça tourne mal.

Le sujet n'est pas de renoncer aux serveurs MCP : ils font gagner trop de temps pour ça, et je continue d'en installer. Il est de savoir lesquels tournent chez vous, avec quels droits, et qui a dit oui. Si vous voulez passer en revue ce qui est déjà branché, un premier échange suffit, sans engagement : parlons-en.