Pourquoi OAuth ne suffit pas à sécuriser le nouveau MCP

La mise à l’échelle de MCP est aussi une migration de l’architecture de sécurité

La révision du 28 juillet du Model Context Protocol facilite la mise à l’échelle de l’infrastructure d’agents en entreprise, mais elle supprime aussi une frontière sur laquelle de nombreuses décisions de sécurité s’appuyaient auparavant. Cette version, la plus importante révision de MCP depuis son lancement initial, a introduit un fonctionnement sans état sur HTTP standard, une autorisation native OAuth et des interfaces rendues côté serveur via MCP Apps. Son délai de dépréciation de 12 mois a également commencé ce jour-là, plaçant les équipes plateforme concernées sur une trajectoire de migration qui s’étend au moins jusqu’à la mi-2027.

Cette migration a commencé dans un contexte d’adoption rapide. Les quatre SDK Tier 1 prenaient en charge cette version dès la fin de son premier jour, tandis que Cloudflare assurait une prise en charge dès le jour de sortie via son Agents SDK et indiquait que des clients comme Sentry et Linear l’avaient adoptée immédiatement. Cloudflare a un intérêt commercial dans l’adoption de MCP, car l’entreprise fournit l’infrastructure de création d’agents via ce SDK. Dans l’écosystème au sens large, les SDK Tier 1 de MCP totalisent près d’un demi-milliard de téléchargements par mois, tandis que ses SDK TypeScript et Python ont chacun dépassé le milliard de téléchargements cumulés.

Cette ampleur rend la conséquence architecturale plus importante que la vitesse de publication. L’expérience acquise au cours de deux années de construction de systèmes d’agents connectant des outils d’entreprise via MCP montre que cette révision transfère davantage de mécanismes de sécurité des sessions de protocole vers les endpoints et les développeurs qui les exploitent. Le MCP sans état rend les agents à l’échelle de l’entreprise praticables sur une infrastructure standard, mais cette même conception modifie l’endroit où l’identité, l’état, le contenu et l’exécution doivent être considérés comme fiables.

À mesure que ces responsabilités se déplacent, une mise à niveau du protocole apparemment réussie peut conserver des contrôles de sécurité conçus pour l’architecture précédente. Une équipe peut migrer ses serveurs, adopter OAuth et monter en charge horizontalement tout en conservant des contrôles qui dépendent de sessions persistantes et de la visibilité réseau. Le principe directeur de la nouvelle conception est explicite : « Le protocole n’applique pas la sécurité à votre place. » La migration doit donc tenir compte de l’endroit où cette application de la sécurité s’est déplacée.

Le MCP sans état supprime la session comme frontière de contrôle

Le premier point où l’application des contrôles se déplace est la session. Dans la conception sans état, une session MCP ne détermine plus à quel endroit une requête appartient : l’en-tête Mcp-Session-Id et les handshakes initialize/initialized qui reliaient auparavant un client à une instance de serveur particulière sont supprimés. La version du protocole, les informations client et les capacités du client sont désormais transmises en ligne avec chaque requête, de sorte que toute instance de serveur compatible peut traiter l’appel suivant.

Cette indépendance des requêtes rend la conception attractive à grande échelle. Le trafic peut passer par un équilibrage de charge en round-robin, et des instances peuvent être ajoutées ou supprimées via l’autoscaling sans conserver une conversation MCP sur une machine spécifique. L’état applicatif qui doit survivre entre les appels peut être transporté via des handles d’état portables, des références qui transportent l’état entre les appels d’outils, plutôt que de résider implicitement dans une session de transport. L’infrastructure peut par conséquent traiter les requêtes MCP beaucoup plus comme des traitements HTTP indépendamment routables.

Parce que les requêtes sont désormais indépendantes, les décisions de sécurité qui valaient autrefois pour une session doivent être établies à la nouvelle frontière appropriée. Une gateway pouvait auparavant approuver un client au début d’une session et prolonger cette décision dans le contexte de la session. Avec des appels indépendants, chaque requête doit transporter suffisamment d’informations pour que le système récepteur décide comment la traiter.

Le même déplacement apparaît dans les principaux changements de cette révision :

