MCP 2026-07-28 : ce que le protocole sans état signifie pour les déploiements d'agents B2B

Pourquoi cette version change l'équation de déploiement

Le Model Context Protocol (MCP) est un standard ouvert pour connecter les agents IA aux systèmes externes. Le 28 juillet 2026, il publie sa plus grande révision depuis son lancement — un spécification finale qui rend la couche de protocole sans état, introduit des extensions de premier ordre et déprécie trois fonctionnalités qui ajoutaient de la complexité sans justifier leur place en production.

Pour les équipes qui déploient des serveurs MCP derrière des systèmes d'agents B2B, l'impact pratique est concret : vous n'avez plus besoin de sessions persistantes, de magasins de sessions partagés ou d'équilibreurs de charge sensibles aux sessions. L'état dont un agent a besoin à travers plusieurs appels d'outils devient un handle explicite — visible pour le modèle, auditable dans les journaux et mettable en cache par les intermédiaires. Cet article parcourt les changements qui comptent pour les déploiements B2B et leur correspondance avec le pattern de module MCP que nous livrons déjà.

La couche de protocole sans état

Le changement principal : la poignée de main initialize / initialized et l'en-tête Mcp-Session-Id sont supprimés. Les requêtes sont désormais autonomes. La version du protocole, les informations client et les capacités transitent dans _meta sur chaque requête, pas dans une session négociée que le serveur doit mémoriser.

Ce que cela élimine dans un déploiement B2B :

• Équilibreurs de charge à sessions persistantes. Les serveurs MCP distants peuvent se trouver derrière des équilibreurs de charge en simple tourniquet. N'importe quelle instance de serveur peut traiter n'importe quelle requête car aucun état côté serveur n'est requis pour l'interpréter.
• Magasins de sessions partagés. Si vous mettez à l'échelle horizontalement aujourd'hui, chaque instance de serveur MCP a besoin d'accéder au même état de session — généralement Redis ou une base de données. Le protocole sans état supprime cette dépendance.
• Infrastructure de rejeu de session. Lorsqu'une session tombe en cours de flux de travail, le client doit réinitialiser et réétablir le contexte. Le protocole sans état n'a pas de session à faire tomber ; chaque requête transporte ce dont elle a besoin.

La forme du déploiement devient plus simple : un pool d'instances de serveurs MCP sans état derrière un équilibreur de charge, sans tier d'état partagé entre elles. C'est la même forme que n'importe quelle API HTTP sans état — éprouvée, observable et peu coûteuse à mettre à l'échelle.

Le pattern de handle explicite pour les flux de travail avec état

Sans état ne signifie pas que l'état disparaît. Les flux de travail qui s'étendent sur plusieurs appels d'outils — une réception de RFQ, une négociation de devis, une réservation de disponibilité — ont toujours besoin de continuité. Le spécification finale remplace l'état de session caché par le pattern de handle explicite : un outil crée un handle (un order_id, un quote_id, un basket_id) et le modèle le repasse comme argument ordinaire lors des appels suivants.

C'est un changement significatif pour les déploiements B2B pour trois raisons.

L'état est visible pour le modèle. Aujourd'hui, l'état de session vit dans des métadonnées de transport que le LLM ne voit jamais. Avec les handles explicites, le modèle détient et référence le handle dans son raisonnement. Lorsque le modèle appelle get_quote(quote_id="q-7f3a"), il sait sur quel devis il opère. Cela améliore la précision de sélection d'outils dans les flux de travail à étapes multiples.

L'état est auditable dans les journaux. Chaque requête transporte son handle dans le corps de la requête, pas dans un en-tête que le journaliseseur d'application supprime. Un trail d'audit peut reconstruire l'état complet du flux de travail à n'importe quel point en lisant les arguments de la requête — aucune corrélation avec les journaux du magasin de sessions n'est nécessaire.

L'état est mettable en cache par les intermédiaires. Parce que le handle fait partie de la requête, une passerelle ou une couche de cache peut s'y fier. Les résultats de liste et de ressource portent les champs ttlMs et cacheScope, donc une requête de catalogue avec un handle stable peut être servie depuis le cache sans solliciter le système en amont.

Comment cela correspond à un flux de travail RFQ

