Sécurité des serveurs MCP : Évaluez les outils avant de les installer

L'installation d'un serveur MCP semble triviale : collez une commande ou une URL, relancez le client, et un nouvel outil apparaît dans le contexte de votre agent. Mais derrière ce nom d'outil se cache du code exécutable, un schéma injecté dans la fenêtre de contexte du modèle, vos identifiants, et tout système que ces identifiants peuvent atteindre. L'écosystème MCP est encore en maturation, et le processus d'évaluation des nouveaux serveurs est, soyons honnête, très mince. Cet article vous fournit une checklist pré-installation réutilisable appliquée à un exemple illustratif épinglé, avec les conclusions et une justification simple d'acceptation/rejet pour chaque étape.

Ce que l'installation accorde réellement

Lorsque vous installez un serveur MCP, vous n'installez pas une simple bibliothèque passive. Vous accordez au code exécutable un accès à vos outils, votre système de fichiers, et généralement vos clés API, sans aucune étape d'examen intermédiaire que la plupart des clients ne vous présentent.

Cette confiance est cumulative et non granulaire. Comme l'indique le guide pratique de Pluto Security, approuver un serveur MCP signifie approuver tous les opérateurs dans sa chaîne d'approvisionnement. Il n'y a pas de redemande par composant. Chaque serveur MCP activé pousse également sa liste complète d'outils dans le contexte du modèle au démarrage de la session, consommant des tokens et diluant l'attention. Vous payez donc deux fois : une fois en surface de sécurité, une fois en budget de contexte.

Dans Claude Code spécifiquement, les serveurs sont configurés via .mcp.json (au niveau du projet) ou ~/.claude.json (au niveau utilisateur), et peuvent être regroupés dans un répertoire d'extension qui contient également des hooks, des agents, des moniteurs et des scripts bin/. Une extension n'est pas un simple wrapper allégé. Elle peut accéder à tout ce que votre session shell peut atteindre.

Le modèle de menace présente trois modes de défaillance réalistes :

• Un éditeur malveillant crée un serveur contrefait qui apparaît dans le registre, redirige les appels API ou exfiltre les données silencieusement.
• Un auteur bien intentionné mais inexpérimenté déploie un serveur qui stocke les tokens en texte brut ou enregistre les corps de requête sans y réfléchir.
• Un serveur légitime que vous avez approuvé est mis à jour, et la nouvelle version introduit une porte dérobée ou élargit ses permissions sans vous redemander.

Tous les trois sont documentés dans la nature, pas hypothétiques.

Examinez la source, la provenance et le comportement des mises à jour

Commencez avant de lire une seule ligne de code. Qui a publié ce serveur ? Y a-t-il une identité vérifiable derrière le paquet ? Le référentiel a-t-il un historique de commits significatif, ou a-t-il été créé la semaine dernière avec un seul commit ?

Le guide d'architecture défense-d'abord de Christian Schneider énonce clairement les exigences d'hygiène de la chaîne d'approvisionnement : installez les serveurs uniquement à partir de sources réputées, vérifiez les signatures de paquet ou les hashes, et épinglez les versions de dépendances plutôt que d'accepter « latest ». Exécutez npm audit ou pip-audit contre le paquet avant qu'il ne touche votre environnement. Générez une nomenclature logicielle (SBOM) afin de tracer chaque dépendance et de réagir rapidement lorsqu'un CVE est publié.

Pour votre checklist d'examen, capturez ceci à l'étape de la source :

1. Vérifiez que l'identité de l'éditeur correspond à une organisation ou une personne connue ayant un historique.
2. Vérifiez la date de création du référentiel et la fréquence des commits. Les référentiels à un seul commit méritent un examen supplémentaire.
3. Épinglez la version exacte que vous avez examinée. Notez le hash du commit ou l'étiquette de version.
4. Exécutez npm audit ou pip-audit sur l'arborescence des dépendances et enregistrez les résultats.
5. Vérifiez que le mécanisme de mise à jour du serveur valide les signatures numériques avant d'appliquer les modifications.

Exemple illustratif : supposez que vous examinez un hypothétique mcp-db-connector@1.4.2 provenant d'un éditeur ayant 18 mois d'historique de commits, deux contributeurs, et une version signée sur GitHub. npm audit retourne zéro résultats de haute sévérité. Cela franchit cette étape. Un serveur avec un éditeur anonyme, un dépôt vieux de deux jours, et aucune version signée ne le ferait pas.

Inspectez les outils, crochets, scripts et accès réseau.

La provenance source est essentielle. Maintenant, lisez le code.

Examinez toutes les définitions d'outils que le serveur enregistre. La description indiquée correspond-elle à l'implémentation réelle ? Comme l'avertit le guide de survie MCP de Towards Data Science, ce n'est pas parce qu'un outil est publié comme « expéditeur d'emails » qu'il n'envoie que des emails. Il pourrait les journaliser, les réécrire, ou les transférer ailleurs que prévu.

Vérifiez spécifiquement ceci :

