Meilleurs MCP Gateways, Runtimes et Registries pour les agents IA DevOps (2026)

TL;DR : Registries, Gateways et Runtimes

• MCP Registry : Un catalogue pour la découverte et la gouvernance des outils. Utilisez-le pour imposer une liste blanche dans votre chaîne d’approvisionnement logicielle en sélectionnant les outils approuvés.
• MCP Gateway : Une couche de routage pour connecter les modèles aux outils. Idéal pour le développement rapide sur des données non sensibles, généralement via un compte de service partagé unique.
• MCP Runtime : Une plateforme d’exécution sécurisée qui héberge les outils et exécute les actions au nom des utilisateurs authentifiés. À utiliser pour les applications d’entreprise qui nécessitent une autorisation par utilisateur (OAuth/OBO), des credentials en coffre-fort et des journaux d’audit structurés.
• Le risque principal : Utiliser un gateway sans permissions par utilisateur expose du code sensible aux attaques par injection de prompt et aux échecs d’audit de conformité.
• Un déploiement sécurisé exige : Des secrets stockés en coffre-fort hors de la fenêtre de contexte du LLM, et des journaux d’audit compatibles OpenTelemetry reliant chaque action à une identité utilisateur précise.
• Le verdict : Optez pour des runtimes comme Arcade.dev pour des agents multi-utilisateurs agissant sur des systèmes en production ; réservez les gateways aux intégrations simples et peu risquées.

Les responsables engineering en entreprise doivent connecter des modèles comme Claude et ChatGPT à des outils clés tels que GitHub, GitLab et Jira. Sécuriser cette connexion impose soit des serveurs personnalisés, soit d’accorder aux modèles de langage un accès étendu au code propriétaire.

L’écosystème Model Context Protocol s’est développé rapidement, mais le secteur continue de confondre découverte d’outils, routage des requêtes et exécution sécurisée à l’exécution.

Sans standard architectural clair, les équipes platform déploient des connexions fragiles et non sécurisées qui exposent les codebases propriétaires à des attaques par injection.

Ce guide établit une taxonomie 2026 pour l’écosystème, distingue la découverte de l’exécution, et explique pourquoi les charges de travail agentiques en production exigent une infrastructure de niveau Runtime. Traiter un simple gateway comme un runtime sécurisé mène souvent à des échecs de sécurité et d’audit de conformité.

Pourquoi les serveurs MCP maison échouent en production

La plupart des équipes engineering commencent leur parcours agentique avec les implémentations de référence d’Anthropic ou des SDK Python open source. Ces outils fonctionnent bien pour prototyper des workflows en local. Mais dès qu’on les pousse dans un environnement multi-utilisateurs en production, on se heurte à un mur DIY.

La production révèle immédiatement les failles architecturales : risques sévères de fuite de tokens, architectures complexes de rate-limiting entre applications, et absence totale de pistes d’audit d’entreprise.

Par exemple, GitHub applique des limites strictes par points pour son API GraphQL. Les agents IA naïfs coincés dans des boucles de retry épuisent rapidement ces quotas, provoquant des ruptures de quota et des workflows d’agents cassés.

Mais le point de rupture le plus critique reste l’autorisation. Quand vous déployez un serveur personnalisé, vous devez décider comment l’agent s’authentifie auprès des outils backend.

Accorder à un agent une identité générique de compte de service est l’approche standard des gateways. Cette méthode contourne les permissions natives des utilisateurs. Si un agent est compromis via une injection de prompt indirecte, vulnérabilité critique détaillée dans l’OWASP Top 10 for Large Language Model Applications, l’identité partagée crée un rayon d’impact très large. L’injection de prompt se propage dans vos dépôts de code source avec un accès administrateur illimité.

L’alternative ? Tenter d’hériter dynamiquement de l’accès complet d’un utilisateur à chaque requête requiert des flux d’autorisation avec état, une logique de rafraîchissement et un coffre-fort de credentials. Un proxy sans état évalue chaque requête isolément. Il ne peut pas savoir qu’une requête est l’étape 3 d’un workflow en 6 étapes, agissant au nom d’un utilisateur précis qui a autorisé un périmètre particulier il y a quelques minutes. C’est cette conscience de session qui rend l’autorisation par utilisateur et par outil applicable, et les couches sans état ne peuvent pas l’assurer sans une gestion d’état personnalisée conséquente.