Considérez un flux de travail de devis qui s'exécute sur cinq appels d'outils : créer la demande, chercher dans le catalogue, générer le devis, réserver la disponibilité, appliquer le palier de prix. Sous le protocole basé sur session, ces cinq appels partagent une session côté serveur. Sous le pattern de handle explicite :

1. create_request(buyer_id, line_items) → request_id="r-1042"
2. search_catalog(request_id="r-1042", query="industrial pump 220V")
3. generate_quote(request_id="r-1042", supplier_ids=["s-12", "s-19"])
       → quote_id="q-7f3a"
4. hold_availability(quote_id="q-7f3a", hold_duration="48h")
       → hold_id="h-3391"
5. apply_pricing_tier(quote_id="q-7f3a", tier="volume-3")

Chaque appel transporte le handle dont il a besoin. Aucun serveur ne mémorise quoi que ce soit entre les appels. Si l'équilibreur de charge achemine l'appel 4 vers une instance différente de l'appel 3, cela fonctionne toujours — le handle est dans la requête. Si l'équipe d'audit doit reconstruire ce flux de travail une semaine plus tard, les handles dans les arguments de requête racontent toute l'histoire.

Extensions : de premier ordre et versionnées indépendamment

Le spécification finale introduit les extensions comme concept de premier ordre. Les extensions reçoivent des identifiants reverse-DNS (par ex. com.example.workflow), possèdent des dépôts ext-*, ont des responsables délégués et sont versionnées indépendamment du protocole central.

Les deux premières extensions sont concrètes :

• MCP Apps — des UI HTML rendues côté serveur livrées dans des iframes bac à sable. Un serveur MCP peut livrer une UI qu'un client affiche, permettant des surfaces d'approbation humaine dans la boucle sans que le client construise un frontend personnalisé.
• Tasks — des travaux longs avec des handles de tâche. Un outil peut renvoyer un handle de tâche immédiatement et le client interroge l'achèvement, plutôt que de maintenir une connexion ouverte pendant des minutes.

Pour les déploiements B2B, MCP Apps comptent là où un humain doit approuver une transaction avant que l'agent ne poursuive — un bon de commande au-dessus d'un seuil, un devis avec une remise non standard. La surface d'approbation peut être livrée avec le module MCP plutôt que de nécessiter un frontend séparé. Tasks comptent pour les flux de travail qui dépassent un seul délai de requête : un devis fournisseur qui prend 90 secondes à générer, une synchronisation de catalogue qui dure des minutes.

Déprécations : Roots, Sampling, Logging

Trois fonctionnalités sont dépréciées (en annotation seule pendant 12 mois ; la suppression nécessite un processus de normes séparé) :

• Roots → remplacés par les paramètres d'outil et les URI de ressource. Roots étaient un moyen pour les clients d'indiquer aux serveurs des emplacements de système de fichiers ; la même intention s'exprime désormais en arguments d'outils qui lisent des fichiers.
• Sampling → remplacé par l'intégration directe avec l'API du fournisseur LLM. Les serveurs qui ont besoin d'appels LLM les font directement au fournisseur, plutôt que de demander au client d'effectuer un aller-retour de sampling.
• Logging → remplacé par stderr et OpenTelemetry. La journalisation du serveur passe à la sortie de processus standard et au traçage distribué, pas au canal de journalisation MCP.

La dépréciation de Logging est la plus pertinente pour les déploiements B2B. Le pattern de journalisation d'audit — où chaque appel d'outil journalise la requête, la réponse, la latence et le résultat — s'aligne désormais avec OpenTelemetry plutôt qu'avec un canal de journalisation spécifique au protocole. Cela signifie que les journaux du serveur MCP s'intègrent aux pipelines d'observabilité existants (Datadog, CloudWatch, Honeycomb) sans transport personnalisé.

Routable, mettable en cache, traçable

Trois ajouts qui affectent les opérations de production :

• Les en-têtes Mcp-Method et Mcp-Name permettent le routage par passerelle sans inspection du corps. Une passerelle peut router par méthode et nom d'outil au niveau des en-têtes — pas de parsing JSON dans la couche de routage.
• ttlMs et cacheScope sur les résultats de liste/ressource donnent aux intermédiaires un contrat de mise en cache standard. Une réponse de liste de catalogue peut déclarer un TTL de 5 minutes, et n'importe quelle passerelle sur le chemin peut le respecter.
• La propagation du W3C Trace Context est documentée pour la compatibilité OpenTelemetry. Une trace initiée par le client agent se propage à travers le serveur MCP et dans les appels système en amont, de sorte qu'un seul flux de travail RFQ apparaît comme une seule trace à travers chaque système qu'il touche.

