Points à retenir
Le 28 juillet 2026, le Model Context Protocol (MCP) passera officiellement à une architecture sans état de niveau entreprise.
En adoptant un modèle sans état et en introduisant des applications dotées d'une interface utilisateur riche ainsi que des tâches asynchrones, le protocole confie désormais entièrement aux développeurs la responsabilité de mettre en place des barrières de sécurité essentielles.
Cette mise à jour élimine avec succès les principaux risques de sécurité historiques, notamment le détournement de session au niveau du protocole, les invites de serveur non sollicitées et les méthodes d'authentification faibles.
L'introduction d'un état géré par l'application, d'interfaces IA interactives riches et de tâches asynchrones de longue durée ouvre toutefois de nouvelles voies d'abus.
Si elles ne sont pas correctement sécurisées, ces nouvelles fonctionnalités pourraient permettre un accès non autorisé aux données des clients, des attaques d'hameçonnage ciblant les utilisateurs via des expériences IA de confiance, le contournement des contrôles de sécurité d'entreprise et la perturbation des services par l'utilisation abusive des flux de traitement en arrière-plan.
La future spécification MCP 2026-07-28 représente l'évolution architecturale la plus importante du Model Context Protocol (MCP) depuis sa création. Ce qui était à l'origine un outil d'intégration d'IA local destiné à un seul utilisateur se transforme en une plateforme capable de prendre en charge des déploiements cloud natifs à l'échelle de l'entreprise.
À la suite de la version candidate publiée le 21 mai 2026, la publication de la spécification finale est prévue pour le 28 juillet 2026, accompagnée d'une période officielle de 12 mois de dépréciation pour certaines fonctionnalités héritées.
Évolution de la surface d'attaque
Pour mettre en place cette base adaptée aux entreprises, cette mise à jour remanie entièrement la manière dont le protocole gère les données et l'exécution. Elle introduit une architecture sans état s'appuyant sur des requêtes à allers-retours multiples, de nouveaux en-têtes HTTP normalisés et un objet _meta universel pour la messagerie contextuelle. De plus, la spécification formalise les applications MCP et les tâches asynchrones, tout en accordant une place de premier plan à l'intégration OAuth.
Si une grande partie des débats autour de ces fonctionnalités porte sur l'évolutivité et l'interopérabilité, leur impact structurel sur la surface d'attaque du protocole est tout aussi profond. À mesure que le modèle de sécurité évolue, certains risques de longue date au niveau du protocole sont atténués, voire totalement éliminés, tandis que de nouvelles responsabilités incombent désormais pleinement aux développeurs d'applications MCP (figure 1). En fin de compte, bien que ces changements améliorent les fondements, ce sont désormais les choix de mise en œuvre qui déterminent la posture de sécurité globale.
Fig. 1 : évolution de la surface d'attaque du MCP dans la nouvelle spécification
Surfaces d'attaque réduites ou éliminées
Les versions précédentes de MCP présentaient plusieurs risques de sécurité liés aux sessions gérées par le protocole, aux communications initiées par le serveur et à des exigences d'authentification encore peu abouties. La nouvelle spécification remanie ou supprime plusieurs de ces mécanismes, réduisant ainsi la surface d'attaque au niveau du protocole. Ces mécanismes comprennent :
Le détournement de session au niveau du protocole
Les invites non sollicitées du serveur
Les méthodes d'authentification peu sûres
Le détournement de session au niveau du protocole
Les versions précédentes de MCP s'appuyaient sur un processus d'initialisation avec état qui établissait une session de longue durée à l'aide de l'en-tête Mcp-Session-Id. Ces identifiants de session constituent généralement des cibles de choix, car les attaquants qui parviennent à s'en emparer peuvent usurper l'identité d'utilisateurs authentifiés.
La nouvelle spécification supprime complètement ces sessions gérées par le protocole, éliminant ainsi ce vecteur d'attaque spécifique. Toutefois, les développeurs doivent désormais mettre en place leurs propres mécanismes sécurisés de gestion de l'état (que nous examinerons plus loin dans cet article).
Les invites non sollicitées du serveur
Les versions antérieures de MCP permettaient aux serveurs d'envoyer des requêtes ou des invites inattendues aux clients à tout moment via les « Server-Sent Events ».
Les nouvelles règles limitent strictement ce comportement, empêchant ainsi les serveurs compromis d'interrompre discrètement les utilisateurs par des interactions malveillantes et non sollicitées.
Les méthodes d'authentification peu sûres
Cette mise à jour impose le respect des exigences strictes de la norme OAuth 2.1, ce qui réduit considérablement les risques liés à l'authentification. En supprimant les mots de passe traditionnels et les autorisations implicites, et en rendant obligatoires des mesures de protection telles que le « Proof Key for Code Exchange » (PKCE), le protocole limite fortement les possibilités de fuite ou d'exploitation des identifiants et des jetons
Dans l'ensemble, ces changements réduisent considérablement la surface d'attaque liée à l'authentification et le rayon d'impact des attaques par « session blast » qui existaient dans les déploiements MCP précédents.
Nouvelles surfaces d'attaque introduites par la spécification
Bien que le protocole élimine plusieurs catégories de vulnérabilités, il introduit également de nouveaux domaines dans lesquels la sécurité dépend fortement de la qualité de la mise en œuvre, notamment :
Le détournement de flux de travail entre agents
La manipulation des métadonnées contrôlée par le client
La confusion des en-têtes et l'exposition des données via les en-têtes
Les applications MCP et le cross-site scripting stocké
Les risques d'exploitation dans les tâches d'arrière-plan s'exécutant sur une longue durée
Le détournement de flux de travail entre agents
La tendance à l'absence d'état soulève des défis subtils en matière de sécurité. Dans les environnements d'entreprise, les interactions avec l'IA ne se résument pas toujours à une simple conversation en une seule requête. Elles nécessitent souvent une chaîne d'événements séquentielle. Par exemple :
Demande de précisions : un outil peut s'interrompre en cours de tâche pour demander à l'utilisateur des informations manquantes
Vérification de l'avancement : une tâche longue peut nécessiter que le système demande régulièrement des mises à jour
Suspension des flux de travail : un processus complexe peut être suspendu pendant une heure dans l'attente d'une validation humaine, puis reprendre son exécution exactement là où il s'était arrêté
Le nouveau MCP étant sans état, il n'utilise pas de sessions permanentes pour mémoriser l'identité des différents acteurs. À la place, il introduit des identifiants de suivi et des objets d'état que le serveur transmet au client. Le client les renvoie ensuite dès qu'il est prêt à reprendre le flux d'exécution, ce qui lui confère pratiquement un contrôle total sur l'état de la tâche.
Le problème de sécurité est simple : comme ces identifiants de suivi et ces objets d'état proviennent directement du client, le serveur ne peut pas s'y fier aveuglément. La figure 2 montre que si un serveur MCP utilise des identifiants de suivi prévisibles ou ne vérifie pas rigoureusement l'intégrité de l'objet d'état reçu, un attaquant pourrait deviner ou modifier ces valeurs afin de :
Détourner le flux de travail actif d'un autre utilisateur
Accéder à des informations appartenant à un autre agent
Déclencher des actions non autorisées entre locataires
Fig. 2 : illustration de la devinette des identifiants de suivi et de la falsification d'état
Bien que la spécification officielle du MCP recommande expressément aux développeurs de vérifier l'intégrité de ces objets, elle ne définit pas de norme ni de mise en œuvre spécifique, laissant ainsi entièrement aux développeurs de serveurs le soin de mettre en place cette couche de sécurité.
La manipulation des métadonnées contrôlée par le client
La nouvelle spécification introduit un objet _meta qui permet aux clients d'associer des métadonnées personnalisées à pratiquement n'importe quel message MCP. Même dans le cadre d'une simple requête unique, un attaquant pourrait fournir des paires clé-valeur malveillantes, telles que {« tenant » : “admin”, « authenticated » : true}.
Ces champs n'étant pas signés cryptographiquement, si un serveur se fie sans discernement à ces métadonnées pour prendre des décisions de routage ou d'autorisation, une seule requête malveillante peut instantanément entraîner une élévation de privilèges ou un accès aux données d'autres locataires.
La confusion des en-têtes et l'exposition des données via les en-têtes
La spécification introduit des en-têtes HTTP spécifiques au MCP, tels que Mcp-Method et Mcp-Name, qui aident les intermédiaires, les proxys, les passerelles et les serveurs à interpréter de manière cohérente les requêtes MCP et à les acheminer correctement.
Cependant, ces en-têtes introduisent également deux nouveaux risques de sécurité :
Attaques par confusion de protocole (désynchronisation) : les attaquants peuvent envoyer des valeurs contradictoires entre les en-têtes HTTP et le corps de la requête JSON-RPC, en exploitant une divergence entre deux protocoles de communication différents — HTTP et JSON-RPC — afin de désynchroniser l'infrastructure back-end. Cette incohérence peut induire en erreur les proxys et les serveurs back-end, les amenant à interpréter une même requête de manière différente, ce qui permet aux attaquants de contourner les contrôles de sécurité, d'échapper à la surveillance ou de masquer des actions malveillantes.
Fuite de données via l'en-tête x-mcp-header : cette nouvelle directive permet aux développeurs de mapper directement des arguments d'outils spécifiques dans les en-têtes HTTP. Cela aide les proxys à acheminer le trafic plus rapidement sans avoir à analyser l'intégralité du corps de la requête. Cependant, si les développeurs mappent accidentellement des données sensibles telles que des clés API, des jetons ou des informations personnelles identifiables (PII), ces informations confidentielles sont directement transmises dans les en-têtes. Une fois sur place, ils deviennent visibles pour tous les équilibreurs de charge, proxys et systèmes de journalisation situés le long du chemin.
Les applications MCP et le cross-site scripting stocké
L'une des évolutions les plus prometteuses du MCP consiste à faire des MCP Apps une extension de protocole à part entière. Les MCP Apps sont les panneaux visuels interactifs que vous voyez au sein d'applications d'IA telles que Claude Desktop (par exemple, des formulaires et tableaux de bord interactifs, des visionneuses de documents, des écrans de suivi des flux de travail et des tâches).
Si ces interfaces riches améliorent considérablement l'expérience utilisateur, elles introduisent également dans l'écosystème de l'IA les risques traditionnels liés aux navigateurs Web, tels que les attaques de type « cross-site scripting » (XSS) stockées. Par exemple, un attaquant peut stocker du code HTML ou JavaScript malveillant via un outil MCP. Lorsqu'un autre utilisateur (ou un agent IA) consulte ce contenu, le script malveillant s'exécute automatiquement au sein de l'interface de l'application.
Bien que la spécification MCP exige que les agents exécutent ces scripts au sein d'un environnement isolé <iframe> afin d'empêcher des acteurs malveillants de prendre complètement le contrôle de l'agent IA, les utilisateurs restent exposés à des risques. Un attaquant peut toujours utiliser le panneau compromis pour afficher du contenu trompeur, mener des campagnes d'hameçonnage visant à obtenir des informations sensibles à l'aide de fausses invites, voler toutes les données utilisateur actuellement visibles au sein de ce panneau spécifique, et renvoyer ces informations volées vers ses propres serveurs (figure 3).
Fig. 3 : illustration de l'exploitation des applications MCP via une vulnérabilité XSS stockée
Risques d'exploitation liés aux tâches d'arrière-plan de longue durée
La mise en place de tâches de longue durée crée un vecteur d'attaque par déni de service (DoS) de grande ampleur qui repose sur des interactions unidirectionnelles. La création d'une tâche étant peu coûteuse pour le client, mais très gourmande en ressources pour le serveur, un attaquant peut envoyer une seule requête pour déclencher une opération coûteuse (en termes de CPU, de mémoire ou d'espace de stockage dans la base de données) puis se déconnecter immédiatement.
Cette méthode d'exploitation asynchrone unidirectionnelle oblige le serveur à traiter des charges de travail importantes même après le départ du client, ce qui épuise facilement les ressources du serveur.
Conclusion
La spécification MCP du 28 juillet 2026 marque la transition du protocole d'une utilisation locale vers un déploiement à l'échelle de l'entreprise. Du point de vue de la sécurité, ces changements ne constituent pas de simples améliorations progressives. Ils redéfinissent fondamentalement la répartition des responsabilités en matière de sécurité : les décisions de sécurité qui étaient auparavant imposées par le protocole sont de plus en plus déléguées aux développeurs de serveurs MCP et aux opérateurs de plateformes.
À mesure que l'adoption du MCP s'accélère dans les environnements cloud, la question de sécurité la plus importante n'est plus de savoir si le protocole lui-même est sécurisé. Les équipes de sécurité doivent désormais déterminer si les applications construites sur ce protocole mettent correctement en œuvre les nouvelles limites de confiance, les mécanismes de gestion d'état et les modèles d'exécution introduits par la spécification.
Pour sécuriser correctement ces nouvelles surfaces d'attaque, les équipes de sécurité doivent traiter toutes les données d'état et métadonnées fournies par les clients comme des entrées non fiables, en appliquant une vérification cryptographique stricte, un encodage des sorties pour les panneaux visuels générés par l'IA, ainsi que des quotas de ressources rigoureux pour les tâches asynchrones.
Pour faire face à cette évolution, il est nécessaire de mettre en place une architecture de défense proactive capable de bloquer les exploits avant même qu'ils n'atteignent votre infrastructure back-end.
Agissez maintenant
Akamai permet aux entreprises d'agir. En nous appuyant sur notre plateforme existante de sécurité de la bordure de l'Internet, des API et des applications, et en l'enrichissant d'une intelligence adaptée au MCP, nous aidons les équipes à identifier les cas où le MCP fait son apparition, à mettre en place des mesures de protection concrètes pendant la phase d'expérimentation et à gérer les risques à mesure que l'exposition augmente.
Cette approche permet aux entreprises d'adopter le MCP dès aujourd'hui tout en s'appuyant sur Akamai pour faire évoluer la protection, la visibilité et le contrôle à mesure que l'utilisation du MCP se développe.
Mots-clés
