Votre serveur MCP est le maillon faible de votre stack

Un serveur MCP malveillant peut voler vos clés SSH sans jamais écrire une seule instruction malveillante complète. Le groupe de recherche ASSET l'a prouvé : quand un ordre de vol est donné à un modèle en un seul bloc, la plupart des grands modèles refusent. Fragmentez ce même ordre en morceaux d'apparence inoffensive, et GPT-4o, Gemini 2.0 Flash et Llama 3.3 obéissent dans 100 % des cas testés.

Pendant ce temps, la plupart des développeurs ajoutent un nouveau serveur MCP à leur agent chaque semaine, en copiant une ligne de config trouvée sur GitHub. Chacun de ces serveurs détient un morceau de votre accès : tokens API, clés cloud, comptes de service. MCP est utile — personne ne le nie. Mais le serveur MCP est devenu le maillon faible de toute la stack d'agents.

Cet article couvre comment un serveur MCP fuite vos secrets sans se faire remarquer, l'attaque GhostSplice qui contourne les refus des modèles en fragmentant ses instructions, et les défenses concrètes, de Cloudflare WriteGuard aux règles que vous pouvez appliquer dès aujourd'hui sur votre propre setup.

Un serveur MCP est le pont entre votre agent et un outil externe : votre base de données, votre GitHub, votre Slack, votre cloud. Pour faire ce travail de pont, il stocke tout ce dont il a besoin pour se connecter en votre nom — tokens, clés API, identifiants de comptes de service — en clair, dans un fichier de config sur votre disque, généralement sans aucun chiffrement.

Un détail de protocole compte pour la suite. Quand un agent se connecte à un serveur MCP, le serveur renvoie sa liste d'outils, chacun avec une description en texte libre qui indique au modèle quand et comment l'utiliser. Ces descriptions vont directement dans le contexte du modèle, avec le même poids que vos propres instructions, et les résultats renvoyés par les outils y vont aussi. Un serveur MCP parle sans arrêt à votre agent, dans un texte que personne ne relit jamais. C'est exactement ce qui rend l'attaque GhostSplice possible.

L'écosystème a aussi explosé plus vite que ses garde-fous :

Signal	Chiffre
Serveurs dans le registre officiel MCP	9 600+
Croissance des déploiements de serveurs distants depuis mai 2025	5×

N'importe qui peut publier un serveur, il n'y a aucune revue centrale, et votre agent fait confiance à chacun exactement comme à un outil officiel. La NSA a publié en mai un guide de sécurité dédié à MCP, affirmant que l'adoption du protocole a dépassé la construction de ses protections. Quand une agence de renseignement écrit un guide sur votre outil de développement préféré, ce n'est rarement pas pour vous féliciter.

Voilà le décor : des milliers de serveurs, aucune revue, et vos clés au milieu.

La première brèche, ce sont les identifiants stockés en clair. The Hacker News a publié une analyse détaillée des mécanismes de fuite le 17 août, et le constat de départ est brutal : les tokens sont collés directement dans des chaînes de configuration et restent lisibles sur disque. Un commit un peu trop rapide suffit à pousser une config dans un dépôt Git avec les clés à l'intérieur. Ça empire avec ce que l'article appelle l'éparpillement : les mêmes clés dupliquées dans plusieurs fichiers de config, des variables d'environnement, et des copies en dev, staging et production. Au bout d'un moment, plus personne ne sait où vivent les secrets, donc plus personne ne les fait tourner — et une clé statique qui ne tourne jamais est une clé qui attend son attaquant.

La deuxième brèche, ce sont les droits excessifs. Pendant le développement, vous donnez à votre serveur des droits larges pour éviter les erreurs d'autorisation, et ces droits larges partent tels quels en production. Une seule compromission expose alors bien plus que ce que l'usage réel justifiait.

La troisième brèche, c'est la supply chain. Le CVE-2025-6514 a touché mcp-remote, un proxy OAuth téléchargé plus de 400 000 fois, et permettait à un serveur malveillant de déclencher une injection de commande sur la machine de l'utilisateur — exécutant du code et repartant avec les identifiants. Un package npm populaire, installé en une ligne, et la porte était ouverte.

La quatrième brèche est la plus sournoise : l'injection de prompt. Un agent lit tout ce que ses outils ramènent — une page web, un ticket, un document interne. Si l'un d'eux contient une instruction cachée, l'agent peut la suivre comme si elle venait de vous, et utiliser ses outils légitimes pour exposer ce qu'il était censé protéger. Cette fuite ne passe par aucune faille technique ; elle passe par la naïveté du modèle.

Avant toute attaque sophistiquée, la vie ordinaire d'un serveur MCP — config en clair, droits excessifs, dépendances non vérifiées, contenu non filtré — expose déjà vos secrets.

