Sécurité MCP : sécuriser le Model Context Protocol

Le Model Context Protocol connecte les applications d'IA aux outils, sources de données et API via une interface unifiée ; les serveurs MCP y jouent le rôle de passerelle, souvent avec des droits utilisateur délégués. L'intégration dynamique d'outils à l'exécution, les relations de confiance implicites entre composants et les contextes partagés créent des chemins d'attaque que la sécurité API classique ne couvre pas. De plus, le protocole ne définit ni contrôle d'accès obligatoire ni gestion du cycle de vie des Tokens – la mise en œuvre sécurisée incombe entièrement aux implémenteurs.

Parmi les risques centraux figurent le Tool Poisoning (instructions cachées dans les descriptions d'outils), les Rug Pulls (remplacement a posteriori de définitions d'outils déjà approuvées) et l'injection de code via des entrées de modèle transmises sans vérification. Le Token Passthrough crée un risque de type Confused Deputy : le serveur MCP est détourné pour exécuter des actions non autorisées avec les droits d'autres utilisateurs ; des clés API et des Tokens OAuth stockés de manière non sécurisée permettent le vol d'identifiants. Des incidents réels – de l'exfiltration de dépôts GitHub privés à la fuite de messages WhatsApp, en passant par la vulnérabilité RCE CVE-2025-49596 dans le MCP Inspector – démontrent que ces attaques fonctionnent en pratique.

Le guide OWASP exige OAuth 2.1/OIDC pour tous les serveurs MCP distants, des Tokens à courte durée de vie et à périmètre restreint, ainsi que la validation par schéma de l'ensemble des entrées et sorties. Les utilisateurs et les sessions doivent être strictement isolés, et l'exécution des outils doit se faire dans des Sandboxes durcies (conteneurs, seccomp/AppArmor) avec des droits minimaux et un réseau segmenté. Les secrets résident dans des Vaults et ne doivent à aucun moment être accessibles au LLM.

Wiz Research recommande de n'utiliser que des serveurs MCP provenant de sources de confiance et de les auditer avant usage comme des paquets logiciels privilégiés – l'installation et l'exécution automatiques d'outils sont des schémas à haut risque. Un client MCP mature, doté de dialogues d'approbation, d'une gestion des permissions et d'un contrôle Human-in-the-Loop pour les actions critiques, limite les dommages causés par des serveurs compromis. Un MCP-Gateway central et l'Allowlisting côté hôte regroupent la journalisation d'audit, les garde-fous et l'application des politiques en un point de contrôle unique.

Tous les appels d'outils et de modèles devraient être journalisés – paramètres et identités impliquées compris – et intégrés aux pipelines SIEM et de détection existants. La NSA recommande en outre de scanner régulièrement son propre réseau à la recherche de serveurs MCP non authentifiés, vulnérables ou non approuvés – les serveurs MCP pouvant changer de port dynamiquement, des scans périodiques avec rapports différentiels sont pertinents. En complément, un processus formel de veille sur les vulnérabilités liées à MCP (CVE, avis des éditeurs) doit faire partie de l'exploitation courante.

Aucun outil ni aucune modification d'outil ne devrait passer en production sans processus formel d'approbation : analyse de code (SAST), analyse des dépendances (SCA) et revue de sécurité manuelle sont obligatoires. Des manifestes d'outils signés avec épinglage de version garantissent l'intégrité ; la fonctionnalité annoncée dans la description d'un outil doit être validée par rapport à son comportement réel à l'exécution. Un inventaire tenu à jour de tous les serveurs et outils MCP utilisés, avec versions et historique des correctifs, accélère le triage et la réaction lorsque de nouvelles vulnérabilités sont publiées.