L’extension Tasks rend la conséquence sur l’identité particulièrement claire. Une tâche de longue durée peut survivre à la connexion qui l’a initiée, son autorisation a donc besoin d’une identité qui persiste après la fin de la connexion. La tâche peut alors rester liée à cette identité, avec son périmètre autorisé appliqué chaque fois qu’une activité ultérieure s’y réfère.

Le même besoin de liaison explicite s’applique à l’état portable. Parce que l’état se déplace entre les appels, la possession d’une référence d’état devient pertinente du point de vue de la sécurité indépendamment du transport qui l’a livrée. L’endpoint qui reçoit la référence doit donc valider à la fois la référence et l’identité qui la présente.

Ces changements signifient qu’une équipe plateforme peut implémenter correctement le protocole du 28 juillet tout en conservant des hypothèses de sécurité liées aux sessions. Une gateway dépendante des sessions associée à des serveurs sans état préserve des contrôles dont le contexte de confiance d’origine a disparu. L’absence d’état améliore précisément la mise à l’échelle parce que les requêtes deviennent indépendantes, et cette indépendance exige que l’application des contrôles les suive.

L’ancien socle de sécurité était déjà sous tension

Le déplacement de l’application des contrôles est important parce que les problèmes de sécurité de MCP étaient visibles avant même que le modèle de contrôle ne change. Les préoccupations existantes incluaient des serveurs MCP trop permissifs, des déploiements sans authentification et le tool poisoning, dans lequel des descriptions ou sorties d’outils malveillantes influencent le comportement d’un agent. La révision du 28 juillet modifie l’endroit où les défenses doivent intercepter ces risques, tout en ajoutant la portabilité de l’état et le rendu côté client à l’environnement que les équipes sécurité doivent gouverner.

Censys a fourni une mesure de l’exposition existante dans une analyse de fin avril, en identifiant 12 520 services MCP accessibles depuis l’internet public. Cette exposition coexistait avec une caractéristique de MCP : l’absence d’authentification par défaut. L’accessibilité publique à elle seule n’établit pas l’exploitabilité, mais ce constat montre pourquoi les implémenteurs ont besoin de l’authentification et de l’autorisation comme contrôles applicatifs explicites.

OX Security a signalé un autre problème dans le transport STDIO de MCP, estimant qu’un seul défaut de conception mettait jusqu’à 200 000 serveurs en risque. STDIO fait passer la communication MCP par l’entrée et la sortie standard d’un processus plutôt que par un transport réseau conventionnel, ce qui rend cette découverte pertinente pour la sécurité des endpoints autant que pour la sécurité des serveurs. Son emplacement montre aussi une limite clé des défenses réseau : une part importante du comportement MCP peut se produire localement sur un hôte.

Ce risque local s’ajoutait à des avertissements plus larges à mesure que l’adoption progressait. En mai, l’Artificial Intelligence Security Center de la NSA avait publié des recommandations sur MCP, avertissant que l’adoption avait progressé plus vite que le modèle de sécurité du protocole. Backslash et Akamai ont, séparément, cartographié les changements de surface d’attaque associés à la spécification la plus récente ; les deux entreprises vendent des produits et services de sécurité, elles ont donc un intérêt commercial dans la demande de défenses contre ces risques. Les recherches de Microsoft sur le tool poisoning ajoutent un mécanisme connexe : un agent capable d’agir via des outils connectés peut transformer des instructions manipulées en actions lourdes de conséquences ailleurs.

Face à ce socle existant, la conception du 28 juillet place davantage de décisions dans les requêtes individuelles, les applications et les hôtes. Les accès permissifs et les contenus empoisonnés restent pertinents, tandis que l’état portable et le rendu côté client créent des décisions supplémentaires en dehors d’une session de transport persistante. Les équipes sécurité ont donc besoin de contrôles partout où l’identité, l’état, le contenu ou l’exécution prennent de l’importance.

Trois surfaces endpoint montrent les limites de l’autorisation des requêtes

Ce besoin peut sembler avoir une réponse simple : utiliser correctement OAuth standard, placer une gateway sensible à l’identité devant chaque serveur MCP et autoriser chaque requête. Les appels indépendants ont bien besoin d’une autorisation indépendante, ce qui rend ces contrôles nécessaires. Pourtant, trois surfaces endpoint exigent des décisions au-delà de la simple question de savoir si l’appelant a l’autorisation d’émettre la requête serveur : le contenu rendu, l’état portable et l’exécution associée à une identité authentifiée.