Taxonomie MCP (2026) : Registries, Gateways et Runtimes

Pour évaluer l’infrastructure efficacement, vous devez comprendre les frontières fonctionnelles de l’écosystème.

Taxonomie de l’infrastructure MCP : Registries, Gateways et Runtimes (2026)

Catégorie 1 : les registres MCP pour la découverte

Les registres sont des catalogues conçus pour résoudre le problème de découverte des outils. Ils n’hébergent pas, n’autorisent pas et n’exécutent pas les appels. Cette catégorie se divise en deux types :

• Registres publics : Des plateformes servant de catalogues publics interrogeables règlent la découverte initiale des outils, mais n’offrent aucun mécanisme pour gouverner les appels de façon sécurisée.
• Registres d’entreprise : Ces plateformes jouent le rôle de listes d’autorisation dans la chaîne d’approvisionnement logicielle : elles proposent des catalogues internes contrôlés, garantissent que les agents n’utilisent que des serveurs approuvés par l’organisation et bloquent les endpoints publics malveillants. Certains registres ajoutent un contrôle d’accès basé sur les rôles et des journaux d’audit, mais ces fonctionnalités varient selon les éditeurs.

Pour évaluer les registres publics, privilégiez l’étendue du catalogue et la précision des métadonnées. Pour les registres d’entreprise, concentrez-vous sur l’analyse de sécurité, l’application des politiques et l’intégration avec vos outils existants de gestion de la chaîne d’approvisionnement logicielle.

Catégorie 2 : les gateways MCP pour le routage

Des éditeurs de gateways API traditionnels comme Kong et MuleSoft adaptent rétrospectivement le support MCP à des architectures conçues pour du trafic HTTP sans état. Ils comblent l’écart protocolaire en traduisant MCP en HTTP et en appliquant des politiques via des constructions de l’ère HTTP : clés API, limites de débit, ACL d’endpoints. Cette couche de traduction introduit de la latence, perd le contexte de session et ne peut pas appliquer d’autorisation par utilisateur et par outil. Greffer MCP sur une gateway API, ce n’est pas pivoter. C’est colmater.

Les gateways MCP et plateformes d’intégration conçues spécifiquement pour ce cas, comme Composio, Merge et AWS AgentCore, constituent un niveau au-dessus. Elles proposent des intégrations d’outils préconstruites et un routage centralisé pensé pour les workflows d’agents. Mais elles manquent encore de l’intersection de permissions au niveau du runtime requise pour une exécution véritablement par utilisateur, laissant les problèmes de sécurité les plus difficiles sans réponse.

Pour évaluer ces plateformes, concentrez-vous sur trois axes :

• Conformité à la spec et fiabilité : Assurez-vous que les implémentations sont de vrais serveurs MCP conformes à la spécification, et non de simples wrappers API avec une interface MCP. Beaucoup de gateways de première génération tombent dans ce piège et produisent des outils qui hallucinent des paramètres sous des charges de travail concurrentes réelles. La spécification officielle du Model Context Protocol exige une adhésion stricte aux structures de messages (négociation de capacités, handshakes d’initialisation, gestion du cycle de vie), que les wrappers simples ne parviennent pas à maintenir. Des wrappers passant les réponses API brutes sans modification peuvent générer 100 fois plus de tokens que des outils orientés intention pour des requêtes identiques, saturant les fenêtres de contexte et dégradant les performances des agents dans des workflows multi-étapes.
• Support des infrastructures privées : Évaluez si la gateway peut se connecter à des environnements cloud privés ou des déploiements on-premise. Le support des outils développeurs auto-hébergés est souvent limité ou nécessite une configuration réseau complexe pour éviter d’exposer les réseaux internes à Internet.
• Autorisation et politique : La plupart des gateways reposent sur une clé unique ou un compte de service. Elles laissent l’autorisation par utilisateur à la charge de l’acheteur, créant une faille de sécurité majeure dans les environnements multi-tenant.

Catégorie 3 : les runtimes MCP pour l’exécution sécurisée