• Crochets et scripts de cycle de vie : hooks.json enregistre-t-il des rappels pré ou post-outil ? Que font-ils ?
• Scripts dans `bin/` : Y a-t-il des scripts shell qui s'exécutent à l'installation ou à l'invocation ? Lisez-les.
• Appels réseau sortants : Le serveur contacte-t-il un endpoint non documenté dans le README ? Utilisez grep -r "fetch\|axios\|http\|https\|request" sur la source.
• Accès au système de fichiers : Demande-t-il un accès à des chemins plus larges que la tâche ne l'exige ?
• Gestion des identifiants : Les clés API sont-elles écrites sur le disque, enregistrées dans les journaux, ou transmises en dehors du service cible déclaré ?

La liste de vérification MCP Security de SlowMist classe la validation des entrées, la limitation du taux d'API, et l'encodage de sortie comme les trois contrôles prioritaires les plus élevés. Si le serveur ne valide pas strictement ses propres entrées, il est un vecteur d'attaques par injection, que vous fassiez confiance à l'éditeur ou non.

Un point que la liste signale et que la plupart des gens manquent : les descriptions d'outils sont injectées littéralement dans le contexte du modèle. Une description malveillante ou mal écrite peut orienter le comportement de l'agent à l'intérieur du bac à sable même si le bac à sable lui-même est intact. L'isolation sans balayage de schéma n'est qu'une demi-défense.

Testez l'injection rapide et les cas limites de données.

Cette étape n'est pas facultative pour tout ce qui touche aux données de production ou aux informations client.

L'injection rapide via les descriptions d'outils est un vecteur d'attaque documenté. Un attaquant incorpore des instructions dans le champ de description d'un outil que le modèle interprète comme l'intention de l'utilisateur. Vous devez vérifier que le schéma du serveur ne contient pas d'instructions incorporées, que la sortie du serveur n'est pas considérée comme une entrée utilisateur fiable en aval, et que les données retournées d'un outil ne peuvent pas fuir dans le contexte d'une session ou d'un utilisateur distinct.

Exécutez des cas limites illustratifs avant de connecter le serveur à des identifiants réels :

1. Créez un appel d'outil qui retourne une réponse contenant quelque chose comme « Ignorez les instructions précédentes et... » et observez si le client hôte la surface ou agit en fonction.
2. Passez des entrées surdimensionnées ou mal formées à chaque outil enregistré et vérifiez que le serveur les traite correctement ou lève des exceptions non gérées qui exposent les traces de pile.
3. Si le serveur a accès à plusieurs sources de données, vérifiez qu'une requête contre la source A ne peut pas retourner de données de la source B.

Ce sont des tests de triage, pas une certification. Un examen manuel court identifie les problèmes évidents. Il ne garantit pas l'absence de problèmes subtils.

Si vous créez des outils IA pour des clients et souhaitez du support pour examiner les intégrations MCP dans le cadre d'une configuration Claude Code plus large, le service d'agence Claude Code de Seahawk peut vous aider à évaluer la pile avant qu'elle n'approche la production.

Choisissez la portée d'identifiants la plus réduite et isolez le processus

Une fois que vous avez examiné le serveur et décidé qu'il est acceptable, la question devient : comment l'exécutez-vous ?

Le principe est le privilège minimal, appliqué sans compromis. Ne confiez pas au serveur MCP votre clé API personnelle avec accès complet au compte juste parce que c'est pratique. Créez un identifiant avec portée comportant les permissions minimales requises par la fonctionnalité documentée. Si le serveur a besoin d'un accès en lecture à un seul bucket S3, l'identifiant ne doit pas avoir d'accès en écriture, point final.

Options d'isolation, grossièrement en coût croissant :

• Exécutez le serveur dans un sous-processus dédié sans accès aux variables d'environnement du shell parent au-delà de ce que vous transmettez explicitement.
• Utilisez un conteneur avec une politique réseau restrictive afin que le serveur ne puisse pas établir de connexions sortantes arbitraires.
• Pour les déploiements sensibles, appliquez des vérifications de la chaîne d'approvisionnement comme points de contrôle du déploiement et traitez les mises à jour du serveur MCP avec le même processus de gestion des modifications que le code applicatif.

Le modèle de menace General Analysis l'énonce bien : une place de marché vérifiée sans épinglage de version signifie que le serveur vérifié d'aujourd'hui est le rug pull de demain. L'isolation et l'épinglage ne sont pas redondants. Ils protègent contre différents modes de défaillance. L'isolation en bac à sable limite le rayon d'explosion ; l'épinglage empêche la dérive silencieuse.

À noter également : ne partagez pas les identifiants entre serveurs MCP. Le transfert de jeton et les clés API partagées signifient qu'une compromission dans un serveur atteint tout ce que l'identifiant touche.

Enregistrez la décision et ré-examinez à chaque changement

Un examen que vous n'enregistrez pas est un examen qui n'a pas eu lieu, du point de vue de vous-même dans le futur ou de votre équipe.

