La nouvelle spec MCP déplace la sécurité vers les développeurs. Checklist concrète pour sécuriser votre serveur MCP sans bloquer vos agents IA.
La nouvelle spécification du Model Context Protocol, publiée fin juin 2026, déplace une partie critique de la responsabilité sécurité du protocole vers les développeurs qui l'implémentent. Concrètement : si votre serveur MCP expose un outil sensible sans validation stricte des tokens OAuth, la faille vient de votre code, pas du protocole conçu par Anthropic.
C'est un changement de philosophie, pas un simple patch. Jusqu'ici, MCP restait relativement permissif sur la façon dont les serveurs géraient l'authentification. La nouvelle version enterprise-ready, documentée par SecurityWeek fin juin, referme cette latitude et pousse les équipes à durcir elles-mêmes leurs implémentations. On en avait déjà parlé dans Commerce agentique sur Shopify : MCP devient l'interface standard entre agents IA et systèmes métier. Reste que brancher un agent sur votre CRM ou votre base de commandes sans blindage, c'est ouvrir une porte que personne ne surveille.
Ce qui a changé dans la spec MCP de juin 2026
Le protocole MCP fonctionne comme une interface unifiée : un agent IA, Claude, Cursor, ou n'importe quel client compatible, s'y connecte pour appeler des outils externes sans code spécifique par intégration. X (l'ancien Twitter) a lancé son propre serveur MCP fin juin pour permettre à des agents comme Claude ou Grok Build d'accéder directement à sa plateforme, selon TechCrunch. HiBob a fait pareil quelques jours plus tôt avec une intégration MCP connectant Slack à son SIRH.
Cette adoption rapide a un revers. Plus il y a de serveurs MCP exposés publiquement, plus la surface d'attaque grossit. La nouvelle spec répond à ça en formalisant des exigences plus strictes sur la gestion des tokens et des scopes OAuth. Mais elle ne les impose pas techniquement, elle documente ce qu'un serveur "enterprise-ready" doit faire. Libre à chaque développeur de suivre ou d'ignorer.
C'est là le point contre-intuitif : une spec plus sécurisée sur le papier peut rendre l'écosystème moins sûr à court terme, parce qu'elle donne l'illusion que le protocole gère déjà le problème. Il ne le gère pas. Il documente le problème et vous refile la patate chaude.
Les failles qu'on voit déjà sur les déploiements MCP
Tool poisoning : quand un serveur ment sur ce qu'il fait
Un serveur MCP déclare ses outils via un manifeste en langage naturel, une description que l'agent lit pour décider quand l'appeler. Rien n'empêche un serveur malveillant, ou compromis, de déclarer un outil "lecture seule" qui en réalité écrit dans votre base. L'agent fait confiance à la description, pas au code réel. C'est le vecteur le plus documenté dans la communauté sécurité MCP depuis le début 2026.
OAuth mal configuré, le vecteur numéro un
La plupart des incidents viennent d'une confusion classique : scopes trop larges, tokens qui ne expirent jamais, ou pire, tokens partagés entre plusieurs agents sur le même serveur. Un token MCP compromis donne accès à tout ce que le scope autorise, pas seulement à la requête en cours.
Absence de sandboxing entre l'agent et le système de fichiers
Beaucoup de serveurs MCP tournent encore en local, avec un accès disque quasi total pour simplifier le dev. Ça marche très bien jusqu'au jour où l'agent reçoit un prompt malveillant injecté via un document externe, et exécute une commande shell qu'il n'aurait jamais dû avoir le droit de lancer.
Comment sécuriser un serveur MCP en production
Voici ce qu'on recommande concrètement, par ordre de priorité :
- Scopes OAuth granulaires, un scope par outil, jamais un scope global "admin".
- Expiration courte des tokens, 15 à 60 minutes, avec refresh explicite plutôt que des tokens qui vivent des semaines.
- Validation du manifeste d'outils à chaque appel, pas seulement au moment du handshake initial.
- Sandboxing systématique, conteneur isolé, système de fichiers en lecture seule sauf répertoire dédié.
- Logs d'audit par appel d'outil, avec alerting sur les patterns anormaux (fréquence, horaires, scopes inhabituels).
- Rate limiting côté serveur MCP, indépendant du rate limiting de l'API sous-jacente.
Cette liste n'a rien de révolutionnaire. C'est essentiellement de l'hygiène API classique, appliquée à un protocole plus jeune que la plupart des standards REST. La différence, c'est que personne n'a encore les réflexes automatiques, parce que MCP a un peu plus d'un an d'existence publique.
Une limite honnête à mentionner : ces mesures ralentissent le développement. Un scope par outil, ça veut dire plus de configuration à chaque nouvel outil ajouté. Si votre équipe déploie vite et itère sur un MVP interne non exposé publiquement, ce niveau de rigueur peut être disproportionné. Réservez-le aux serveurs exposés à des tiers ou manipulant des données sensibles.
MCP vs API REST classique : la sécurité en comparaison
| Critère | API REST classique | Serveur MCP |
|---|---|---|
| Authentification | OAuth 2.0 / API keys, standard mature | OAuth intégré à la spec, mais implémentation variable |
| Découverte des capacités | Documentation statique (OpenAPI) | Manifeste dynamique lu par l'agent à l'exécution |
| Surface d'attaque | Endpoints connus, fixes | Outils déclarés dynamiquement, donc plus difficile à auditer |
| Contrôle d'accès | Rôles et permissions bien établis | Scopes encore peu granulaires dans la pratique |
| Maturité écosystème | 15+ ans de patterns éprouvés | Moins de deux ans, best practices encore mouvantes |
Le tableau parle de lui-même : MCP n'est pas moins sécurisable qu'une API REST, mais l'écosystème d'outils, de scanners et de bonnes pratiques n'a pas encore rattrapé son retard. Ça viendra. En attendant, c'est à vous de compenser.
Ce que font déjà les gros acteurs
Anthropic a fait évoluer son modèle Claude vers Sonnet 5 fin juin 2026, en remplacement de Sonnet 4.6 sorti en février, selon 9to5Mac. Un modèle plus capable pose mécaniquement plus de risques côté agentique : plus l'agent est autonome dans ses décisions, plus une faille MCP en amont a de conséquences en aval. X a choisi d'exposer un serveur MCP public pour laisser des agents comme Claude ou Cursor interagir directement avec sa plateforme, un choix qui suppose une gouvernance des tokens particulièrement stricte vu l'échelle. HiBob, de son côté, a opté pour une intégration plus fermée, connectant son SIRH à Slack via MCP plutôt que d'exposer un serveur ouvert à n'importe quel client.
Deux philosophies, deux niveaux de risque. Si votre boutique Shopify ou votre SaaS interne envisage d'exposer un serveur MCP, la question à se poser d'abord : est-ce que vous avez vraiment besoin d'un accès ouvert, ou un accès fermé à vos propres agents suffit ?
Conclusion
Trois points à retenir. D'abord, la nouvelle spec MCP ne sécurise pas automatiquement vos déploiements, elle documente des exigences que vous devez implémenter vous-même. Ensuite, les failles les plus fréquentes restent des classiques : scopes trop larges, tokens qui ne expirent pas, sandboxing absent. Enfin, la rigueur a un coût en vélocité, à réserver aux serveurs réellement exposés.
Si vous exposez déjà un agent IA connecté à votre stack via MCP, ou si vous hésitez encore entre une solution no-code et une implémentation custom, on en avait détaillé les arbitrages dans No-code vs code pour construire un agent IA. Besoin d'un audit sécurité sur votre serveur MCP avant mise en prod ? Contactez-nous sur fstck.co.
Questions fréquentes
Comment savoir si mon serveur MCP est vulnérable au tool poisoning ?
Vérifiez que le manifeste déclaré par chaque outil correspond exactement à son comportement réel en production, pas seulement à la documentation. Un audit simple : loggez chaque appel d'outil et comparez l'action réelle (écriture, lecture, appel externe) à la description annoncée dans le manifeste.
Faut-il attendre que MCP mature avant de le déployer en production ?
Non, mais il faut adapter le niveau de rigueur à l'exposition réelle du serveur. Un serveur MCP interne, accessible uniquement par vos propres agents sur un réseau privé, tolère moins de contraintes qu'un serveur exposé publiquement à des clients tiers.
Quelle différence entre les scopes OAuth d'une API REST et ceux d'un serveur MCP ?
Le principe est identique, limiter l'accès à ce qui est strictement nécessaire, mais la spec MCP encourage un scope par outil plutôt qu'un scope par ressource. En pratique, beaucoup d'implémentations actuelles restent trop permissives faute d'outils de tooling matures pour gérer cette granularité facilement.
Un token MCP compromis donne-t-il accès à tous les outils du serveur ?
Ça dépend entièrement de la configuration des scopes. Si le token a un scope global, oui, l'attaquant récupère tout ce que ce scope autorise. C'est pour ça que la granularité des scopes n'est pas un détail optionnel, mais la première ligne de défense.
MCP est-il plus risqué qu'une intégration API classique ?
Pas intrinsèquement plus risqué, mais moins mature en termes d'outils d'audit et de bonnes pratiques standardisées. La découverte dynamique des capacités, qui fait la force de MCP, complique aussi l'analyse statique de sécurité qu'on fait facilement sur une API REST documentée en OpenAPI.