MCP Apps expose la surface du contenu rendu. Un serveur MCP peut fournir du HTML interactif à rendre par le client IA, plaçant un contenu applicatif fourni par le serveur dans l’environnement où un utilisateur travaille avec un agent. Le contenu s’exécute dans une iframe sandboxée, ce qui limite son comportement, mais le client le rend tout de même après que la gateway a approuvé la requête MCP.

Une fois le rendu effectué dans le client, le cross-site scripting stocké, ou XSS stocké, devient une préoccupation : du HTML ou du JavaScript malveillant est enregistré puis exécuté plus tard lorsqu’une personne consulte le contenu stocké. Un attaquant peut persister un tel contenu via un outil MCP ; plus tard, un agent ou un autre utilisateur le récupère et l’affiche, ce qui entraîne l’exécution du code dans l’interface de l’application. La sandbox de l’iframe limite une compromission complète, mais le client IA environnant opère au-dessus de ressources sensibles pouvant inclure du code source, des terminaux, des systèmes de fichiers et d’autres serveurs MCP connectés.

Parce que l’autorisation précède cette étape de rendu, les équipes sécurité ont besoin d’une décision de contenu distincte sur ce qu’un serveur autorisé peut amener le client à afficher et sur la manière dont ce contenu peut se comporter dans l’environnement hôte. La cartographie de la nouvelle surface d’attaque par Backslash et Akamai s’applique ici, avec leurs intérêts commerciaux en sécurité mentionnés plus haut. L’endpoint est devenu une partie du périmètre de sécurité effectif.

Les handles portables créent la deuxième surface endpoint. Un handle transporte explicitement l’état entre les appels d’outils, mais au niveau de la conversation, il s’agit d’une chaîne qui peut être copiée ou insérée dans un autre contexte. Toute personne qui obtient la chaîne concernée peut être en mesure de présenter un état qui aurait auparavant été associé implicitement à une session établie.

Le prompt injection peut fournir le chemin par lequel un tel handle se déplace. Une instruction malveillante intégrée dans un ticket Jira, par exemple, peut être consommée par un agent, tandis qu’une réponse d’outil offre un autre point d’entrée au contenu injecté. Si l’instruction provoque la divulgation, la copie ou l’insertion d’un handle valide là où un autre acteur peut l’utiliser, un problème d’intégrité des instructions devient un problème de possession d’état de type identifiant d’accès.

Cette séquence sépare le mécanisme facilitateur du mécanisme de livraison. L’état portable rend un handle réutilisable entre les appels, tandis que le prompt injection peut déplacer ce handle dans le mauvais contexte ou entre de mauvaises mains. L’hygiène conversationnelle peut réduire l’exposition aux instructions implantées, tandis que la propriété doit toujours être établie indépendamment lorsque le handle est présenté.

La validation des handles doit donc intervenir sur chaque requête qui en utilise un. Un endpoint doit vérifier l’identité qui le présente par rapport à l’identité pour laquelle le handle a été émis et appliquer le périmètre prévu. Sans cette liaison, un principal OAuth correctement authentifié pourrait présenter un état applicatif appartenant à une autre identité ou à un autre périmètre, de sorte que l’authentification de la requête réussirait alors que l’autorisation applicative échouerait.

OAuth constitue la troisième partie du modèle parce que ces requêtes indépendantes ont besoin d’une identité fiable. L’autorisation native OAuth donne à MCP des flux d’identité standard, tandis qu’OAuth 2.1 avec PKCE protège le flux d’autorisation contre d’importants scénarios d’interception et de substitution de code. Le consentement par client et la correspondance stricte des URI de redirection restreignent encore davantage les destinations possibles de l’autorisation.

Ce contrôle d’identité dépend aussi de l’audience du token. Un token émis pour un serveur MCP doit être rejeté par un autre, car son acceptation par des services MCP non liés élargirait l’accès créé par la divulgation d’un token. Une gateway sensible à l’identité peut valider l’audience sur chaque requête serveur entrante et rejeter un token destiné à un autre serveur.