Les runtimes représentent le niveau le plus élevé de la taxonomie. Ce sont des plateformes d’exécution complètes combinant l’exécution hébergée des outils, des implémentations de serveurs conformes à la spec, une autorisation multi-utilisateurs just-in-time (les credentials ne sont acquis qu’au moment où une action les requiert, limités à l’outil et à l’utilisateur spécifiques, et jamais exposés au LLM ni au client MCP), des credentials mis en coffre, des garde-fous politiques et une gouvernance complète au sein d’un environnement managé unique.

Les runtimes atténuent spécifiquement la menace d’empoisonnement des outils. En isolant les credentials et en n’appliquant les permissions au niveau utilisateur qu’après que le modèle de langage a généré une requête, les runtimes garantissent qu’un agent compromis ne peut pas accéder à de la propriété intellectuelle au-delà des privilèges natifs de l’utilisateur authentifié.

Le modèle d’autorisation applique une intersection stricte des permissions : Agent Permissions ∩ User Permissions = Effective Action Scope. L’agent ne peut exécuter une action que si la politique de rôle de l’agent ET les permissions SaaS natives de l’utilisateur humain l’autorisent explicitement. Toute autre combinaison est refusée.

Prenons un exemple : un agent IA d’entreprise assiste le département des ressources humaines. Un employé utilisant cet agent dispose de privilèges administratifs dans Workday, avec accès aux données de paie mondiales. Mais l’agent RH lui-même est strictement limité aux tâches de recrutement. Lorsqu’il est invité à accéder aux données de paie, le runtime évalue l’intersection au moment de l’appel et refuse la requête. L’utilisateur a l’autorité, mais le périmètre restreint de l’agent bloque l’action. Cela impose le principe du moindre privilège au niveau de la couche agent, bloquant à la fois l’exfiltration de données et les accès non autorisés.

Flux d’autorisation MCP Gateway vs Runtime : identité partagée vs OBO par utilisateur

Comment évaluer les runtimes MCP

• OAuth par utilisateur et RBAC : Un vrai runtime évalue l’intersection des permissions de l’agent et de celles de l’utilisateur appelant pour chaque action, au niveau de la fonction et non du simple outil. Cela signifie autoriser process_claim et get_claim_status tout en bloquant deny_claim pour un utilisateur spécifique, via un agent spécifique, au runtime. Il gère le renouvellement, les incohérences et la rotation des tokens conformément aux spécifications IETF OAuth modernes, en maintenant ces fonctions isolées de la fenêtre de contexte du modèle de langage.
• Support des infrastructures privées : Les runtimes doivent se connecter de façon sécurisée aux serveurs de contrôle de code source auto-hébergés et aux plateformes développeurs internes via des tunnels sécurisés ou du peering, sans les exposer au web ouvert.
• Audit et politique : La plateforme doit produire des logs compatibles OpenTelemetry traçant chaque action, explicitement associée à un utilisateur et un service spécifiques. Elle doit également supporter des hooks politiques pré-appel et post-appel pour valider et intercepter les requêtes risquées en temps réel.
• Fiabilité du runtime : La plateforme doit fournir un contexte d’exécution défini par le développeur pour les nouvelles tentatives intelligentes, l’exécution parallèle des tâches multi-étapes, et le basculement automatique pour gérer les limites de débit et les erreurs réseau transitoires.

Meilleurs gateways, runtimes et registres MCP (top 8)

L’écosystème compte actuellement huit plateformes notables réparties dans la taxonomie définie. Cette matrice de fonctionnalités cartographie chaque plateforme selon les critères d’évaluation essentiels pour les déploiements DevOps en entreprise, permettant aux équipes d’identifier rapidement la meilleure architecture.

