MCP en périphérie : ce qui change lorsque le MCP s'exécute en toute sécurité dans chaque POP

Les serveurs Model Context Protocol (MCP) donnent aux agents d'IA un moyen standard d'appeler des outils, de lire des ressources et d'importer des prompts en masse. 

La plupart des serveurs MCP s'exécutent dans une architecture cloud héritée : une seule région, derrière un équilibreur de charge, en maintenant une session par client. C'est une approche raisonnable, jusqu'à ce qu'un agent situé à l'autre bout du monde effectue quarante appels d'outils pour accomplir une seule tâche, et que chaque appel subisse un aller-retour transcontinental au sein de sa boucle de raisonnement. Ces allers-retours sur de longues distances s'accumulent rapidement et détruisent les performances de votre application.

Exécuter votre serveur MCP sur Fastly Compute en tant que binaire WebAssembly sur l'ensemble de nos data centers, propulsé et sécurisé par notre plateforme mondiale de plus de 620 To/s, change la donne quant à ce que MCP peut apporter aux agents et aux humains qui les contrôlent. Nous venons de publier un exemple de projet qui fait exactement cela et auquel vos agents de codage peuvent se référer pour moderniser votre propre pile MCP. 

Plus besoin de payer pour un hébergement de niche ou d'isoler votre serveur dans une seule région géographique. De plus, vous pouvez tester l'ensemble du projet localement avec Viceroy, l'environnement d'exécution Compute local de Fastly, avant de le déployer sur le réseau. Ci-dessous, nous allons détailler le fonctionnement d'un serveur MCP sans état en périphérie.

Résoudre la latence là où cela compte : à l'intérieur de la boucle d'agent

Les agents ne font pas un seul appel avant de s'arrêter. Ils découvrent des outils, en appellent un, lisent le résultat, en appellent un autre et fonctionnent en boucle parfois une douzaine de fois avant de répondre. Chacun de ces sauts de réseau se trouve sur le chemin critique du flux de travail de l'agent. Si vous hébergez votre serveur MCP dans une architecture traditionnelle, un développeur utilisateur final qui s'appuie sur votre serveur MCP à l'autre bout du monde pourrait subir jusqu'à 500 ms de retard pour chaque appel, et son agent pourrait effectuer des dizaines d'appels par action. Ce retard s'accumule rapidement et conduit à une expérience utilisateur désastreuse. 

En périphérie, le serveur se trouve à quelques millisecondes de tout point d'origine d'une requête. Il n'existe aucune limitation de région d'origine, ni aucun rapatriement vers un data center principal. Le catalogue d'outils, la répartition des appels, la vérification de l'authentification : tout est traité au POP le plus proche. Pour une charge de travail d'agent générant de nombreux échanges, réduire de plusieurs centaines de millisecondes chaque appel se traduit par une boucle agentique sensiblement plus rapide.

Sans état par conception, pour permettre à n'importe quel POP de répondre

La dernière révision de MCP (28-07-2026) a été conçue pour être sans état, afin d'être plus conforme aux bonnes pratiques HTTP, et nous sommes ravis de soutenir l'Agentic AI Foundation dans ses recherches autour de ce sujet et des futures avancées.

La différence notable dans cette révision est qu'il n'y a pas de négociation d'initialisation. Chaque requête transporte sa propre identité et ses fonctionnalités négociées dans un bloc _meta, et tout état qui doit persister entre les appels voyage avec la requête plutôt que de résider sur le serveur.

Puisqu'aucune session n'est rattachée à une machine, un déploiement sans état en périphérie est désormais bien plus intéressant que dans les spécifications précédentes. Avec cette implémentation sur une plateforme moderne comme celle de Fastly : 

• Votre serveur MCP est instantanément déployé partout. Une requête peut arriver sur n'importe quel datacenter Fastly dans le monde entier et être traitée correctement.

• La mise à l'échelle est horizontale et automatique, sans latence de démarrage à froid. Fastly lance votre serveur MCP en moins de 50 microsecondes.

• Chaque requête est isolée en toute sécurité au sein de notre environnement d'exécution basé sur WebAssembly, éliminant tout risque de sécurité lié aux voisins bruyants.

Vous bénéficiez de la simplicité opérationnelle d'une plateforme distribuée à l'échelle mondiale en un seul déploiement.

Tâches de longue durée et en plusieurs étapes sans maintenir de connexion

