Une refonte majeure du Model Context Protocol prévue le mois prochain supprime plusieurs risques de sécurité de longue date au niveau du protocole, mais offre aux développeurs un nouvel ensemble de surfaces d'attaque à défendre, selon une étude publiée aujourd'hui par Akamai Technologies Inc.
L'analyse examine la spécification MCP 2026-07-28, le plus grand changement architectural apporté à la norme depuis sa création par Anthropic PBC pour connecter les agents d'intelligence artificielle à des outils et des données externes. La version finale est prévue pour le 28 juillet, suite à une version candidate publiée en mai et comporte une fenêtre de dépréciation de 12 mois pour certaines fonctionnalités héritées. Les chercheurs d'Akamai appellent cela la transition du protocole d'un outil local pour utilisateur unique à une plate-forme conçue pour un déploiement cloud natif à l'échelle de l'entreprise.
La reconstruction met fin à une classe de risques qui définissaient les versions antérieures. Les versions précédentes reposaient sur un processus d'initialisation avec état qui établissait des sessions de longue durée via l'en-tête Mcp-Session-Id, une cible de grande valeur car un attaquant qui en volait une pourrait usurper l'identité d'un utilisateur authentifié.
La nouvelle spécification supprime entièrement les sessions gérées par protocole, éliminant ainsi ce vecteur. Il limite également strictement les invites lancées par le serveur autorisées par les versions précédentes, qui permettaient à un serveur compromis d'interrompre les utilisateurs avec des requêtes non sollicitées et potentiellement malveillantes. Le passage à OAuth 2.1 obligatoire, avec la suppression des anciens mots de passe et des autorisations implicites et des protections telles que PKCE requises, réduit encore davantage le risque d'authentification.
Le compromis est que les décisions de sécurité que le protocole utilisé pour appliquer incombent désormais aux développeurs et aux opérateurs de plate-forme qui s'appuient sur celui-ci. Akamai présente plusieurs nouveaux domaines dans lesquels la sécurité d'un déploiement MCP dépend de la qualité de sa mise en œuvre.
La première découle directement du passage à un modèle apatride. Le protocole ne conservant plus de sessions permanentes, il émet des identifiants de suivi et des objets d'état que le serveur remet au client, qui les renvoie pour reprendre un workflow. Cela permet effectivement au client de détenir les clés de l'état d'une tâche. Puisque ces valeurs proviennent du client, le serveur ne peut pas leur faire aveuglément confiance.
Le risque apparaît lorsqu'un serveur utilise des ID de suivi prévisibles ou ne parvient pas à valider l'intégrité d'un objet d'état renvoyé. Un attaquant pourrait alors deviner ou modifier ces valeurs pour détourner le flux de travail actif d'un autre utilisateur, accéder aux données appartenant à un autre agent ou déclencher des actions inter-locataires non autorisées. La spécification avertit les développeurs de vérifier ces objets, mais ne définit pas de norme sur la manière de procéder, a noté Akamai, laissant le travail aux développeurs de serveurs individuels.
Un deuxième risque réside dans un nouvel objet _meta qui permet aux clients de joindre des métadonnées personnalisées à presque tous les messages MCP. Les champs ne portent aucune signature cryptographique. Un attaquant peut insérer ses propres paires clé-valeur, par exemple un locataire étiqueté « admin ». Si le serveur utilise ces métadonnées pour effectuer des appels de routage ou d’autorisation, cette paire forgée leur confère une élévation de privilèges ou un accès entre locataires. Une seule demande suffit.
MCP définit également ses propres en-têtes HTTP, parmi lesquels Mcp-Method et Mcp-Name, afin que les proxys et les passerelles puissent acheminer les requêtes sans creuser dans le corps. Cette confiance est la faiblesse. Envoyez une valeur dans l'en-tête, une autre dans le corps JSON-RPC. Le proxy fait confiance à sa copie, le serveur fait confiance à l'autre et la discordance laisse passer une requête qu'aucun des deux ne permettrait par lui-même. Akamai appelle cela une désynchronisation. Il peut échapper aux contrôles de sécurité, à la surveillance aveugle ou enterrer les traces d'un attaquant.
Une directive connexe, x-mcp-header, mappe les arguments de l'outil choisi directement dans les en-têtes HTTP, épargnant ainsi aux proxys le coût de l'analyse du corps. Pratique, jusqu'à ce que quelqu'un cartographie la mauvaise chose. Mappez par erreur une clé d'interface de programmation d'application, un jeton ou une donnée personnelle, et le secret circule dans l'en-tête, exposé à chaque équilibreur de charge, proxy et journal entre le client et le serveur.
La quatrième surface déplace le problème dans le navigateur. Les applications MCP, les panneaux interactifs tels que les formulaires, les tableaux de bord et les visionneuses de documents qui apparaissent dans les applications d'IA, constituent désormais une extension de protocole de premier ordre.
Akamai prévient que la fonctionnalité importe les scripts intersites stockés dans l'écosystème de l'IA. Un attaquant pourrait stocker du HTML ou du JavaScript malveillant via un outil et le script s'exécuterait lorsqu'un autre utilisateur ou agent consulterait le contenu.
La spécification exige que ces scripts s'exécutent dans une iframe en bac à sable, ce qui bloque une prise en charge complète de l'agent. Mais Akamai a déclaré qu'un panneau compromis pourrait toujours afficher du contenu trompeur, pirater des informations sensibles via de fausses invites et voler toutes les données utilisateur visibles dans le panneau.
Le dernier est un vecteur de déni de service qu'Akamai qualifie d'abus de tâches « délit de fuite ». Les tâches de longue durée sont ici en cause. En faire tourner un ne coûte presque rien au client tandis que le serveur paie en puissance de traitement, en mémoire ou en stockage.
Un attaquant génère une opération coûteuse avec une seule requête, abandonne la connexion et s'en va. Le serveur continue de produire du travail que personne n'attend, jusqu'à ce qu'il soit à court d'énergie.
En fin de compte, selon Akamai, la question a évolué. Il ne s’agit plus de savoir si MCP lui-même est sécurisé. Il s'agit de savoir si chaque application construite dessus respecte les nouvelles limites de confiance, la gestion des états et les modèles d'exécution.
Pour ce faire, a déclaré la société, les équipes de sécurité doivent traiter tous les états et métadonnées fournis par le client comme des entrées non fiables, appliquer une vérification cryptographique, appliquer le codage de sortie aux panneaux visuels générés par l'IA et définir des quotas de ressources pour les tâches asynchrones.
Le rapport a été rédigé par les chercheurs d'Akamai Maxim Zavodchik, Segev Fogel et Gal Meiri.