Plateforme	Catégorie	Auth par utilisateur	Support infra privée	Fiabilité des outils	Journaux d’audit	Cas d’usage idéal
Arcade	Runtime	Oui (OBO)	Oui (VPC/Secure Tunnel)	Oui (nouvelles tentatives, failover, exécution parallèle)	Oui (OTel)	Équipes prod nécessitant des agents multi-utilisateurs sécurisés sur tout système.
Composio	Gateway	Partiel (OAuth par utilisateur ; pas d’intersection permissions agent/utilisateur)	Oui (Self-hosted)	Limité (pas de sélection de champs ; erreurs nécessitant plusieurs tentatives)	Limité (UI web)	Prototypage et intégration dans des projets.
Merge MCP	Gateway	Partiel (auth par identité ; portée limitée à la catégorie d’intégration)	Limité	Limité (nouvelles tentatives niveau API)	Oui (logs API)	API unifiée pour intégrations SaaS B2B (meilleur en HRIS et recrutement selon G2)
AWS AgentCore	Gateway	Partiel (OAuth sortant ; OBO nécessite une configuration personnalisée)	Oui (AWS uniquement)	Partiel (orchestration personnalisée requise)	Oui (via CloudWatch, travail supplémentaire requis)	Équipes entièrement engagées dans l’écosystème AWS Bedrock.
WorkOS	Auth Sidecar	Oui (SSO/SCIM)	N/A	N/A	Oui (API)	Couche d’identité en complément de gateways de routage personnalisés.
JFrog MCP	Registry	N/A	Oui (Artifactory)	N/A	Oui (Standard)	Liste d’autorisation supply chain pour outils internes approuvés en entreprise.
Smithery	Registry	N/A	Non	Non	Non (stats d’usage)	Découverte publique d’outils open source créés par la communauté.
Anthropic DIY	DIY Code	Non (à construire soi-même)	Oui (build personnalisé)	Non (à construire soi-même)	Non (à construire soi-même)	Implémentations de référence open source et projets personnels.

Arcade.dev (runtime)

Vue d’ensemble : Arcade.dev est un runtime d’exécution conçu spécifiquement pour le Model Context Protocol. Contrairement aux couches de routage sans état, Arcade fonctionne comme un runtime complet qui unifie l’autorisation des agents, un catalogue étendu d’outils optimisés pour les agents, et la gouvernance du cycle de vie dans un seul plan de contrôle. Le runtime parle MCP nativement via le transport Streamable HTTP, sans traduction de protocole ni perte de contexte.

Idéal pour : Les équipes en production qui ont besoin d’agents multi-utilisateurs sécurisés, capables d’agir sur n’importe quel système : du code source et CI/CD aux outils de productivité et aux applications métier.

Points forts :

Arcade se distingue en proposant plus de 8 000 outils optimisés pour les agents avec une autorisation native multi-utilisateurs en juste-à-temps. Ce sont des outils au niveau de l’intention, pas de simples wrappers d’API bruts. Ils absorbent l’ambiguïté d’une requête d’agent et la traduisent en une transaction sûre et prévisible. Quand un utilisateur dit « rends le paragraphe d’intro de mon Google Doc plus chaleureux », les outils d’Arcade identifient le bon segment ID, l’index de caractère et le texte de remplacement. L’agent ne raisonne jamais sur le schéma API sous-jacent. Ce mécanisme évite les boucles d’hallucination de paramètres qui cassent les agents connectés directement à des endpoints REST.

Chaque requête MCP dans Arcade porte deux couches d’identité : une clé au niveau projet (quelle application émet la requête) et une identité au niveau utilisateur (au nom de qui l’action est effectuée). Arcade évalue dynamiquement l’intersection des permissions de l’agent et de l’utilisateur au moment de l’exécution, pour éviter toute escalade de privilèges. Arcade s’intègre aux systèmes d’identité existants en entreprise comme Okta, Entra et SailPoint, acquiert des tokens à portée limitée au runtime et applique les politiques existantes de l’entreprise plutôt que de les dupliquer.

Arcade génère des Journaux d’audit compatibles OpenTelemetry, fournissant l’observabilité nécessaire pour répondre aux exigences de conformité entreprise et relier chaque action à la session utilisateur correspondante. La certification SOC 2 Type 2 d’Arcade valide ces contrôles via un audit indépendant. Le filtrage de visibilité garantit que les agents ne voient que les outils que l’utilisateur actuel est autorisé à invoquer. Le versioning permet aux ingénieurs plateforme de mettre à jour les schémas d’outils et de faire tourner les paramètres de connexion sans perturber les agents en cours d’exécution.