L'approche « sans état » semble généralement incompatible avec l'approche « longue durée ». Les deux mécanismes de continuation de la spécification assurent son fonctionnement, et notre implémentation s'appuie sur les deux :

• Requêtes à allers-retours multiples (MRTR) : un outil peut s'interrompre au cours d'un appel pour demander une entrée au client et reprendre plus tard. L'état en cours est scellé dans un jeton opaque que le client renvoie lors de l'appel suivant. Aucune connexion n'est maintenue ouverte ; n'importe quelle instance reprend la tâche.

• L'extension Tasks : un outil capable de déclencher des tâches de longue durée et de renvoyer un identifiant de tâche. Le client interroge l'état d'achèvement au lieu de maintenir un socket pendant toute la durée. Il s'intègre bien au modèle de requête de Fastly.

Les deux jetons de continuation sont scellés de manière cryptographique à l'aide d'un chiffrement authentifié et liés à l'identité de l'appelant, de sorte que le modèle « l'état voyage avec la requête » ne devienne pas un moyen de falsifier ou de détourner des tâches.

Le catalogue d'outils, distribué depuis le cache

Les appels de découverte et de listage (server/discover, tools/list, prompts/list, resources/list) renvoient la même réponse à chaque appelant et changent rarement. Ils sont parfaits pour être mis en cache en périphérie via la fonctionnalité de mise en cache native de Fastly.

Le serveur marque ces réponses avec des indications de nouveauté et de portée du cache, afin que le cache puisse fournir le catalogue d'outils aux agents du monde entier sans réexécuter le gestionnaire à chaque fois. Tout ce qui dépend de la personne qui effectue la demande est automatiquement exclu du cache et ne fuit jamais d'une requête à l'autre.

La sécurité est appliquée avant que quoi que ce soit n'atteigne votre serveur d'origine

Comme Fastly se positionne en amont de tout ce avec quoi vos outils communiquent réellement, il s'agit de l'endroit idéal pour appliquer les contrôles d'accès. Nous avons veillé à intégrer la fonctionnalité suivante dans le prototype :

• L'authentification est fail-closed par défaut : une erreur de configuration entraîne un point de terminaison verrouillé ou indisponible. Il n'est jamais silencieusement ouvert.

• Les jetons Bearer sont vérifiés en périphérie : les JWT ES256 sont validés par rapport à un JWKS mis en cache, afin que les requêtes non authentifiées ou incorrectes soient rejetées avant de vous coûter quoi que ce soit en aval.

• L'autorisation applique le principe de refus par défaut et est délimitée : un appelant doit détenir les portées spécifiques déclarées par un outil ; un outil qui n'en déclare aucune ne peut pas être appelé sous autorisation.

• Les corps de requête sont limités avant analyse : les récupérations JWKS sont protégées contre les SSRF, et les erreurs internes sont masquées avec des identifiants de corrélation pour le débogage.

Une requête non autorisée ou abusive est bloquée au sein de Fastly et n'atteint jamais votre back-end.

Boosté par toute la puissance de la plateforme Fastly

Le prototype MCP s'exécute au sein de Fastly Compute. Il bénéficie donc de toute la résilience et de toutes les fonctionnalités de la plateforme comme atouts, parmi lesquelles :

• Démarrages à froid de moins de 50 microsecondes

• Isolation sécurisée via notre environnement d'exécution WebAssembly

• Protection DDoS en un clic

• Plus de 620 To/s de capacité lorsque vous en avez besoin

• Réduction des demandes pour éviter un problème de trafic intense lorsque votre produit devient viral

La spécification MCP sans état et l'environnement d'exécution de Fastly se renforcent mutuellement : le protocole a été conçu pour que l'état voyage avec la requête, et la périphérie est l'endroit où cette conception prend tout son sens. Ce qui transformait auparavant ce qui est normalement un service rattaché à une seule région et lié à une session en quelque chose qui est partout, au plus près de chaque agent qui l'appelle.

Gouvernez le trafic d'IA et d'agents avec ARC en utilisant des limitations du débit par clé, des contrôles des dépenses, un logging détaillé et un basculement automatique entre fournisseurs.

Découvrez comment Fastly pour l’IA aide les équipes à créer, protéger et exploiter des applications agentiques en périphérie.

Pour l'essayer, consultez le projet sur GitHub.