Le Model Context Protocol (MCP), introduit par Anthropic en novembre 2024 puis ouvert et adopté largement en 2025-2026, est devenu en quelques mois le standard de fait pour exposer des outils à un LLM. Claude, Cursor, et la plupart des agents 2026 le supportent. Côté ergonomie, c'est une bonne nouvelle. Côté sécurité, c'est un nouveau vecteur à auditer — et la majorité des équipes le sous-estiment.
Un serveur MCP, c'est du code étranger qui parle à votre LLM, lui expose des fonctions, et reçoit ses appels. Il mérite le même niveau de scrutin qu'un connecteur OAuth ou une intégration tierce.
Ce qu'un serveur MCP fait, en clair
Un serveur MCP expose :
- Une liste de tools (fonctions appelables par l'agent).
- Une liste de resources (données que l'agent peut lire).
- Une liste de prompts (templates que l'agent peut utiliser).
Quand l'agent veut utiliser un outil, il fait un appel au serveur MCP, qui exécute le code et retourne le résultat. Le résultat est intégré au contexte de l'agent et utilisé pour la suite de la conversation.
C'est précisément cette intégration qui crée la surface d'attaque.
Les 6 risques à examiner pour chaque serveur MCP
1. Origine du code
- Est-ce un serveur officiel maintenu par l'éditeur du SaaS auquel il donne accès ? (Notion MCP par Notion, GitHub MCP par GitHub.)
- Ou un wrapper communautaire maintenu par un développeur tiers ?
Les wrappers communautaires sont la majorité aujourd'hui. Beaucoup sont excellents. Beaucoup ne le sont pas. Aucun n'a la garantie d'être maintenu.
2. Données envoyées
Quand l'agent appelle un outil MCP, toute la conversation pertinente peut être envoyée au serveur. Vérifications :
- Les paramètres passés à l'outil contiennent-ils des données sensibles (PII, secrets, contenu de prompts internes) ?
- Où vit le serveur MCP — localhost ? un service tiers ? un endpoint cloud ?
- Quelle est la rétention de logs côté serveur MCP ?
Le pire scénario : un wrapper MCP communautaire hébergé sur un VPS personnel d'un dev tiers, qui logge tous les appels en clair.
3. Sortie consommée comme contexte
C'est le point que j'ai détaillé dans Prompt injection indirecte via tool output. Tout output d'un serveur MCP devient du prompt côté agent. Un serveur MCP compromis peut donc faire de la prompt injection sur tous les agents qui l'utilisent.
4. Authentification
Comment l'agent prouve son identité au serveur MCP ?
- Token statique dans la config : si exfiltré, accès permanent.
- OAuth flow : meilleur, mais demande implémentation correcte côté serveur.
- Aucune auth (serveur local en mode dev) : OK en dev, à proscrire en prod.
5. Permissions des opérations
Le serveur MCP qui expose un outil delete_file ou send_email doit-il avoir un mécanisme de confirmation utilisateur côté agent ? Aujourd'hui c'est au client MCP de gérer. Claude Desktop, par exemple, a des prompts de confirmation. Beaucoup de wrappers MCP custom n'en ont pas.
6. Code source et dépendances
- Le serveur MCP est-il open source ? Vous pouvez l'auditer.
- Sinon, qu'est-ce qu'il dit faire vs ce qu'il fait réellement ?
- Sur ses propres dépendances, mêmes questions que pour n'importe quel package — cf. les attaques supply chain sur npm/PyPI (Shai-Hulud, PyTorch Lightning).
La checklist d'audit en 30 minutes par serveur
Avant de connecter un serveur MCP à un agent en prod :
`` [ ] Origine documentée (officiel ou wrapper, qui maintient) [ ] Localisation du serveur (local / SaaS / VPS) [ ] Données envoyées documentées [ ] Données retournées documentées [ ] Mécanisme d'authentification revu [ ] Liste des outils exposés ; pour chaque outil : - Action effectuée - Données accédées - Réversibilité - Confirmation requise ou non [ ] Audit du code source si dispo [ ] Audit des dépendances (npm/pypi) [ ] Plan de désactivation rapide (kill-switch côté agent) ``
Le cas particulier des serveurs MCP qui exécutent du code arbitraire
Plusieurs serveurs MCP populaires en 2026 exposent un outil execute_command ou équivalent. C'est techniquement très puissant, c'est aussi une porte ouverte. Si vous l'autorisez :
- Toujours dans un sandbox isolé.
- Sans accès à des credentials.
- Avec un logging exhaustif.
- Idéalement avec confirmation humaine sur chaque commande.
Dans la majorité des contextes B2B, le bon défaut est de ne pas activer ces serveurs. L'utilité est marginale par rapport au risque.
Le sujet émergent : la gouvernance MCP en entreprise
Les premières équipes 2026 qui industrialisent l'usage des MCP mettent en place :
- Un registre interne de serveurs MCP validés.
- Un proxy MCP par lequel passent tous les appels (logging, validation, rate limit centralisé).
- Une politique sur ce qu'un employé peut ou ne peut pas connecter en autonomie.
C'est le même schéma que les premiers SaaS approvals en entreprise vers 2010-2015. Anticipez-le si vous voulez éviter le shadow MCP — analogue du shadow AI sur un nouveau vecteur.
Pour la lecture des entrées non fiables qui transitent par un agent, Prompt injection indirecte via tool output. Pour l'intégration Claude enterprise, Claude en entreprise : sécuriser l'API et les agents.