Arcade inclut également son propre MCP Gateway, mais ce n’est pas une couche de routage de catégorie 2. C’est une couche de composition au niveau du runtime qui opère à l’intérieur du périmètre de sécurité du runtime, héritant de toutes ses capacités d’autorisation, de coffre-fort de credentials et d’audit. Elle fédère les outils de plusieurs sources en collections scopées par équipe et par identité. Une entreprise peut créer des Gateways délimitées par équipe ou périmètre de sécurité : l’Engineering obtient GitHub, Linear et les outils de déploiement ; le Sales obtient Salesforce, Gong et les outils email. Chacune est une URL unique utilisable dans n’importe quel client MCP (Cursor, Claude Desktop, VS Code, ChatGPT ou applications custom). Chaque Gateway peut embarquer des instructions LLM, des compétences et du contexte pour aider l’agent à utiliser les outils efficacement. Les équipes peuvent aussi intégrer leurs serveurs MCP existants dans le runtime pour bénéficier de l’autorisation, des tentatives automatiques et des journaux d’audit, sans réécrire ce qui fonctionne déjà.

Contrepartie : Arcade est conçu spécifiquement pour les déploiements multi-utilisateurs en production et gère la complexité infrastructurelle nativement. Pour des projets hobbyistes mono-utilisateur ou des scripts locaux, un runtime complet ajoute une charge inutile.

Composio (gateway)

Vue d’ensemble : Composio est une plateforme d’intégration qui propose une large bibliothèque de connecteurs prêts à l’emploi entre les modèles de langage et les applications tierces.

Idéal pour : Les développeurs qui prototypent des agents ou intègrent des connecteurs tiers dans des projets où la rapidité prime sur la sécurité et la gouvernance.

Points forts : La valeur principale de Composio réside dans sa bibliothèque de connecteurs. Elle réduit le code répétitif nécessaire pour connecter un agent à différents endpoints, en abstrayant la complexité initiale d’intégration pour que les développeurs se concentrent sur le prompt engineering.

Contrepartie : La valeur principale de Composio tient à sa bibliothèque d’intégrations, pas à son architecture de routage. L’étendue de ses connecteurs prêts à l’emploi est son atout. Mais son comportement de logging par défaut peut exposer des payloads sensibles de requêtes et réponses, créant un risque de conformité pour les équipes qui traitent des données personnelles protégées. Dans les benchmarks publiés, l’approche de passthrough API brut de Composio a produit 100x plus de tokens de réponse que le tooling orienté intention pour des requêtes CRM identiques, consommant 373 % d’une fenêtre de contexte de 200K là où Arcade en consommait 3,7 %. À grande échelle, cette surcharge en tokens se traduit par une précision dégradée des agents, des dépassements de fenêtre de contexte dans les workflows multi-étapes, et des différences de coûts significatives. Les données complètes du benchmark sont open source sur github.com/ArcadeAI/attio-mcp-benchmark. Composio manque aussi du contrôle d’accès par rôle granulaire au niveau de l’outil et des interfaces de gouvernance dédiées que l’on trouve nativement dans les vrais runtimes d’exécution.

Merge MCP (gateway)

Vue d’ensemble : Merge apporte son héritage de fournisseur d’intégration unifiée dans l’espace agentique, en proposant un gateway qui mappe ses modèles de données normalisés existants vers des endpoints serveur conformes au protocole.

Idéal pour : Les applications où le défi principal est la fragmentation des données entre catégories SaaS B2B comme les HRIS, le recrutement et la gestion de tickets. Les modèles de données unifiés de Merge offrent une interface propre et normalisée entre les fournisseurs de ces catégories. Si vos agents doivent agir sur ces systèmes avec une autorisation par utilisateur et des pistes d’audit, vous avez besoin d’une couche Runtime que Merge ne fournit pas.

Points forts : Merge excelle dans la gestion d’interfaces unifiées pour les systèmes RH, de tickets et de comptabilité. Si votre agent doit synchroniser des données entre vingt systèmes de suivi des candidatures simultanément, Merge fournit une interface propre et standardisée qui prévient les hallucinations de paramètres.

Contrepartie : Merge n’est pas conçu nativement pour les workflows DevOps ou d’ingénierie cœur de métier. Il manque d’intégration poussée avec les outils CI/CD spécialisés, ce qui le rend moins adapté aux agents conçus pour manipuler du code source, gérer une infrastructure cloud ou résoudre des pull requests complexes dans des VPC isolés.

AWS AgentCore (gateway)