Les Tasks de longue durée prolongent cette même exigence d’identité au-delà de la durée de vie d’une requête. Le travail asynchrone peut se poursuivre après la fin de la connexion initiatrice, la propriété doit donc être attachée à une identité et à un périmètre autorisé. Les appels ultérieurs qui interrogent, modifient ou consomment la tâche peuvent alors être évalués par rapport à cette relation d’autorisation persistante.

Ensemble, ces contrôles font d’OAuth plus une gateway sensible à l’identité un socle solide d’autorisation des requêtes, tandis que les autres surfaces ont toujours besoin de leurs propres contrôles. Du HTML malveillant atteint un client pour y être rendu, des serveurs MCP locaux peuvent agir sur un poste de travail, et un IDE peut exécuter des opérations ultérieures sans générer un nouvel événement de gateway. La propriété des handles exige de même une liaison applicative explicite entre le handle, l’identité et le périmètre.

Le modèle de menace qui en résulte suit l’intégralité du parcours d’action de l’agent. Chaque requête indépendante a besoin d’une décision d’autorisation, chaque handle portable a besoin de contrôles d’intégrité et d’identité, et chaque interface rendue place le contenu sous la gouvernance du client. À mesure que les agents gagnent en capacité d’action via des outils, les conclusions de Microsoft sur le tool poisoning rendent ces distinctions opérationnellement importantes, car des instructions et des états compromis peuvent conduire à des actions.

La frontière réseau s’arrête désormais avant la fin de l’activité MCP pertinente

Ces surfaces endpoint créent aussi un angle mort de visibilité. Une gateway peut savoir qu’un principal authentifié a envoyé une requête autorisée au serveur MCP prévu, tandis que l’activité ultérieure se poursuit à l’intérieur d’un client IA, d’un processus serveur local ou d’un IDE. Une telle activité se produit sur l’endpoint et peut ne générer aucune requête supplémentaire à la gateway qu’un contrôle réseau pourrait inspecter.

MCP Apps rend cette limite de visibilité concrète parce que le client rend leur HTML après l’avoir reçu. Les serveurs MCP locaux présentent la même limite lorsque les opérations restent sur l’hôte, tandis que l’exécution dans l’IDE peut agir sur du code ou sur des résultats d’outils dans l’environnement du développeur. Une gateway sensible à l’identité peut appliquer correctement chaque requête tout en n’ayant aucune connaissance directe de ces événements ultérieurs.

Une sécurité uniquement réseau laisse donc une partie du chemin d’exécution hors de son champ de vision. Une gateway qui conserve l’ancien état de session présente un décalage supplémentaire, car les appels MCP indépendants ne fournissent plus la frontière de session dont dépend cette politique. L’architecture a besoin de visibilité et d’application des contrôles là où l’état est présenté, où le contenu est rendu et où l’exécution locale se produit.

Les contrôles de migration doivent suivre les requêtes, les handles, les interfaces et l’exécution

Parce que le rendu fait désormais partie du périmètre de sécurité, la migration devrait commencer par l’identification des serveurs MCP capables d’envoyer des interfaces HTML dans les clients et les IDE. Les équipes ont besoin d’un inventaire de ces chemins de rendu et d’une politique de revue du HTML livré par ces serveurs. Une norme utile est le niveau d’examen appliqué aux scripts tiers envoyés vers un site web de production : les équipes doivent comprendre ce que du code fourni de l’extérieur peut faire dans l’environnement où il s’exécute.

Une fois les chemins de rendu identifiés, la conception de la gateway peut passer des hypothèses de session aux requêtes individuelles partout où l’état de session influence aujourd’hui les décisions d’accès. Chaque appel MCP a besoin d’inspection et d’application des contrôles, avec OAuth 2.1 plus PKCE, le consentement par client, la correspondance stricte des URI de redirection et des tokens liés à l’audience comme modèle d’autorisation renforcé. Une gateway sensible à l’identité doit se trouver devant chaque serveur et rejeter les requêtes dont les tokens sont absents, invalides ou destinés à une autre audience.