GhostSplice est le nom que le groupe de recherche ASSET a donné à une technique qui fait exécuter l'exfiltration par votre propre agent, avec sa pleine coopération. Le principe tient en une phrase : au lieu d'écrire l'ordre de vol en entier, le serveur malveillant le fragmente, place un morceau dans la description d'un outil, et un autre dans le résultat que cet outil renvoie. Chaque morceau, lu seul, paraît inoffensif. Mais l'agent combine tout ce qui entre dans son contexte de travail : il reconstruit l'instruction complète et l'exécute en toute bonne foi — de son point de vue, il remplit simplement le formulaire que l'outil lui a demandé de remplir.

Les chiffres des tests racontent la vraie histoire :

Modèle	Instruction en un bloc	Instruction fragmentée
GPT-4o	Refuse à 100 %	Obéit à 100 %
Gemini 2.0 Flash	Refuse à 100 %	Obéit à 100 %
Llama 3.3	Refuse à 100 %	Obéit à 100 %
Claude Haiku 4.5	Refuse via l'API	Obéit à 100 % dans le test à trois morceaux sous Cursor

Le détail Claude tue toute conclusion facile : le même modèle peut refuser sur un client et exfiltrer sur un autre, selon les protections que ce client ajoute ou non.

Ce que GhostSplice vole dans les tests : clés SSH, secrets d'environnement, code source, données clients. Les chercheurs ont travaillé sur des projets isolés avec de fausses clés, pas sur de vraies victimes, mais la méthode est publiée et reproductible.

GhostSplice n'est pas un coup d'essai. Le même laboratoire a publié Ghostcommit en juin, une attaque qui cachait ses instructions dans des fichiers PNG référencés par les conventions d'un projet, puis encodait les secrets volés en entiers dans le code source. La fragmentation d'instructions est une famille d'attaques qui s'installe, pas une curiosité isolée.

Deux points permettent de garder les choses en perspective. L'attaque a deux prérequis : le serveur malveillant est déjà branché sur votre agent, et l'agent a un accès en lecture aux fichiers ciblés. C'est exactement pourquoi la provenance compte autant — d'où viennent vos serveurs est votre première ligne de défense. Et retenez la mécanique : l'alignement du modèle ne vous protège pas, parce que l'attaque ne demande jamais rien d'interdit d'un seul coup.

GhostSplice supposait un serveur malveillant déjà branché. Mais qui décide de ce qui se branche ? Dans une équipe, la réponse honnête est : personne. C'est le problème que Cloudflare appelle shadow MCP : tous les serveurs que les développeurs connectent à leurs agents sans aucune revue de sécurité. Jusqu'à récemment, ce trafic était invisible — une requête MCP ressemble à n'importe quel autre appel HTTPS.

Cloudflare a changé ça avec une détection au niveau du protocole. Depuis la mise à jour de la spec, chaque client MCP conforme envoie un en-tête MCP-Protocol-Version sur ses requêtes, et Gateway inspecte cet en-tête sur tout le trafic TLS qu'il déchiffre. Une équipe sécurité peut désormais voir chaque serveur MCP utilisé dans l'entreprise, avec un tableau de bord dédié : serveurs uniques, utilisateurs, volumes de requêtes. Cette approche par en-tête bat le filtrage par nom de domaine, parce qu'un serveur MCP n'a aucune raison de s'appeler mcp-quelque-chose — le protocole se repère à ce qu'il dit, pas à ce qu'il prétend être.

L'équipe peut aussi agir : un sélecteur is_mcp permet de bloquer tout trafic MCP qui n'est pas passé par un portail approuvé. Le portail est l'autre moitié du dispositif — un point d'accès unique qui regroupe les serveurs validés derrière une authentification d'identité.

La dernière version de la spec pousse la visibilité encore plus loin. Les nouveaux en-têtes Mcp-Method et Mcp-Name exposent l'opération demandée et l'outil appelé, sans que le pare-feu ait besoin d'ouvrir le corps de la requête. Une équipe peut distinguer un agent qui lit un ticket d'un agent qui en supprime cinquante, directement au niveau réseau.

Cloudflare distingue en fait deux cas : le shadow MCP pur, un serveur qui n'a jamais été approuvé, et le contournement de portail, un serveur approuvé atteint directement en dehors du point de contrôle. Les deux sont bloqués par la même règle de base. La logique est simple : tout ce qui passe par le portail est connu et journalisé, tout le reste est bloqué. Pour une entreprise, c'est la fin du serveur MCP fantôme installé un vendredi soir.

Même un serveur approuvé peut faire des dégâts, parce qu'un agent hérite d'un coup de tous les droits de son utilisateur. C'est là qu'intervient WriteGuard, que Cloudflare vient d'ouvrir en bêta privée. L'idée : classer chaque outil de chaque serveur MCP dans un niveau de risque, et appliquer une politique différente par niveau.