Vue d’ensemble : L’entrée native d’Amazon dans l’écosystème est une plateforme d’infrastructure agent managée avec une couche de routage intégrée qui permet aux développeurs de convertir des services existants et des fonctions serverless en endpoints conformes aux spécifications, en toute sécurité dans leur cloud.

Idéal pour : Les équipes d’ingénierie déjà profondément intégrées et engagées dans AWS Bedrock et l’écosystème Amazon Web Services au sens large.

Points forts : AgentCore offre une intégration native excellente avec AWS CloudWatch pour des métriques de performance détaillées, et utilise IAM pour l’autorisation sortante vers les services natifs AWS. AgentCore gère l’authentification entrante de base via Amazon Cognito et propose un scaling d’infrastructure natif.

Contrepartie : AWS AgentCore entraîne un enfermement extrême dans l’écosystème. AgentCore fonctionne strictement comme un gateway. Il prend en charge des flux d’autorisation basiques, mais construire un runtime multi-utilisateurs cohérent avec une gouvernance fine exige d’assembler Cognito, IAM, CloudWatch et d’autres services, chacun géré, configuré et supervisé séparément. La charge opérationnelle s’accumule à mesure que la complexité des agents croît.

WorkOS (auth sidecar)

Vue d’ensemble : WorkOS n’est pas une plateforme MCP à proprement parler. C’est un sidecar d’identité et d’authentification entreprise que les équipes utilisent pour colmater les failles de sécurité des passerelles de routage basiques.

Idéal pour : Les organisations qui construisent une infrastructure sur mesure et doivent implémenter rapidement le SSO entreprise et la synchronisation d’annuaires.

Points forts : WorkOS offre une infrastructure solide pour la gestion des identités, avec un support complet de SCIM et du provisionnement automatisé. Il permet aux développeurs de déléguer la complexité du cycle de vie utilisateur, de la gestion des sessions et de l’émission des tokens.

La contrepartie : WorkOS étant une couche d’authentification plutôt qu’une plateforme d’exécution, les équipes doivent l’intégrer manuellement à leurs passerelles existantes. Cette intégration alourdit les coûts, la latence et la complexité architecturale. Les développeurs doivent câbler manuellement les tokens du fournisseur d’identité dans leur logique d’exécution pour obtenir une vraie isolation multi-utilisateurs.

JFrog MCP (registre)

Présentation : Loin du routage et de l’exécution, le JFrog MCP Registry est un catalogue dédié à la découverte et à la gouvernance en entreprise. JFrog traite les outils d’agents comme des artefacts logiciels standards, analysables comme n’importe quel autre package.

Idéal pour : Les équipes sécurité et platform engineering qui doivent constituer une liste strictement approuvée d’outils pour les développeurs internes et les charges de travail d’agents.

Points forts : JFrog agit comme une liste d’autorisation critique pour la chaîne d’approvisionnement. Grâce à des contrôles d’accès basés sur les rôles et des journaux d’audit détaillés au périmètre, il permet aux entreprises de constituer un catalogue interne très sélectif, en bloquant les endpoints publics malveillants ou non vérifiés.

La contrepartie : JFrog est uniquement une couche de découverte et de politique. Il ne fournit ni environnement d’exécution, ni couche de routage live. Une fois un outil découvert et approuvé via le registre, les équipes ont encore besoin d’une passerelle ou d’un runtime dédié pour l’invoquer et l’exécuter de façon sécurisée sur des données réelles.

Smithery (registre)

Présentation : Smithery est aujourd’hui le moteur de découverte public de référence de l’écosystème : il fait office de marketplace ouverte pour trouver et distribuer des serveurs construits par la communauté.

Idéal pour : Les développeurs solo, chercheurs et passionnés qui souhaitent trouver rapidement des serveurs communautaires, les expérimenter et les tester en local.

Points forts : Smithery offre une large visibilité sur le front de l’écosystème. Quand une nouvelle API de niche sort, un connecteur communautaire apparaît souvent sur Smithery en quelques jours. C’est l’outil idéal pour prototyper vite, sans friction.

La contrepartie : Smithery est conçu uniquement pour la découverte et l’exécution locale basique. Il manque des mécanismes de gouvernance entreprise, des contrôles d’accès robustes et des processus de vetting sécurité exigés par les équipes corporate. Il ne résout pas les défis d’exécution, de routage ou d’infrastructure sécurisée, ce qui le rend trop risqué à brancher directement sur des workflows de production manipulant des données sensibles.