Pour un déploiement B2B qui exécute des serveurs MCP pour NetSuite, HubSpot et un catalogue fournisseur, cela signifie : une passerelle peut router par nom d'outil sans parser les corps, mettre en cache les réponses de catalogue pour un TTL déclaré et tracer une seule demande de devis de l'agent à l'ERP à l'API fournisseur dans un seul arbre de spans.

Renforcement de l'autorisation pour la forme un-à-plusieurs

Le spécification finale améliore OAuth et OpenID Connect pour la forme de déploiement que les systèmes d'agents B2B utilisent réellement : un client (l'agent) se connectant à de nombreux serveurs (NetSuite, HubSpot, BigCommerce, un catalogue fournisseur). L'actualisation des jetons, la gestion des scopes et le traitement multi-serveurs des identifiants sont traités dans la spécification plutôt que laissés à chaque intégration à résoudre indépendamment.

Cela compte parce que les systèmes d'agents B2B ne se connectent pas à un seul système. Un agent RFQ typique se connecte à un ERP (NetSuite), un CRM (HubSpot), une plateforme e-commerce (BigCommerce) et deux ou trois catalogues fournisseurs — chacun avec son propre flux OAuth, sa durée de vie de jeton et son ensemble de scopes. Le protocole fournit désormais un pattern standard pour gérer cette complexité, plutôt que chaque module MCP implémentant son propre cycle de vie d'identifiants.

Update — 2026-08-06: Terraform MCP CVE-2026-16496 (CVSS 10.0) — the stateless thesis validated in production

HashiCorp patched CVE-2026-16496 (CVSS 10.0) in Terraform MCP Server before version 1.1.0 — the first maximum-severity CVE in the MCP ecosystem. The vulnerability is an authorization bypass in the streamable-HTTP stateful transport mode: a user who obtains another user's MCP session ID can have their tool calls executed using that user's Terraform credentials. HashiCorp also patched CVE-2026-16498 (tenant isolation break) and CVE-2026-14869 (SSRF) in the same release. (The Hacker News, SentinelOne vulnerability database)

This CVE is the first production evidence that the stateful transport mode is a security liability, not just an operational complexity — and it validates the core thesis of this article. The stateless protocol layer the July 28 final specification introduced exists precisely to eliminate the server-side session state that this attack exploits. The attack vector (session-ID theft leading to credential reuse) exists only because the server holds a session state that an attacker can steal and reuse. A stateless server has no session to steal. The explicit-handle pattern this article describes — where stateful workflows mint handles that travel in the request body, not in a server-side session — is the architecture that closes this vulnerability class. The vulnerability affects only the stateful streamable-HTTP transport mode; the stateless protocol core is not affected.

For B2B deployments, the implication is direct: if your MCP servers run stateful streamable-HTTP with Mcp-Session-Id, they carry the session-hijacking attack surface that CVE-2026-16496 exploits. Migrating to the stateless protocol core (Control 1 in the MCP Security Hardening Checklist) eliminates the attack surface at the architecture level, not the patch level. The 12-month SSE deprecation window is now a security deadline, not just an operational one.

Sécurité : trois nouvelles surfaces d'attaque et un point de données de défense en profondeur

La refonte sans état introduit trois nouvelles surfaces d'attaque identifiées par backslash.security dans leur analyse du jour même de la spécification finale :

