Shadow MCP : les serveurs MCP non gouvernés que vos équipes ont déjà branchés

En 2025, une organisation sur cinq étudiées par IBM a déclaré une fuite de données liée au shadow AI, et celles où le shadow AI était très répandu ont supporté un surcoût moyen de 670 000 dollars par incident. Ce chiffre mesure la première vague : des employés qui collent des données de l’entreprise dans des chatbots grand public. La deuxième vague est déjà là, et elle se voit moins. Vos équipes ne se contentent plus de discuter avec l’IA. Elles la branchent à leur messagerie, à leur CRM, à leur code et à leurs fichiers, un serveur MCP à la fois.

Appelons cela le shadow MCP.

Qu’est-ce que le shadow MCP ?

Le shadow MCP, ce sont les serveurs MCP que les employés branchent eux-mêmes à leur client IA, hors de toute revue de l’IT ou de la sécurité, avec leurs accès personnels. Personne ne les a validés, personne n’en tient l’inventaire, et personne ne peut dire ce qu’ils ont fait hier.

MCP, le Model Context Protocol qu’Anthropic a publié en open source en novembre 2024, est la façon standard de brancher des outils sur un agent IA. Un serveur MCP expose des actions (envoyer un e-mail, interroger une base de données, ouvrir une demande de modification de code) que Claude, ChatGPT, Copilot ou un agent de développement peuvent appeler. C’est un bon standard. Le problème, c’est qui branche les serveurs, et comment.

Si la notion de shadow AI est nouvelle pour vous, commencez par ce qu’est le shadow AI et pourquoi l’interdire ne marche pas. Le shadow MCP en est l’étape suivante.

Comment le shadow MCP s’installe

Aucune procédure d’achat ne l’arrête, parce qu’il entre par trois portes dérobées :

1. Des serveurs locaux sur les postes des développeurs. Les agents intégrés aux éditeurs de code et les applications de bureau lancent des serveurs MCP à partir d’une ligne de configuration, le plus souvent un paquet tiré d’un dépôt public. Il tourne sur le poste, avec les accès du poste.
2. Des connecteurs personnels. Sur les offres individuelles de Claude, chaque utilisateur ajoute lui-même ses connecteurs personnalisés ; sur les offres Team et Enterprise, seuls les propriétaires du compte le peuvent. Le mode développeur de ChatGPT offre un support MCP complet, en lecture et en écriture, y compris sur les offres individuelles. Un compte personnel et un connecteur personnel suffisent à mettre les systèmes de l’entreprise à une requête d’un outil que personne n’a vérifié.
3. Des serveurs faits maison. Une équipe enveloppe une API interne dans un serveur MCP vite écrit pour gagner du temps, partage la configuration dans une discussion, et le voilà devenu, sans bruit, de l’infrastructure.

Rien de tout cela n’est malveillant. Ce sont des gens qui veulent travailler plus vite, exactement comme lors de la première vague du shadow AI. Le Work Trend Index 2024 de Microsoft et LinkedIn relevait déjà que 78 % des utilisateurs d’IA apportaient leurs propres outils au travail. Les outils qui agissent sont simplement la suite logique.

Pourquoi le shadow MCP est plus risqué que le shadow AI

Le shadow AI laisse fuir ce que quelqu’un colle. Le shadow MCP agit avec tout ce que quelqu’un peut atteindre. Un agent doté d’un connecteur de messagerie et d’un connecteur de fichiers peut lire, envoyer, déplacer et supprimer, avec tous les droits de l’employé, en suivant des instructions qui ne viennent pas forcément de lui. Ces risques n’ont rien de théorique : chacun des cas ci-dessous est documenté publiquement.

Un serveur de confiance peut changer de camp

En septembre 2025, Postmark a averti qu’un paquet nommé postmark-mcp, qu’elle n’avait jamais publié, copiait les e-mails qu’il envoyait vers un serveur externe. L’usurpateur avait publié quinze versions saines pour gagner la confiance des utilisateurs, avant d’ajouter la copie cachée dans la version 1.0.16. Quiconque l’avait choisi par son nom dans un dépôt public et était passé à cette version était exposé.

Une description d’outil peut contenir des ordres