Serveurs officiels Anthropic et Python SDK DIY

Présentation : Pour les équipes qui préfèrent construire from scratch, Anthropic propose des implémentations de référence open source et des SDK pour des plateformes comme GitHub ou Slack, afin d’illustrer les capacités fondamentales.

Idéal pour : Les architectures très spécialisées et hautement personnalisées, où les plateformes commerciales prêtes à l’emploi ne peuvent pas gérer des protocoles internes propriétaires ou legacy.

Points forts : Construire sa propre infrastructure donne un contrôle total sur chaque octet de données et chaque requête réseau. C’est aussi une excellente base pédagogique pour comprendre en profondeur comment le protocole gère la négociation des capacités et l’échange de contexte.

La contrepartie : La charge d’ingénierie est colossale. Vous êtes responsable de la construction, de la maintenance et du passage à l’échelle de vos propres pipelines d’autorisation multi-utilisateurs, règles de routage, périmètres de sécurité réseau et plomberie d’audit, from scratch. Vous êtes aussi lié à l’écosystème de modèles Anthropic, les serveurs de référence étant conçus pour Claude. Résultat : des coûts de maintenance élevés et une attention d’ingénierie détournée du produit.

Runbook en 5 étapes pour déployer des agents MCP en production

Les déploiements IA entreprise manipulant du code sensible, des données clients ou des systèmes réglementés suivent tous le même chemin en cinq étapes, quelle que soit l’équipe.

1. Cartographiez le rayon d’impact : Identifiez vos systèmes cibles et classifiez la sensibilité des données et actions auxquelles l’agent accédera, avant d’écrire la moindre ligne de code.
2. Choisissez votre architecture : Sélectionnez la catégorie de plateforme appropriée (Registry, Gateway ou Runtime) en vous basant exclusivement sur les référentiels de sécurité et de gouvernance définis à la première étape.
3. Configurez le mapping d’identité : N’utilisez jamais de clés partagées pour les données sensibles. Reliez toutes les actions de l’agent à des identités humaines réelles et vérifiables depuis votre fournisseur d’identité principal, via des flux d’autorisation modernes.
4. Mettez en place un filtrage de visibilité : Appliquez un contrôle strict sur l’accès au catalogue. Les agents ne doivent pouvoir découvrir et invoquer dynamiquement que les outils que l’utilisateur authentifié est explicitement autorisé à utiliser.
5. Testez le failover et les nouvelles tentatives : Vérifiez comment votre plateforme gère les erreurs transitoires, les limites de débit et les défaillances d’outils. Appuyez-vous sur une logique de retry structurée avec backoff exponentiel, plutôt que sur des tentatives illimitées pilotées par le LLM.

Conclusion

Le choix de l’infrastructure dépend de la sensibilité des données, pas d’un compromis universel. Utilisez des registries pour la découverte d’outils publics et des gateways pour router des outils de productivité non critiques. Pour les déploiements IA d’entreprise traitant du code sensible, des données réglementées ou des workflows multi-utilisateurs, les runtimes d’exécution sont la seule option viable.

N’accordez pas à un agent IA un accès illimité à votre compte de service sur vos plateformes de développement. L’injection de prompt est une menace persistante, et les agents surprivilégiés constituent une faille que les attaquants exploiteront.

Si vous construisez des agents multi-utilisateurs et ne pouvez pas vous permettre de fuiter du code source ou de compromettre votre environnement d’ingénierie, explorez Arcade. Arcade offre une autorisation par utilisateur, des outils optimisés pour les agents et une gouvernance du cycle de vie, le tout au sein d’une seule couche runtime.

Vous voulez donner à vos agents un accès sécurisé, par utilisateur, aux outils d’entreprise sans construire l’infrastructure d’authentification from scratch ?

Inscrivez-vous sur Arcade maintenant.

FAQ : MCP Gateways, Runtimes et sécurité

Quelle est la différence entre un MCP Registry, un Gateway et un Runtime ?