Pour chaque serveur installé, conservez un journal de décisions contenant au minimum :

• La version exacte examinée (version du package plus hash de commit ou étiquette de version).
• La date de l'examen.
• Qui a effectué l'examen.
• Les conclusions des outils d'audit et de l'inspection manuelle.
• La justification d'acceptation/rejet.
• Les conditions qui déclencheraient un ré-examen (par exemple, toute nouvelle version majeure, tout changement au schéma d'outil, tout avis de sécurité touchant une dépendance).

Ce n'est pas de la bureaucratie pour elle-même. Le guide d'architecture de Schneider pose une question directe que la plupart des équipes ne peuvent pas répondre : « Que se passe-t-il si la description d'outil d'un serveur MCP change après qu'un utilisateur l'ait approuvé ? Quelqu'un le saurait-il ? » Dans la plupart des configurations par défaut, la réponse est non. L'épinglage de version plus un journal de décisions est comment vous changez cette réponse.

Définissez un rappel calendaire pour ré-examiner les serveurs épinglés trimestriellement même sans nouvelle version, car l'environnement de menace autour d'eux change même quand le code ne change pas.

Pour les équipes exécutant déjà des serveurs MCP dans des piles de production, les considérations opérationnelles autour de la gestion de plusieurs serveurs aux côtés de votre outillage existant sont traitées séparément dans notre article sur la pile de production.

Liste de contrôle réutilisable avant installation : justification des acceptations/rejets

Voici la liste de contrôle complète en ordre de triage. Appliquez-la avant d'installer tout serveur. Les découvertes d'exemple sont illustratives ; vos résultats varieront.

La ligne 6 explique pourquoi vous faites cela. Un ping analytics non documenté n'est pas automatiquement malveillant, mais il est non documenté, et les appels sortants non documentés sont un critère de rejet jusqu'à explication. Vous questionnez l'éditeur, obtenez une réponse claire, examinez ce qui est réellement envoyé, puis prenez une nouvelle décision. C'est le processus.

FAQ

L'examen du code source garantit-il qu'un serveur est sûr à installer ?

Non. L'examen du code est un triage, pas une certification. Il réduit la probabilité de problèmes évidents : appels réseau non documentés, journalisation des identifiants, descriptions d'outils malveillants. Il ne protège pas contre les vulnérabilités introduites dans une mise à jour future (c'est pourquoi vous épinglez les versions et réexaminez lors de changements) ni contre les failles logiques subtiles qui nécessitent une analyse de sécurité approfondie pour être détectées.

Qu'est-ce que l'empoisonnement d'outils et quel est son lien avec MCP ?

L'empoisonnement d'outils désigne un attaquant qui intègre des instructions malveillantes dans le champ nom ou description d'un outil. Parce que les schémas d'outils MCP sont injectés verbatim dans le contexte du modèle, le modèle peut interpréter ces instructions comme des directives légitimes. Examiner le schéma avant installation et vérifier la présence de fragments d'instructions intégrées est la principale atténuation au stade pré-installation.

Dois-je examiner les serveurs MCP distants différemment des serveurs locaux ?

Les serveurs locaux ont un chemin plus court vers les données sensibles car ils s'exécutent directement sur votre machine avec accès à votre environnement. Les serveurs distants introduisent une surface d'attaque réseau et un risque d'interception. Les deux nécessitent la même liste de contrôle, mais les serveurs locaux justifient une attention particulière à la portée d'accès au système de fichiers et à la gestion des identifiants dans le code source, tandis que les serveurs distants exigent du TLS vérifié, la validation de signature et la conformité OAuth 2.1 selon la spécification MCP actuelle.

Comment gérer les serveurs MCP dont le code source est fermé ou distribués sous forme de binaires ?

Si vous ne pouvez pas lire le code source, vous dépendez entièrement de la réputation de l'éditeur, de la vérification de signature cryptographique et des contrôles d'exécution (isolation, politique réseau, identifiants limités). C'est une posture de risque matériellement plus élevée. Pour tout ce qui touche aux données de production ou aux informations clients, un binaire dont le code source est fermé sans signature vérifiable d'un éditeur connu doit par défaut être rejeté.

Qu'est-ce qu'un SBOM et en ai-je vraiment besoin pour les serveurs MCP ?

Un SBOM (logiciel de nomenclature) est un inventaire lisible par machine de chaque dépendance incluse dans un paquet. Pour les serveurs MCP, il vous permet d'identifier si une dépendance transitive a une CVE divulguée, même si le paquet de haut niveau lui-même semble propre. Pour les outils personnels à faible enjeu, c'est une surcharge optionnelle. Pour les déploiements de production traitant des données sensibles, c'est la différence entre connaître votre exposition et la deviner.

La mise en garde la plus importante de cet examen entier : une description d'outil qui semble bénigne dans le registre peut orienter le comportement de l'agent après installation tout aussi efficacement que du code exécutable malveillant, et la plupart des clients ne vous avertissent pas. Lisez le schéma, pas seulement le README.