La refonte MCP entreprise déplace la sécurité du protocole vers vos développeurs

De quoi s’agit-il ?

Le Model Context Protocol connaît sa plus grande évolution structurelle depuis sa publication par Anthropic fin 2024. La spécification MCP 2026-07-28 — candidate à la publication le 21 mai 2026, version finale prévue le 28 juillet 2026, avec une fenêtre de dépréciation de douze mois pour les fonctions héritées — fait passer MCP d’un outil d’intégration local et mono-utilisateur vers un protocole sans état, pensé pour un déploiement cloud à l’échelle de l’entreprise.

Le 25 juin 2026, l’équipe de recherche menaces d’Akamai (Maxim Zavodchik, Segev Fogel et Gal Meiri) a publié une modélisation de menaces de la nouvelle spécification. Leur conclusion justifie ce billet : la refonte ferme réellement plusieurs classes de vulnérabilités au niveau du protocole, mais elle le fait en déplaçant les décisions de sécurité correspondantes vers les développeurs et les opérateurs de plateforme qui implémentent les serveurs MCP. Le protocole devient plus sûr ; la sûreté d’un déploiement donné dépend désormais entièrement de la qualité de l’implémentation.

Comment ça marche

Trois anciennes classes de risque sont réduites ou supprimées. Les sessions gérées par le protocole — le Mcp-Session-Id à longue durée de vie qu’un attaquant pouvait voler pour usurper un utilisateur — disparaissent au profit d’un modèle sans état. Les serveurs ne peuvent plus envoyer de prompts non sollicités aux clients à tout moment, ce qui ferme un canal exploitable par un serveur compromis. Et l’authentification passe à OAuth 2.1 obligatoire, en abandonnant les grants par mot de passe et implicites hérités et en exigeant des protections comme PKCE.

En contrepartie, un nouvel ensemble de surfaces apparaît, où la sûreté dépend de la façon dont chaque serveur est écrit, et non du protocole :

Supprimé / réduit par le protocole        Désormais à la charge du développeur
---------------------------------------  -------------------------------------------
Détournement de session (protocole)      Intégrité de l'objet d'état (workflow)
Prompts serveur non sollicités           Confiance dans les métadonnées _meta client
Authentification faible / héritée        Cohérence en-tête / corps (désync)
                                         Ne pas mapper de secrets dans les en-têtes
                                         Encoder l'UI des MCP Apps (XSS stocké)
                                         Quotas sur les tâches asynchrones longues

Le protocole étant sans état, le serveur remet au client un identifiant de suivi et un objet d’état, et fait confiance au client pour les renvoyer afin de reprendre un workflow en pause. Si un serveur utilise des identifiants prévisibles ou ne vérifie pas l’intégrité de l’état renvoyé, un attaquant peut deviner ou falsifier ces valeurs pour détourner le workflow actif d’un autre utilisateur ou déclencher des actions inter-locataires. La spécification demande de vérifier ces objets mais ne normalise pas la méthode.

Un nouvel objet _meta permet au client d’attacher des paires clé-valeur arbitraires à presque tout message, sans signature cryptographique. Un serveur qui fait confiance à un {"tenant": "admin"} pour le routage ou l’autorisation peut être conduit à une élévation de privilèges en une seule requête. De même, les nouveaux en-têtes HTTP MCP (Mcp-Method, Mcp-Name) invitent aux attaques de désync quand l’en-tête et le corps JSON-RPC divergent, et une directive x-mcp-header qui mappe des arguments d’outil dans des en-têtes fera fuiter des secrets vers chaque proxy et journal du chemin si un développeur mappe le mauvais champ. Enfin, les MCP Apps — les panneaux d’interface interactifs désormais promus au rang d’extension de première classe — importent le cross-site scripting stocké classique dans la surface de l’agent (isolé dans une <iframe>, mais suffisant pour hameçonner ou exfiltrer ce que le panneau voit), et les tâches longues peu coûteuses à lancer créent un vecteur de déni de service de type « frappe et fuite ».

Pourquoi c’est important

MCP est déjà le tissu conjonctif de fait entre les agents et les outils d’entreprise, et son adoption s’accélère précisément vers les déploiements multi-locataires et hébergés dans le cloud que vise cette spécification. La question de sécurité passe de « le protocole est-il sûr ? » à « ce serveur a-t-il implémenté correctement les nouvelles frontières de confiance ? » — et la réponse variera d’un serveur à l’autre. La fenêtre de migration (support hérité pendant douze mois) implique aussi des parcs mixtes exécutant simultanément anciennes et nouvelles sémantiques, terrain idéal pour les bugs de désync et de gestion d’état. Si votre organisation publie ou consomme des serveurs MCP, la bascule du 28 juillet est un événement planifié que vous pouvez préparer.

Défenses

Les recommandations d’Akamai, généralisées à toute équipe adoptant la nouvelle spécification :

1. Traitez tout état et toute métadonnée fournis par le client comme non fiables. Signez et vérifiez l’intégrité des objets d’état ; ne prenez jamais de décision d’autorisation ou de routage à partir de champs _meta non signés. Utilisez des identifiants de suivi imprévisibles et à forte entropie, liés côté serveur au principal authentifié.
2. Réconciliez en-têtes et corps. Assurez-vous que proxys, passerelles et serveur s’accordent sur Mcp-Method / Mcp-Name face au corps JSON-RPC ; rejetez les requêtes contradictoires pour fermer les brèches de désync.
3. Auditez les mappings x-mcp-header. Ne mappez jamais de clés d’API, de jetons ou de PII dans des en-têtes HTTP. Contrôlez ces mappings avant déploiement et en revue de code, car la fuite est silencieuse.
4. Encodez la sortie des MCP Apps. Appliquez un encodage de sortie strict et une CSP restrictive à tout HTML fourni par un utilisateur ou un outil rendu dans les panneaux ; conservez le bac à sable, mais ne comptez pas dessus seul.
5. Imposez des quotas aux tâches asynchrones. Limitez le débit et plafonnez les ressources de création de tâches, et liez le travail long à une session authentifiée et responsable pour qu’un seul client qui se déconnecte ne puisse pas épuiser le serveur.
6. Planifiez la migration. Inventoriez serveurs et clients MCP, suivez ceux qui parlent la nouvelle sémantique sans état, et évitez les déploiements en mode mixte durables où l’ancien et le nouveau comportement peuvent être opposés.

Statut

Élément	Référence	Date	Notes
Candidate MCP 2026-07-28	modelcontextprotocol.io	2026-05-21	Architecture sans état, MCP Apps, tâches async, OAuth 2.1
Modélisation Akamai	Akamai SIG	2026-06-25	Analyse du déplacement de surface d’attaque
Spécification finale	modelcontextprotocol.io	2026-07-28 (prévu)	Fenêtre de dépréciation héritée de 12 mois

Le titre n’est pas « la nouvelle spécification MCP est non sûre » — elle supprime de vrais risques au niveau du protocole. C’est que la responsabilité de la sécurité s’est déplacée vers ceux qui construisent les serveurs MCP, à compter de la bascule du 28 juillet. Les équipes qui traitent la migration comme un projet de sécurité d’implémentation, et non comme une simple mise à jour, sont celles qui éviteront d’hériter des nouvelles surfaces.