Un serveur MCP expose des outils qu'un LLM peut appeler de façon autonome. La question de sécurité n'est donc pas "le LLM est-il fiable ?" mais "qu'est-ce qu'un attaquant peut faire s'il arrive à orienter les décisions du LLM ?" — car c'est exactement le scénario d'une injection de prompt réussie.
Le confused deputy, version MCP
Le problème classique : un serveur MCP a plus de droits que l'utilisateur final ne devrait en avoir (accès disque complet, clé API scope large), et le LLM devient le "député confus" qui utilise ces droits sur instruction d'un contenu malveillant plutôt que de l'utilisateur légitime. La défense de fond est la même que pour toute injection de prompt : traiter le contenu récupéré comme non fiable, jamais comme une instruction.
Contrôles concrets
| Risque | Contrôle |
|---|---|
| Outil trop permissif (accès disque large, shell) | Scoper chaque outil à un périmètre minimal, jamais un accès générique |
| Description d'outil trompeuse ("tool poisoning") | Auditer les descriptions à l'installation, ne pas faire confiance à un serveur tiers non vérifié |
| Mise à jour silencieuse d'un serveur ("rug pull") | Épingler une version, revalider avant toute mise à jour |
| Ressources exposées trop larges | Distinguer tools (actions) et resources (lecture) — voir MCP : tools vs resources |
| Exécution de code non sandboxée | Isoler l'exécution (conteneur, utilisateur système dédié, sans accès réseau superflu) |
Le cas du serveur minimal
Serveur MCP minimal en PHP montre l'implémentation du protocole sans se soucier de la sécurité — volontairement, pour rester lisible. En prod, chaque outil de ce serveur devrait passer par une couche d'autorisation explicite avant exécution, exactement comme un endpoint HTTP classique protégé par un firewall applicatif.
Le point souvent oublié : l'audit humain reste nécessaire
Aucun contrôle technique ne remplace une revue humaine avant de connecter un serveur MCP tiers à un agent qui a accès à des données sensibles. La confiance dans un serveur MCP externe devrait suivre les mêmes réflexes qu'une dépendance logicielle tierce : code source visible, mainteneur identifiable, changelog suivi.
FAQ
Un serveur MCP local (stdio) est-il plus sûr qu'un serveur distant ?
Le transport n'est pas le facteur principal de risque — le périmètre d'accès de l'outil l'est. Un serveur local avec un accès disque complet est plus dangereux qu'un serveur distant strictement scopé.
Faut-il sandboxer systématiquement l'exécution des outils MCP ?
Dès qu'un outil exécute du code arbitraire ou touche au système de fichiers au-delà d'un répertoire précis, oui — un conteneur ou un utilisateur système dédié limite la casse en cas de compromission.
Comment détecter le tool poisoning avant qu'il ne cause un dégât ?
En auditant les descriptions d'outils à l'installation (elles font partie du contexte envoyé au LLM) et en surveillant les changements de version d'un serveur tiers, pas seulement son comportement au runtime.