En avril 2025, Invariant Labs a décrit les attaques par empoisonnement d’outils : des instructions cachées dans la description d’un outil, invisibles pour l’utilisateur mais lues par le modèle, qui peuvent amener l’agent à exfiltrer des données par un autre serveur, parfaitement légitime. La même étude décrit le « rug pull » : un serveur modifie la description de ses outils après que l’utilisateur les a approuvés. Le centre d’aide d’Anthropic le dit sans détour : des serveurs MCP malveillants peuvent contenir des instructions cachées, il ne faut donc brancher que des serveurs d’organisations de confiance.

La tuyauterie a des fuites

En juillet 2025, JFrog a publié la CVE-2025-6514, une faille critique (score CVSS de 9,6) dans mcp-remote, un proxy très utilisé pour relier les clients à des serveurs MCP distants : se connecter à un serveur non fiable pouvait conduire à l’exécution de commandes sur le poste de l’utilisateur. Un mois plus tôt, Backslash Security avait recensé des centaines de serveurs MCP ouverts sur toutes les interfaces réseau, accessibles à quiconque se trouvait sur le même réseau, et des dizaines qui permettaient d’exécuter n’importe quelle commande sur la machine hôte.

Rien n’est consigné

Quand un connecteur que personne n’a enregistré traite des données clients, c’est un traitement que personne n’a inscrit au registre. Le RGPD impose de tenir un registre des activités de traitement (article 30) et de ne recourir qu’à des sous-traitants présentant des garanties suffisantes (article 28) ; la nLPD suisse prévoit une obligation de registre comparable (article 12). La spécification MCP elle-même range le problème de l’audit parmi ses bonnes pratiques de sécurité : quand des jetons d’accès sont relayés sans contrôle, les journaux attribuent les requêtes à la mauvaise identité et l’enquête sur un incident devient plus difficile. Le rapport d’IBM dit la même chose sous un autre angle : 63 % des organisations victimes d’une fuite n’avaient pas de politique de gouvernance de l’IA, ou étaient encore en train de la rédiger.

Pourquoi interdire MCP ne marchera pas

Le premier réflexe est de bloquer. Cela échoue pour la même raison que l’interdiction de ChatGPT a échoué : MCP est intégré aux clients que vos équipes utilisent déjà, et le gain de productivité est réel. Bloquez-le sur les postes gérés, il se déplace vers les comptes personnels, où vous voyez encore moins. Les éditeurs le reconnaissent : OpenAI qualifie son mode développeur de « puissant mais dangereux » et le propose malgré tout, parce que c’est dans les agents connectés que se trouve la valeur.

L’objectif n’est pas zéro MCP. C’est zéro MCP invisible.

Comment gouverner MCP sans le bloquer

Cinq gestes, dans cet ordre :

1. Faites l’inventaire. Listez les serveurs MCP déjà configurés dans vos clients IA et vos éditeurs de code, ainsi que les autorisations OAuth accordées aux connecteurs. On ne gouverne pas ce qu’on n’a pas compté.
2. Constituez un registre interne et curé. Une liste courte de serveurs revus, dotés d’accès et de périmètres définis pour votre organisation. Les registres publics aident à découvrir des serveurs ; ils ne les autorisent pas. L’annonce du registre officiel par le projet MCP prévoit elle-même que les entreprises aux exigences de sécurité strictes tiennent des sous-registres privés.
3. Fermez les portes dérobées avec les réglages que vous avez déjà. Sur les offres Claude Team et Enterprise, seuls les propriétaires peuvent ajouter des connecteurs personnalisés ; appuyez-vous sur ce réglage, et sur son équivalent dans vos autres clients, pour que le registre soit le seul point d’entrée.
4. Accordez le minimum, figez la version. Donnez à chaque serveur les accès les plus étroits qui suffisent à sa tâche, comme la spécification MCP le recommande avec la minimisation des périmètres, et figez les versions pour qu’une mise à jour soit une décision, pas une surprise.
5. Journalisez chaque appel, et rendez le chemin officiel plus simple. Chaque appel d’outil rattaché à la personne qui l’a lancé. Puis livrez les serveurs approuvés avec les instructions qui permettent de bien s’en servir, pour que l’option gouvernée soit plus rapide que le contournement. Composer des skills au-dessus des outils MCP est ce qui garde l’ensemble utilisable.

Ce dernier point décide de l’issue. Comme le shadow AI, le shadow MCP est un problème de produit avant d’être un problème de discipline : on contourne un processus quand il est plus lent que le contournement. Il en va de même pour les skills : un SKILL.md qui circule hors de tout catalogue est la version savoir-faire de la même fuite.

