Un serveur MCP par service intégré, contre un seul serveur qui agrège Stripe, Algolia et Sentry derrière une interface commune : la différence entre ces deux architectures ne saute pas aux yeux tant que tout se passe bien. Elle devient en revanche évidente le jour où un agent chargé d’une tâche précise se retrouve, sans que personne ne l’ait vraiment décidé, en mesure d’en faire bien plus que prévu.
C’est ce qui s’est produit sur un projet e-commerce qui avait fait le choix, par souci de simplicité initiale, de construire un unique serveur MCP exposant à la fois les outils de facturation Stripe, de recherche produit Algolia et de suivi d’erreurs Sentry. Un agent conçu au départ pour aider les clients à retrouver un produit dans le catalogue s’est retrouvé, plusieurs mois plus tard, avec un accès technique aux outils de remboursement Stripe qu’aucun responsable n’avait explicitement validé pour cet usage.
Comment la dérive s’est installée
Le serveur MCP unique exposait bien des scopes différents en théorie, mais l’implémentation initiale ne les vérifiait que de façon partielle : un agent authentifié auprès du serveur avait accès à la liste complète des outils disponibles, y compris ceux qui ne le concernaient pas directement, dès lors qu’un développeur avait, par commodité lors d’une évolution rapide, élargi les scopes accordés à un jeton de test qui a fini par migrer tel quel en production.
Ce que cela a permis, sans qu’aucun incident grave ne survienne
Aucun remboursement injustifié n’a été déclenché : l’incident a été découvert lors d’une revue de sécurité de routine, pas à la suite d’un dommage constaté. Mais la simple possibilité qu’un agent de recherche produit puisse, en théorie, appeler un outil de remboursement Stripe, a suffi à déclencher une refonte complète de l’architecture, considérée comme un risque latent inacceptable une fois identifié.
// Extrait des scopes réellement accordés au jeton de l'agent recherche,
// découverts lors de l'audit
{
"agent": "assistant_recherche_produit",
"scopes_attendus": ["algolia:search"],
"scopes_reels": [
"algolia:search",
"algolia:write",
"stripe:refund",
"sentry:read"
]
}
Le découpage qui a suivi
La correction a consisté à séparer physiquement le serveur unique en trois serveurs MCP distincts, un par service, chacun avec sa propre authentification et son propre jeu de scopes strictement limité à son domaine :
- Un serveur MCP dédié exclusivement à la recherche Algolia, en lecture seule pour la majorité des agents
- Un serveur MCP dédié à Stripe, accessible uniquement aux agents explicitement habilités à la facturation
- Un serveur MCP dédié à Sentry, réservé aux agents de supervision technique
Ce découpage a un coût réel : chaque serveur doit désormais être maintenu, surveillé et versionné séparément, ce qui alourdit un peu la charge d’exploitation par rapport au serveur unique initial. Ce coût a été jugé largement acceptable au regard du risque écarté.
Ce qui reste vrai même en dehors de ce cas précis
Le risque identifié ici n’est pas propre à la combinaison Stripe, Algolia et Sentry : il s’applique à toute architecture qui agrège plusieurs services sensibles derrière un unique point d’authentification, dès lors que la vérification des scopes n’est pas strictement appliquée à chaque appel d’outil, et non simplement à l’authentification initiale du jeton.
Un serveur MCP qui agrège plusieurs services n’est un problème que le jour où un scope mal accordé transforme un accès théorique en accès réel.
En résumé
Le cumul d’accès à plusieurs services sensibles derrière un même agent n’est jamais une décision explicite : c’est presque toujours une dérive progressive, un scope élargi par commodité qui n’est jamais revenu à sa taille initiale. La performance de cette nouvelle architecture en trois serveurs distincts, elle, n’a montré aucune dégradation notable par rapport à l’ancien serveur unique, ce qui n’était d’ailleurs pas l’objet premier de cette refonte.
