La sécurité des serveurs MCP commence par une règle brutale : traitez chaque serveur MCP comme un logiciel capable d’accéder à vos données, d’appeler des outils et d’influencer le prochain mouvement d’un agent d’IA. Le Model Context Protocol est utile parce qu’il relie les assistants à des ressources, des invites et des outils exécutables, mais cette même conception crée des risques en matière d’autorisation, d’injection de prompts, d’exécution de commandes et d’exfiltration de données.
Pourquoi la sécurité des serveurs MCP est différente de la sécurité API ordinaire
Anthropic a publié le Model Context Protocol le 25 novembre 2024 comme protocole ouvert permettant de connecter des applications d’IA à des sources de données et des outils externes. Selon la spécification du 25 novembre 2025, les serveurs MCP fournissent trois éléments principaux : des ressources, des prompts et des outils. Les outils sont la partie la plus tranchante. Ce sont des fonctions que le modèle peut exécuter.
Une API normale attend qu’un client déterministe fasse une requête. Un serveur MCP peut se trouver derrière un hôte d’IA qui interprète l’intention de l’utilisateur, lit les descriptions des outils, sélectionne des actions et, parfois, enchaîne plusieurs serveurs ensemble. Cela fait de la sécurité des serveurs mcp en partie un problème de sécurité des applications et en partie un problème de contrôle des agents.
La politique officielle de sécurité MCP, publiée sur GitHub et référencée en 2026, est rafraîchissante de franchise : les clients MCP font confiance aux serveurs auxquels ils se connectent, et les serveurs MCP locaux doivent être considérés comme dignes de confiance au même titre que des logiciels installés. C’est le bon modèle mental. Si vous n’installeriez pas une application de bureau non signée provenant d’un dépôt aléatoire sur un ordinateur financier portable, ne connectez pas le client d’IA de cette même machine à un serveur d’outils aléatoire ayant accès au système de fichiers ou au réseau.
Si vous construisez des workflows agentiques, le risque opérationnel ressemble davantage à de la livraison logicielle autonome qu’à un widget de chat. La même prudence s’applique aux boucles de codage IA et aux modifications non supervisées ; notre guide sur l’ingénierie des boucles pour les systèmes d’IA est pertinent parce que les outils MCP deviennent souvent les mains de ces boucles.
Le modèle de menace fondamental : outils, confiance et mouvement des données
Commencez par ce que le serveur peut réellement faire. Un serveur en lecture seule qui expose de la documentation publique est très différent d’un serveur capable d’interroger des bases de données de production, d’envoyer des messages Slack, de créer des pull requests GitHub ou d’initier des paiements. Honnêtement, appeler les deux « un serveur MCP » peut masquer la différence de risque.
La spécification MCP indique que les hôtes doivent obtenir le consentement explicite de l’utilisateur avant d’invoquer un outil et avant d’exposer les données de l’utilisateur aux serveurs. Ne considérez pas cela comme une simple commodité UX. C’est une frontière de sécurité, et une frontière fragile si votre hôte affiche des invites vagues telles que « Autoriser l’accès ? » sans indiquer le serveur cible, le nom de l’outil, la catégorie de données et la conséquence.
Le guide pratique 2026 de l’OWASP pour le développement sécurisé de serveurs MCP met l’accent sur une architecture sécurisée, une authentification et une autorisation robustes, une validation stricte, l’isolation des sessions et un déploiement renforcé. Ce sont des termes familiers, mais MCP leur donne une tournure particulière : une réponse malveillante peut être lue par le modèle comme une instruction, et pas seulement affichée comme une donnée.
Voici l’écueil que beaucoup d’équipes manquent : la partie dangereuse peut être un outil que vous n’avez pas appelé directement. Dans une configuration multi-serveurs, un serveur à faibles privilèges peut renvoyer un texte qui pousse l’agent à appeler un outil privilégié sur un autre serveur. C’est une propagation implicite de la confiance, et un article arXiv de janvier 2026 intitulé « Breaking the Protocol » l’a signalée comme l’une des trois préoccupations au niveau du protocole, aux côtés de l’absence d’attestation des capacités et de l’échantillonnage bidirectionnel sans authentification de l’origine.
Où s’insère l’authentification dans la sécurité des serveurs mcp
La spécification d’autorisation MCP du 18 juin 2025 définit une autorisation basée sur HTTP utilisant OAuth 2.1, OAuth Authorization Server Metadata, Dynamic Client Registration et Protected Resource Metadata. Si votre serveur est accessible via HTTP, vous devriez lire cette spécification, et non improviser la gestion des bearer tokens dans une branche bricolée en un week-end.
L’autorisation est toutefois facultative dans le protocole. Cette phrase devrait vous faire réfléchir. La spécification indique que les transports HTTP doivent suivre la spécification d’autorisation MCP, que les transports STDIO doivent récupérer les identifiants depuis l’environnement et que les transports alternatifs doivent suivre les pratiques de sécurité de leur propre protocole.
Une authentification de protocole facultative ne signifie pas une sécurité facultative. Cela signifie que la responsabilité vous incombe. Pour la sécurité des serveurs mcp, vous devez décider quelles identités existent : l’utilisateur humain, l’application hôte, le client MCP, le serveur et le compte de service en aval. Si tout cela se réduit à un seul jeton tout-puissant, la capacité d’audit en souffre et une compromission fait davantage de dégâts.
Un schéma pratique consiste à séparer l’autorisation utilisateur de l’autorisation des outils. Un utilisateur peut être autorisé à se connecter à un serveur MCP CRM, mais ne pas être autorisé à exécuter « export_all_contacts » ou « delete_account_notes ». Si vous raisonnez déjà en termes de renforcement de l’identité, les modes de défaillance ressemblent aux problèmes de MFA et d’abus de session abordés dans notre analyse de l’avertissement MFA de Microsoft 365: l’authentification seule ne vous sauve pas lorsque les sessions et les permissions sont trop étendues.
Vulnérabilités connues et ce qu’elles enseignent
La vulnérabilité publique la plus concrète dans l’enregistrement fourni est CVE-2025-6514, publiée par NVD le 9 juillet 2025. Elle affectait le package npm mcp-remote versions 0.0.5 jusqu’à 0.1.15, et NVD l’a classée comme CWE-78 Injection de commandes OS.
La vulnérabilité impliquait une connexion à des serveurs MCP non fiables via des URL de réponse authorization_endpoint fabriquées. Son vecteur CVSS v3.1 était AV:N/AC:L/PR:N/UI:R/S:C/C:H/I:H/A:H. En clair : vecteur d’attaque réseau, faible complexité d’attaque, aucun privilège requis, interaction utilisateur requise, portée modifiée, et impact élevé sur la confidentialité, l’intégrité et la disponibilité.
| Problème ou élément de recherche | Année | Ce qui a été signalé | Leçon de sécurité |
|---|---|---|---|
CVE-2025-6514 dans mcp-remote |
2025 | Injection de commandes OS dans les versions 0.0.5 jusqu’à 0.1.15 |
Ne faites pas confiance aux métadonnées d’autorisation fournies par le serveur sans validation |
| OWASP MCP Tool Poisoning | 2026 | Des réponses d’outils malveillantes peuvent déclencher des appels restreints, des fuites ou des contournements de prompt | Traitez la sortie des outils comme une entrée non fiable, et non comme des instructions |
| Prépublication arXiv « MCP Pitfall Lab » | 2026 | Le durcissement aurait réduit les conclusions de niveau 1 de 29 à 0 pour un coût moyen de 27 lignes de code | De petites modifications du code peuvent éliminer des catégories majeures d’exposition |
| Analyse LangSight | 2026 | A signalé 8,247 serveurs MCP exposés sans authentification | L’exposition sur Internet se produit déjà à grande échelle |
| Recherche TrueFoundry | 2026 | A signalé 492 serveurs MCP exposés publiquement, dépourvus d’authentification ou de chiffrement de base | L’hygiène de base du transport et de l’authentification échoue encore dans les déploiements réels |
Ces chiffres sur l’exposition à Internet proviennent de recherches menées par des fournisseurs, et non d’un organisme de normalisation ; il faut donc les considérer comme des signaux d’alerte plutôt que comme des données de recensement. Cela dit, la tendance est évidente. Les équipes publient des points de terminaison MCP plus vite qu’elles n’en modélisent les menaces.
Faites un calcul simple. Si un serveur exposé dispose de quatre outils, et qu’un seul outil peut lire des tickets internes, résumer des documents ou envoyer des messages, une seule réponse empoisonnée peut créer quatre points de décision où l’agent peut être orienté. Multipliez cela par 50 serveurs internes et vous n’examinez plus « une intégration de chatbot ». Vous examinez une infrastructure d’automatisation distribuée.
Empoisonnement d’outils : le risque que les scanners ordinaires ne détectent pas
OWASP décrit l’empoisonnement d’outils MCP comme une injection indirecte de prompts via des réponses d’outils MCP malveillantes. Les conséquences peuvent être graves : un agent peut appeler des outils restreints, divulguer des données ou contourner les prompts système parce qu’un outil a renvoyé un contenu ressemblant à une instruction.
Les scanners de sécurité classiques recherchent les injections SQL, les injections de commandes, la traversée de chemin et les secrets exposés. Utile. Mais ils ne comprendront pas de manière fiable qu’un champ JSON nommé summary contient un langage demandant au modèle d’ignorer les règles précédentes et d’envoyer des identifiants à un autre outil.
Une bonne sécurité du serveur mcp exige donc une discipline des sorties. Les recommandations de prévention d’OWASP incluent des sorties structurées à schéma fixe, l’isolation des outils privilégiés, des contrôles d’accès côté serveur, des listes d’autorisation de serveurs approuvés, le principe du moindre privilège et une confirmation utilisateur hors bande pour les actions sensibles ou entraînant une exfiltration. Je placerais les schémas fixes tout en haut de la liste. C’est dans la prose libre que commencent beaucoup de confusions chez les agents.
Pour les systèmes qui récupèrent des connaissances externes, la même famille de risques apparaît dans la génération augmentée par récupération. Si votre serveur MCP alimente un agent en documents, les questions de conception recoupent celles de Décisions entre RAG et fine-tuning: où le texte non fiable entre-t-il, qui peut l’influencer et que peut faire le modèle après l’avoir lu ?
Établir une liste de contrôle pratique de durcissement
Les conseils de sécurité deviennent vite vagues, alors rendez-les opérationnels. Avant qu’un serveur MCP n’atteigne un véritable utilisateur ou un véritable jeu de données, vous devriez être en mesure d’expliquer ce que le serveur expose, quelles identités peuvent l’appeler, à quoi chaque outil peut accéder et comment vous détecterez les abus.
- Dressez l’inventaire de chaque outil. Consignez le nom de l’outil, sa description, ses paramètres, les systèmes en aval, les classes de données et les actions destructrices dans une documentation adaptée à 2026 que vos réviseurs pourront réellement lire.
- Utilisez des identifiants à privilège minimal. N’accordez à chaque serveur et à chaque outil à haut risque que les autorisations dont il a besoin, de préférence avec des jetons à portée limitée et des comptes de service distincts.
- Validez les entrées et les sorties. Appliquez des schémas stricts, rejetez les champs inattendus, limitez la longueur des chaînes et évitez de transmettre la sortie brute des outils dans le contexte de l’agent lorsqu’une valeur typée suffit.
- Exigez un consentement explicite pour les appels risqués. Affichez à l’utilisateur le serveur, l’outil, les arguments, la destination et les données partagées avant l’exécution, en particulier pour les e-mails, les paiements, la suppression, les modifications de code et les exportations.
- Séparez les outils privilégiés. Gardez les outils de recherche en lecture seule à l’écart des outils d’écriture, des outils d’administration et de l’accès aux secrets ; utilisez des serveurs distincts si cela rend la frontière plus claire.
- Autorisez uniquement les serveurs de confiance. Ne laissez pas les employés connecter des serveurs MCP publics arbitraires à des hôtes internes sans examen, verrouillage de version et approbation de la configuration.
- Journalisez les décisions, pas seulement les requêtes HTTP. Enregistrez la sélection de l’outil, l’approbation de l’utilisateur, l’identité du serveur, les arguments, les sorties et les effets en aval avec une durée de conservation adaptée à vos besoins de réponse aux incidents.
Un contre-argument mérite qu’on s’y attarde : trop de confirmations peuvent habituer les utilisateurs à cliquer sans réfléchir. C’est vrai. La réponse n’est pas de réduire les contrôles partout ; c’est d’appliquer une friction fondée sur le risque. Une consultation météo ne devrait pas ressembler à un virement bancaire, mais l’exportation de données client vers un serveur tiers devrait exiger une confirmation visible et distincte.
L’observabilité est importante parce que les défaillances de MCP peuvent donner l’impression que « le modèle a fait quelque chose d’étrange ». Instrumentez la chaîne. Si vous mettez en place de la télémétrie pour des systèmes d’agents, notre analyse de l’architecture d’observabilité de l’IA à l’échelle des données s’applique bien à la journalisation MCP, aux traces et à la corrélation d’événements.
Des choix de déploiement qui réduisent le rayon d’impact
Les serveurs STDIO locaux sont tentants parce qu’ils sont faciles à connecter aux outils de développement. La comparaison de la politique de sécurité officielle est utile : traitez les serveurs MCP locaux comme des logiciels installés. Épinglez les versions, examinez le code ou la provenance, et évitez de les exécuter avec l’ensemble complet des secrets de votre shell habituel à moins qu’ils n’en aient réellement besoin.
Les serveurs réseau ont besoin d’une protection du transport, d’une authentification, d’une autorisation et de limites de débit. Si un serveur est exposé au public, placez-le derrière les mêmes contrôles que ceux attendus pour une API interne : TLS, accès tenant compte de l’identité, surveillance, correctifs, analyse des dépendances et mécanismes de désactivation d’urgence. Ici, les contrôles les plus simples l’emportent.
La prépublication arXiv « MCP Pitfall Lab » de 2026 a indiqué que le durcissement recommandé a réduit les constats de niveau 1 de 29 à 0 et abaissé son score de risque de cadre de 10.0 à 0.0 pour un coût moyen de 27 lignes de code. Comme il s’agit d’une prépublication, ne considérez pas ces chiffres comme universels. Considérez-les comme un rappel utile que de nombreuses erreurs MCP sont mineures et corrigibles : validation manquante, vérifications d’origine faibles, autorisations trop larges et descriptions d’outils ambiguës.
Le commerce agentique augmente encore les enjeux. Un outil qui lit l’inventaire est une chose ; un outil qui dépense de l’argent en est une autre. Les questions de sécurité autour du consentement, des limites de transaction et de l’approbation humaine recoupent les risques évoqués dans paiements et achats en IA agentique, où une mauvaise action peut avoir des conséquences financières immédiates.
Gouvernance : décider qui peut connecter quoi
Quelqu’un dans votre organisation doit être responsable des connexions MCP. Sans cela, chaque équipe devient sa propre autorité d’intégration, et l’expérimentation la plus faible définit votre niveau d’exposition. C’est ainsi que des serveurs « temporaires » deviennent des voies d’attaque permanentes.
Un modèle de gouvernance clair comporte trois étapes de validation. D’abord, approuvez la source du serveur : fournisseur, dépôt, responsable de maintenance, licence et processus de mise à jour. Ensuite, approuvez les capacités : outils, portées, catégories de données et destinations sortantes. Enfin, approuvez l’environnement d’exécution : application hôte, transport, identifiants, journalisation et flux de consentement utilisateur.
Des rapports publics publiés en 2026 par LangSight et TrueFoundry ont affirmé que des centaines à des milliers de serveurs MCP étaient exposés sans authentification. Même si les totaux exacts évoluent à mesure que les analyses s’améliorent, la leçon pour la sécurité des serveurs mcp reste stable : refuser par défaut toute exposition externe, et rendre les exceptions d’une formalité ennuyeuse.
Vous voudrez également un coupe-circuit. Si un outil commence à divulguer des données ou si une dépendance reçoit une CVE comme mcp-remote l’a fait en 2025, vous devez désactiver le serveur, faire tourner les identifiants, révoquer les sessions et préserver les journaux sans attendre une réunion de l’équipe plateforme jeudi prochain.
FAQ
Qu’est-ce qu’un serveur MCP en termes simples ?
Un serveur MCP est un service qui expose des ressources, des invites ou des outils à une application d'IA via le Model Context Protocol. La partie risquée, ce sont les outils, car ce sont des fonctions que le modèle peut exécuter.
L’autorisation MCP est-elle requise par le protocole ?
Non. La spécification d’autorisation MCP 2025 définit une autorisation HTTP basée sur OAuth 2.1, mais l’autorisation est facultative dans le protocole. Les transports HTTP doivent suivre la spécification d’autorisation MCP, tandis que STDIO et les autres transports nécessitent une gestion des identifiants adaptée à leur environnement.
Qu’est-ce que l’empoisonnement des outils MCP ?
L’empoisonnement des outils MCP est une attaque d’injection indirecte de prompt dans laquelle une sortie d’outil malveillante influence un agent pour qu’il appelle des outils restreints, divulgue des données ou ignore les instructions système. Des schémas de sortie fixes, le principe du moindre privilège, des listes d’autorisation côté serveur et une confirmation hors bande réduisent le risque.
Dois-je faire confiance aux serveurs MCP publics ?
Seulement après examen. La politique de sécurité officielle de MCP indique que les clients font confiance aux serveurs auxquels ils se connectent, donc les serveurs publics doivent être traités comme des logiciels tiers ayant accès à votre agent, à vos données et parfois à des capacités locales.
Quelle est la victoire la plus rapide pour la sécurité du serveur mcp ?
Recensez chaque outil et supprimez les autorisations inutiles. Ajoutez ensuite une validation de schéma stricte et une confirmation explicite pour les actions sensibles ; ces contrôles réduisent à la fois les bogues logiciels ordinaires et les abus propres aux agents.
FR 
EN 
ES