• Détournement de handles. Les handles explicites remplacent l'état de session côté serveur, mais un handle est un argument ordinaire. Si l'espace de handles est prévisible ou si le transport manque de protection d'intégrité, un attaquant qui observe ou devine un handle peut l'injecter dans ses propres requêtes — en usurpant l'identité du propriétaire du flux de travail. La solution est la génération cryptographique de handles (aléatoires, non devinables) et la liaison des handles à l'appelant authentifié, pas seulement au corps de la requête.
• Lacune de portée du système de fichiers. La dépréciation de Roots supprime la déclaration de limite du système de fichiers côté client. Les outils qui lisent des fichiers reçoivent désormais des chemins comme arguments, mais sans la limite Roots, un outil peut accéder à des emplacements du système de fichiers que le client n'a jamais voulu exposer. La solution est la validation de chemin par outil contre une liste d'autorisation explicite, pas la dépendance à une limite au niveau du protocole qui n'existe plus.
• Rendu HTML de MCP Apps. L'extension MCP Apps permet aux serveurs de livrer des UIs HTML dans des iframes en sandbox. Le sandbox est une limite de sécurité, mais le contenu HTML provient du serveur — un serveur MCP compromis ou malveillant peut livrer une UI qui tente de s'échapper du sandbox ou de phishing l'utilisateur. La solution est de traiter le HTML de MCP Apps comme un contenu non fiable : Content Security Policy stricte, pas d'accès same-origin, et confirmation de l'utilisateur avant de rendre les surfaces d'application des nouveaux serveurs.

Un point de données de défense en profondeur : Claude Opus 5 avec Auto Mode activé a atteint un taux de succès d'attaque par injection de prompt en navigateur de 0% sur 129 scénarios de test — le premier point de données concret montrant que l'injection de prompt d'agent navigateur peut être réduite à zéro. Auto Mode combine une sonde d'injection de prompt en couche d'entrée avec un classificateur d'actions en couche de sortie. Pour les déploiements MCP sans état où les agents navigateur appellent des outils MCP, le modèle de scan d'entrée + blocage de tâches est une implémentation concrète de défense en profondeur que la conception sans état du protocole facilite : chaque requête est autonome, donc la sonde et le classificateur opèrent sur chaque requête indépendamment, sans état de session à corrompre.

Ce qui change pour les modules MCP existants

Si vous livrez déjà des modules MCP — par exemple, le pattern de processeur RFQ à 38 outils où les outils sont enregistrés via MCP_CONFIGURATION et les mixins de domaine composent sur un client GraphQL partagé — le protocole sans état change le déploiement, pas le code du module.

L'enregistrement des outils du module, les schémas d'entrée/sortie, les limites de débit et la journalisation d'audit restent les mêmes. Ce qui change :

• Pas d'initialisation de session au démarrage. Le module ne participe pas à une poignée de main initialize. Il reçoit des requêtes avec _meta portant la version du protocole et les capacités, et répond.
• Les outils avec état créent des handles. Si un outil s'appuie aujourd'hui sur une session côté serveur pour suivre un flux de travail à étapes multiples, il doit créer un handle explicite et le renvoyer. Le client le repasse à l'appel suivant. Pour un processeur RFQ, le request_id, le quote_id et le hold_id sont déjà les handles — le pattern est naturel au domaine.
• La journalisation passe à OpenTelemetry. Si le module journalise via le canal de journalisation MCP, migrez vers stderr et les spans OpenTelemetry. Le contenu d'audit (requête, réponse, latence, résultat) reste ; le transport change.
• La mise en cache est déclarative. Les endpoints de liste et de ressource peuvent déclarer ttlMs et cacheScope sur leurs réponses, permettant aux intermédiaires de mettre en cache sans deviner.

La conclusion pour les équipes B2B

Le protocole sans état réduit l'infrastructure qu'un déploiement d'agent basé sur MCP nécessite. Vous échangez les sessions persistantes et les magasins de sessions partagés contre des handles explicites dans les arguments de requête — un échange qui rend le système plus simple à mettre à l'échelle, plus facile à auditer et plus observable dans des outils standard.

Si votre équipe délimite un déploiement d'agent basé sur MCP, le spécification finale du 28 juillet est la version à cibler. Concevoir pour des handles explicites dès le départ évite la migration depuis un état basé sur session plus tard.

---

Un distributeur qui exploite NetSuite, BigCommerce et trois catalogues fournisseurs obtient un agent qui reçoit un RFQ par e-mail ou portail, résout les produits et substituts contre le graphe de catalogue, fixe les prix par palier client, réserve le stock avec une expiration et écrit le devis accepté dans NetSuite — chaque étape journalisée. Cette construction correspond aux phases 2-3 de la méthode en quatre étapes et est généralement en ligne en 5-8 semaines.

Demandez une construction délimitée. Découverte d'une semaine. Vous obtenez un inventaire des systèmes, une cartographie des flux de travail et un périmètre fixe — que vous construisiez avec nous ou non.