La place de skilder

La réponse de skilder au shadow MCP est structurelle. Chaque workspace dispose d’un registre interne et curé de serveurs MCP : des serveurs vérifiés et préconfigurés (revus, dotés d’accès et de périmètres définis), pas un index de tous les serveurs qui existent. Y ajouter un serveur est l’étape d’autorisation centrale. Les serveurs atteignent ensuite les équipes par les rôles : un rôle, c’est le travail que fait réellement un poste de l’organigramme, réunissant des skills, des outils MCP au périmètre défini et des permissions, et il ne peut atteindre que des serveurs déjà présents dans le registre. Les connecteurs sont autorisés de façon centrale et révocables, et chaque tâche est journalisée et attribuable à la personne qui l’a lancée. Le même registre sert Claude, ChatGPT et Copilot.

Ce n’est pas un annuaire public de serveurs MCP, et il ne cherche pas à l’être. Son rôle est l’inverse : garder la liste courte, connue et maîtrisée. La tenue de ce principe, des serveurs atteints seulement à travers des rôles appris, face à des prompts adverses est ce que mesure le papier sur la découverte progressive des skills. La place de ce registre à côté d’une passerelle de modèles ou d’agents est détaillée dans LiteLLM vs agentgateway vs skilder.

En résumé

Le shadow AI a appris aux organisations qu’on ne se débarrasse pas par l’interdiction d’un outil que les gens trouvent utile. Le shadow MCP élève l’enjeu, parce que l’outil agit désormais. La réponse est la même, un cran plus haut : voir ce qui est branché, proposer un chemin gouverné au moins aussi bon, et garder la trace de ce que les agents ont fait.

Pour situer votre organisation en matière de contrôle et de traçabilité, le bilan IA en 10 questions prend deux minutes et ne vous demande rien.

Questions fréquentes

Qu'est-ce que le shadow MCP ? +

Le shadow MCP désigne les serveurs MCP (Model Context Protocol) que les employés branchent eux-mêmes à leur client IA, hors de toute revue de l'IT ou de la sécurité : paquets installés depuis des dépôts publics, serveurs lancés sur un poste de travail, ou adresses distantes ajoutées comme connecteurs personnels. Ils tournent avec les accès personnels de l'employé, et personne n'en tient l'inventaire.

Quelle différence entre shadow MCP et shadow AI ? +

Le shadow AI concerne les données qui sortent : un employé colle un contrat ou un fichier clients dans un chatbot grand public. Le shadow MCP concerne les actions qui entrent : un serveur MCP permet à l'agent de lire et d'écrire dans les systèmes de l'entreprise (messagerie, CRM, code, fichiers) via un outil que personne n'a vérifié. L'exposition ne se limite plus à ce qui a été tapé : elle s'étend à tout ce que les accès connectés permettent d'atteindre.

Les serveurs MCP sont-ils sûrs en entreprise ? +

Le protocole n'est pas le problème ; les serveurs non vérifiés, si. Des incidents publics le montrent : un faux paquet postmark-mcp publié sur npm copiait en secret chaque e-mail envoyé vers une adresse externe, et une faille critique (CVE-2025-6514, score CVSS de 9,6) dans le proxy mcp-remote permettait d'exécuter du code lors d'une connexion à un serveur non fiable. Un serveur revu, figé sur une version, doté d'accès restreints et journalisé n'a rien à voir avec un serveur installé depuis un résultat de recherche.

Comment gouverner les serveurs MCP sans les bloquer ? +

Cinq étapes : faire l'inventaire de ce qui est déjà branché ; constituer un registre interne et curé de serveurs revus, dotés d'accès et de périmètres définis ; utiliser les réglages d'administration de vos clients IA pour que seul ce registre soit accessible ; figer les versions et examiner chaque mise à jour ; journaliser chaque appel d'outil, rattaché à la personne qui l'a lancé. Puis rendre le chemin officiel plus simple que le contournement, pour que personne n'ait de raison de l'éviter.

Une entreprise doit-elle s'appuyer sur un registre MCP public ? +

Un registre public sert à découvrir des serveurs : le registre MCP officiel recense des serveurs publiquement disponibles. Ce n'est pas une autorisation. Le projet MCP prévoit lui-même que les entreprises aux exigences de sécurité strictes tiennent des sous-registres privés. Ce que vos équipes peuvent atteindre doit venir d'une liste interne et curée, pas d'un annuaire public.