Le Model Context Protocol est ce qui branche un agent IA sur vos systèmes : vos dépôts, votre messagerie, votre base de données, vos billets.
Il s’est répandu comme se répandent les outils de développement, c’est-à-dire par les postes de travail et sans passer par une revue d’architecture. C’est la raison pour laquelle la question d’inventaire posée plus bas reste sans réponse dans la plupart des organisations.
Trois problèmes distincts, et il faut les séparer parce qu’ils ne se corrigent pas de la même manière.
1. Une faille de conception, confirmée comme intentionnelle
En avril 2026, OX Security divulgue un défaut systémique dans le transport STDIO. N’importe quelle commande passée à l’interface s’exécute sur le système hôte, qu’un serveur MCP valide soit initialisé ou non.
Ce n’est pas un bogue dans un produit. C’est un comportement par défaut présent dans tous les SDK officiellement supportés — Python, TypeScript, Java, Rust — et propagé dans tous les projets en aval qui ont fait confiance à l’implémentation de référence.
La Cloud Security Alliance chiffre la portée à environ 200 000 instances vulnérables, dans une chaîne d’approvisionnement de plus de 150 millions de téléchargements de paquets et plus de 7 000 serveurs publiquement accessibles.
Voici la partie qui devrait déterminer votre posture, et qui a été peu reprise : Anthropic a confirmé que ce comportement est intentionnel et n’a pas modifié l’architecture du protocole. La responsabilité de la correction revient à chaque développeur en aval.
La conséquence pratique est simple à énoncer. « On attend le correctif » n’est pas une position disponible ici. La CSA recommande de traiter l’infrastructure connectée en MCP comme une menace active et non corrigée.
2. L’authentification est optionnelle par spécification
Problème indépendant du premier, et plus banal.
La spécification d’autorisation MCP définit un cadre OAuth 2.1, puis marque explicitement l’autorisation comme optionnelle.
Un balayage d’Internet en juillet 2025 a identifié au moins 1 862 instances publiquement accessibles répondant à des requêtes non authentifiées.
Il n’y a rien de subtil là-dedans. C’est le cas classique du défaut permissif : le protocole rend une chose possible, la documentation la présente comme un choix, et le déploiement rapide prend le chemin qui fonctionne du premier coup.
3. La chaîne d’approvisionnement des serveurs eux-mêmes
En septembre 2025, Koi Security identifie le premier serveur MCP malveillant documenté publiquement.
postmark-mcp reproduisait un outil légitime d’envoi de courriels. La version 1.0.16, publiée le 17 septembre 2025, ajoute une ligne : une copie conforme invisible de chaque courriel sortant vers une adresse externe.
Environ 1 500 téléchargements par semaine, intégré dans des centaines de flux de travail de développement.
Une ligne. Aucune vulnérabilité exploitée, aucune sophistication. Le paquet a simplement fait ce que le mainteneur a décidé qu’il ferait, ce qui est le fonctionnement normal d’une dépendance.
Les catégories de risque à connaître
L’aide-mémoire MCP de l’OWASP en nomme quatre, et elles se reconnaissent une fois qu’on a les noms.
L’empoisonnement d’outil. La description d’un outil est du texte que le modèle lit et suit. Une description rédigée pour influencer le comportement de l’agent est une injection de prompt livrée par le canal auquel l’agent fait le plus confiance.
Le retrait du tapis. Un serveur se comporte correctement pendant l’évaluation, puis change après l’adoption. C’est postmark-mcp, exactement : quinze versions honnêtes, puis une seizième.
L’ombrage d’outil. Un serveur malveillant définit un outil qui en éclipse un autre, légitime, et intercepte les appels destinés à celui-ci.
Le député confus. Celle qui compte le plus dans une revue d’architecture. Le serveur MCP s’exécute avec ses propres privilèges, qui sont généralement larges, et non avec ceux de l’utilisateur qui a formulé la demande. L’agent demande, le serveur exécute avec ses droits à lui, et le contrôle d’accès que vous avez construit autour de l’utilisateur ne s’applique jamais.
Ce qu’il faut faire
La conclusion de la CSA est celle que je reprends telle quelle : traiter chaque serveur MCP comme un tiers non fiable, appliquer le zero trust à la couche d’intégration des outils, et opérer une gouvernance continue plutôt qu’un cycle de correction ponctuel.
Concrètement, dans l’ordre où ça se fait :
Inventorier. Quels serveurs MCP tournent, sur quels postes et dans quels pipelines. C’est la question à laquelle personne ne peut répondre aujourd’hui, et tout le reste en dépend.
Exiger OAuth 2.1 avec PKCE, et valider l’audience du jeton. Le cadre existe dans la spécification. Il faut simplement refuser de le traiter comme optionnel.
Épingler les versions. Le retrait du tapis est le mode de défaillance le plus probable des quatre, et l’épinglage est ce qui vous laisse le temps de le voir venir.
Mettre les serveurs locaux en bac à sable. La faille STDIO ne sera pas corrigée en amont. Ce qui reste est le confinement.
Vérifier l’intégrité des descriptions d’outils. Une description qui change entre deux versions est un événement de sécurité, pas une note de publication.
Journaliser par identité d’agent. Quel agent, pour le compte de qui, à travers quel outil. Sans ces trois éléments dans la même ligne de journal, la question « qui a fait ça » n’a pas de réponse.
La question d’inventaire
Elle vient en premier et elle est inconfortable, ce qui est normal.
Quels serveurs MCP tournent chez vous, avec quelles credentials, et qui les a approuvés ?
Dans la plupart des organisations, la réponse aux trois volets est la même : personne ne sait, parce que l’adoption a eu lieu poste par poste. Ce n’est pas une défaillance de gouvernance. C’est la façon dont l’outillage de développement est entré dans les entreprises depuis toujours, appliquée cette fois à un composant qui détient des credentials et exécute des commandes.
Besoin d’aide pour mettre cela en œuvre ?
Nous travaillons avec votre équipe pour concevoir, construire et exploiter les contrôles décrits ci-dessus.