Un registry gère la découverte et le catalogage des outils, un gateway route les requêtes (souvent via un compte de service partagé), et un runtime exécute les outils de manière sécurisée avec une autorisation par utilisateur, des secrets en vault et des logs d’audit.

Quand utiliser un MCP Gateway plutôt qu’un MCP Runtime ?

Utilisez un gateway pour les outils à faible risque et le routage rapide avec une identité partagée. Optez pour un runtime quand vous avez besoin d’OAuth/OBO par utilisateur, de RBAC et de logs d’audit OpenTelemetry pour des agents en production.

Les MCP Gateways prennent-ils en charge l’autorisation par utilisateur (OAuth/OBO) ?

La plupart des gateways utilisent par défaut un compte de service partagé et ne fournissent pas de véritable exécution OBO par utilisateur. Si vous avez besoin de permissions appliquées par utilisateur au moment de l’exécution, il vous faut généralement un runtime ou un middleware d’authentification personnalisé conséquent.

Comment empêcher l’injection de prompt d’exfiltrer du code source via les outils ?

Appliquez le moindre privilège par utilisateur, gardez les credentials hors du contexte du modèle et effectuez des vérifications de politique avant et après les appels d’outils. Les runtimes réduisent le rayon d’impact en exécutant les appels d’outils dans les limites des permissions restreintes de l’utilisateur authentifié.

Puis-je exécuter MCP de façon sécurisée dans un VPC ou avec des outils auto-hébergés comme GitHub Enterprise ?

Oui, mais vous avez besoin d’une connectivité privée (tunneling ou peering, par exemple) pour que les services internes ne soient pas exposés publiquement. Préférez les plateformes qui prennent explicitement en charge les infrastructures privées et les architectures réseau d’entreprise.

Quels logs d’audit me faut-il pour des agents IA d’entreprise ?

Vous avez besoin de logs qui enregistrent quel agent a fait quoi, au nom de qui, sur quel système et quand, liés à une identité utilisateur réelle. Les logs compatibles OpenTelemetry sont une exigence courante pour la traçabilité et la gestion des incidents.

Où stocker les secrets dans un setup MCP ?

Les secrets doivent être stockés dans un vault et injectés uniquement au moment de l’exécution. Ne les placez jamais dans les prompts ni dans la fenêtre de contexte du modèle. L’agent doit recevoir le résultat d’une action, pas les credentials bruts utilisés pour l’effectuer. Les runtimes fournissent cette isolation des credentials nativement.

Un « MCP Gateway » est-il simplement une API gateway ?

Pas tout à fait. Les interactions MCP sont souvent multi-tours et avec état, tandis que les API gateways traditionnelles sont optimisées pour des cycles requête-réponse sans état. Si vous utilisez une API gateway, vous aurez généralement besoin d’un middleware supplémentaire compatible MCP.

Puis-je utiliser une API gateway existante pour MCP ?

Pas directement. Les API gateways traditionnelles sont conçues pour des requêtes sans état, alors que MCP est stateful et multi-tours. Il faudrait construire un middleware personnalisé conséquent pour gérer les exigences de MCP en matière de négociation de capacités et d’échange de contexte.

Comment gérer la conformité SOC 2 avec des agents IA ?

Deux choses sont à distinguer. D’abord, votre fournisseur doit détenir la certification SOC 2 Type 2 en tant qu’exigence d’achat d’entreprise, validant ses contrôles internes. Ensuite, le produit lui-même doit générer des logs d’audit structurés enregistrant qui a fait quoi, sur quel système et quand, liés à une identité utilisateur authentifiée. La certification seule ne garantit pas la visibilité et la gouvernance par action dont vous avez besoin. Cherchez des logs compatibles OpenTelemetry avec traçabilité par utilisateur comme fonctionnalité produit, pas seulement comme argument de conformité.

Cela s’applique-t-il au-delà des équipes ingénierie et DevOps ?

Oui. La même architecture s’applique à tout déploiement IA d’entreprise traitant des données sensibles. Les agents RH accédant à Workday, les agents finance accédant aux systèmes comptables et les agents juridiques accédant aux référentiels de contrats nécessitent tous une autorisation par utilisateur, des credentials en vault et des logs d’audit. Les exemples d’ingénierie de ce guide se généralisent directement à tout département où des agents agissent au nom d’utilisateurs authentifiés.