• Une lecture passe sans friction.
• Une écriture contenue, comme poster un commentaire, passe mais enrichie : l'action est signée comme venant d'un agent, au nom d'un humain précis, et un événement d'audit part vers un log central.
• Une action critique — fusionner du code, déployer en production, suppression massive — est bloquée avant même que le serveur ne la traite.

L'exemple GitLab du billet de Cloudflare montre bien la gradation : lire une merge request passe, la commenter passe avec attribution, et la fusionner est refusé tant qu'un humain ne le fait pas lui-même.

La partie la plus intéressante, c'est le modèle d'identité. L'agent garde les permissions de l'employé qu'il sert, mais chaque écriture porte désormais deux signatures : la personne, et la session d'agent qui agit pour elle. Les systèmes en aval peuvent enfin distinguer un changement fait main d'un changement généré par une machine, et l'audit part de manière asynchrone vers un log central, nettoyé des données sensibles. Jusqu'ici, un agent était indissociable de son humain dans les logs ; pour un audit d'incident, ça change tout — une seule requête suffit à savoir si le merge douteux de mardi vient d'un collègue pressé ou d'une session d'agent trop créative.

Cloudflare ne vend pas une théorie ; ils décrivent leur propre usage interne : leur portail connecte 27 serveurs MCP, contre 13 en avril. Ce chiffre raconte la vraie histoire — même chez Cloudflare, le nombre de serveurs double en quelques mois, ce qui est exactement pourquoi le contrôle outil par outil devient nécessaire. La direction que prend l'industrie est claire : arrêter de faire confiance au serveur entier, et décider action par action ce qu'un agent a le droit de faire.

Les limites doivent être dites clairement. WriteGuard est une bêta privée derrière un formulaire d'inscription, et la détection de Gateway nécessite un déploiement Cloudflare Zero Trust avec inspection TLS activée : pour un développeur solo ou une petite équipe, ce n'est tout simplement pas votre infrastructure. Même en entreprise, la détection ne voit que le trafic réseau qu'elle déchiffre — un serveur MCP local tournant en stdio, lancé comme un simple processus sur votre machine, reste invisible pour Gateway. Ce qui est exactement comment tournent la plupart des serveurs que les développeurs installent.

Surtout, aucun de ces outils ne répare le mécanisme central que GhostSplice a exposé : tant qu'un agent combine librement tout ce qui entre dans son contexte, des fragments inoffensifs continueront à se recomposer en instructions hostiles. Les chercheurs d'ASSET le disent eux-mêmes : la solution exige de traiter le résultat d'un outil comme une donnée, jamais comme une instruction, et cette séparation n'existe pas nativement chez les agents aujourd'hui.

En attendant, leurs recommandations tiennent en trois gestes : empêcher les valeurs sorties d'un outil d'alimenter sans vérification les arguments d'un autre outil, garder la possibilité de refuser chaque appel d'outil à la main, et traiter toute annotation venant d'un serveur non vérifié comme hostile par défaut. Aucun des trois n'est automatique aujourd'hui : vous l'appliquez, ou personne ne le fait. Traitez tout ce que Cloudflare livre ici comme une ceinture de sécurité, pas des freins — ça limite les dégâts, ça n'empêche pas la collision.

Ce qu'il faut faire, dès aujourd'hui :

1. Inventaire. Listez les serveurs MCP réellement branchés sur vos agents, et retirez ceux que vous n'utilisez plus.
2. Trier par provenance. Un serveur officiel d'un éditeur connu, oui. Un dépôt GitHub à 40 étoiles trouvé sur un forum, non — pas avant d'avoir lu ce qu'il fait de vos données.
3. Cadrer les droits. Donnez à chaque serveur un token dédié avec le scope minimal, jamais votre clé maîtresse, et faites tourner ces tokens comme pour n'importe quel système en production.
4. Garder la main sur les actions sensibles. Un agent qui écrit, fusionne ou supprime doit repasser par vous — la version artisanale de ce que WriteGuard industrialise.
5. Appliquer la règle GhostSplice au quotidien. Quand votre agent enchaîne des actions d'outils que vous n'avez pas demandées, arrêtez-le et lisez ce que le serveur lui racontait.

Chaque client d'agent peut lister ses serveurs connectés et leurs outils, et cette liste prend trente secondes à lire. Ces trente secondes offrent le meilleur ratio temps-sécurité de toute votre configuration.

Si vous êtes en entreprise, ajoutez la couche réseau : la détection MCP de Gateway et les portails valent le déploiement, parce que le shadow MCP existe déjà dans votre organisation, que vous le voyiez ou non.

MCP n'est pas le problème — la vitesse à laquelle on lui a confié nos clés en est un.