Une fois l’identité de la requête établie, les handles portables ont besoin de leur propre règle de confiance, car la validation OAuth n’établit pas la propriété d’un état applicatif arbitraire. Traitez chaque handle comme une entrée non fiable et vérifiez que l’identité qui le présente est bien celle à laquelle il a été émis, y compris le périmètre concerné. Au niveau de la conversation, supprimez ou signalez les contenus de type instruction dans les documents récupérés et les sorties d’outils, car ce sont des points d’entrée par lesquels une instruction injectée ou un handle implanté peut atteindre un workflow d’agent.

Ces contrôles sur les requêtes et l’état ont ensuite besoin d’une observabilité endpoint pour l’activité qui échappe à la visibilité de la gateway. Instrumentez le processus hôte, les serveurs MCP locaux et le rendu côté client afin que les équipes sécurité puissent observer le comportement après que des données autorisées ont atteint l’endpoint. Les organisations dont les contrôles MCP existants sont entièrement fondés sur le réseau ont besoin de cette couverture côté hôte pour les opérations locales et le rendu de MCP Apps.

Une fois les points d’application des contrôles en place, les tests doivent suivre l’exécution jusque dans la boucle d’agent en conditions réelles : le cycle répété dans lequel un modèle réel interprète le contexte, invoque des outils, reçoit des résultats et choisit son action suivante. Les tests unitaires peuvent établir qu’un serveur individuel implémente correctement le nouveau protocole, tandis que les interactions pilotées par les décisions du modèle n’émergent que lorsque plusieurs systèmes fonctionnent ensemble. Exécutez les serveurs migrés avec de vrais modèles réalisant de vrais workflows, puis vérifiez si l’état fuit entre les instances de serveur, si des handles sont réutilisés entre périmètres et si du contenu d’interface apparaît là où il n’était pas attendu.

Le calendrier de dépréciation donne à cette migration une fenêtre plateforme définie. Roots, sampling et logging sont dépréciés dans cette révision, ainsi que l’ancien transport HTTP+SSE, décrit comme imposant un travail de migration à la plupart des équipes plateforme. La politique de dépréciation de 12 mois a commencé le 28 juillet, plaçant le premier point de suppression annoncé à la mi-2027 et donnant aux équipes une période pour déplacer l’application des contrôles vers les requêtes, ajouter des contrôles endpoint et gouverner MCP Apps avant que leur usage ne se diffuse davantage.

Principaux enseignements pour les dirigeants

• Déplacez l’application de la sécurité vers chaque requête : Le MCP sans état supprime la session persistante comme frontière de contrôle, ce qui permet l’équilibrage de charge et l’autoscaling tout en déplaçant les décisions d’autorisation vers les appels individuels. Les équipes plateforme ont besoin d’une inspection au niveau de la requête, de contrôles d’identité et d’une application du périmètre sur l’ensemble des serveurs MCP.
• Réévaluez le socle de sécurité MCP existant : Les services exposés publiquement, les déploiements sans authentification, les risques STDIO locaux et le tool poisoning créent déjà une exposition pour l’entreprise. Les responsables sécurité doivent prendre en compte ces risques alors que l’état portable et le rendu côté client élargissent les surfaces sous leur contrôle.
• Sécurisez séparément l’identité, l’état et le contenu rendu : OAuth et les gateways sensibles à l’identité établissent qui peut appeler un serveur MCP, tandis que les handles portables et MCP Apps créent des décisions de confiance supplémentaires. Liez les handles à l’identité et au périmètre, gouvernez le HTML fourni par le serveur et appliquez la propriété des tâches tout au long des workflows asynchrones.
• Étendez la visibilité au-delà du réseau : L’activité MCP peut se poursuivre dans des clients IA, des serveurs locaux et des IDE après la fin d’une requête autorisée à la gateway. Les équipes sécurité ont besoin d’une télémétrie endpoint couvrant l’exécution locale et le rendu de MCP Apps pour observer cette partie du workflow de l’agent.
• Profitez de la fenêtre de migration pour repenser les contrôles : Le calendrier de dépréciation donne aux équipes plateforme jusqu’à au moins la mi-2027 pour remplacer les contrôles dépendants des sessions et les hypothèses héritées sur le transport. Les plans de migration doivent combiner autorisation par requête, validation des handles, gouvernance du rendu, observabilité endpoint et tests de la boucle d’agent en conditions réelles.