Comment Eon a construit une investigation multi-cloud avec une passerelle MCP sur Amazon Bedrock AgentCore

Ceci est un article invité rédigé en collaboration avec Roei Zavida d'Eon.

Les éditeurs de logiciels indépendants (ISV) qui créent des produits propulsés par l'IA doivent connecter des agents et des humains à des dizaines d'outils opérationnels répartis sur plusieurs clouds, chacun avec des modèles d'authentification, des limites réseau et des politiques d'accès différents. Lorsque ces outils couvrent simultanément AWS, GCP et Azure, la surface d'intégration se multiplie.

Cet article décrit comment Eon a utilisé Amazon Bedrock AgentCore, une plateforme pour construire, connecter et optimiser des agents à grande échelle, avec n'importe quel framework ou modèle. Eon l'a utilisé pour remplacer les identifiants par outil et les processus Model Context Protocol (MCP) locaux par une seule passerelle authentifiée. Le résultat donne aux développeurs et aux agents autonomes un accès unifié aux outils d'investigation sur trois clouds. Les nouveaux ingénieurs accèdent désormais à tous leurs outils d'investigation en environ deux minutes au lieu des deux jours qu'il fallait auparavant pour configurer les identifiants et les serveurs MCP locaux.

À propos d'Eon

Eon fournit l'Autonomous Data Foundation pour l'ère de l'IA. La plateforme découvre et classifie les ressources cloud sur AWS, Azure et GCP. Elle offre une sauvegarde continue dédupliquée qui réduit les coûts de stockage jusqu'à 50 pour cent selon les mesures internes d'Eon. Elle détecte également les dommages causés par les ransomwares et les agents malveillants et fournit un contexte vivant et vérifié pour les agents d'IA. Tout cela fonctionne à partir d'un seul rôle AWS Identity and Access Management (IAM) en lecture seule, avec des données stockées aux formats Apache Parquet et Apache Iceberg. Fondée par d'anciens ingénieurs d'AWS, Eon exécute son infrastructure de logiciel en tant que service (SaaS) sur AWS.

Le défi

L'équipe d'ingénierie interne d'Eon investigue les incidents de production sur plusieurs clouds et des dizaines de systèmes opérationnels. Un pod Kubernetes planté nécessite de vérifier les journaux de conteneurs, les métriques Grafana, la pull request (PR) GitHub du déploiement et l'état de santé du fournisseur cloud dans la même session.

Eon devait répondre à plusieurs exigences clés :

• Consolidation des identifiants — Chaque nouvel outil ajoutait une intégration supplémentaire à configurer, sécuriser et faire tourner, ce qui devenait plus difficile à maintenir de manière cohérente à mesure que l'ensemble d'outils grandissait.
• Éliminer les processus MCP locaux — Chaque développeur exécutait plusieurs serveurs MCP localement, ce qui était difficile à standardiser et à maintenir à jour.
• Séparation des identités — Les ingénieurs accédaient à chaque système avec des autorisations basées sur les rôles, mais il n'existait aucun endroit unique pour décider quels outils chaque personne ou agent pouvait appeler.
• Accès inter-comptes sans surcharge réseau — L'hébergement de serveurs MCP sur plusieurs comptes AWS nécessitait du peering de cloud privé virtuel (VPC) ou AWS PrivateLink par compte, multipliant les coûts opérationnels et le temps de configuration.
• Intégration des développeurs — Les nouveaux ingénieurs passaient environ 2 jours à configurer les identifiants et les serveurs MCP locaux avant d'investiguer leur premier incident.
• Accès des agents — L'agent autonome d'ingénierie de fiabilité des sites (SRE) d'Eon (exécutant Claude sur Amazon Bedrock) avait besoin du même accès aux outils que les humains, mais avec des autorisations différentes.

La croissance des effectifs d'ingénierie combinée à un ensemble d'outils et de MCP d'IA en expansion rapide rendait la maintenance des identifiants et des serveurs MCP locaux de plus en plus coûteuse. Cela a poussé Eon vers une solution centralisée.

Approches envisagées

Avant de construire sur AgentCore, Eon a évalué des alternatives :

Option 1 : Proxy centralisé avec authentification personnalisée

Chaque harness avait sa propre configuration de proxy avec toutes les cibles. Un seul reverse proxy agrégeant tous les outils, avec une couche d'authentification personnalisée. Cela permettait la consolidation des identifiants, mais ne prenait en charge que le MCP distant et nécessitait de construire et maintenir la traduction des protocoles d'outils, la gestion des sessions et la logique d'autorisation à partir de zéro. La charge de mise en œuvre et de maintenance était considérable.

Option 2 : Amazon Bedrock AgentCore Gateway

Amazon Bedrock AgentCore Gateway, une capacité d'Amazon Bedrock AgentCore, est une passerelle gérée avec fédération d'identité intégrée, politiques d'autorisation basées sur Cedar, et hébergement Runtime qui convertit les serveurs MCP locaux en points de terminaison HTTP distants. Cela répondait à toutes les exigences sans infrastructure personnalisée.

Eon a choisi l'Option 2 parce qu'elle offrait la séparation des identités, la connectivité inter-comptes et l'application des politiques en tant que capacités gérées plutôt que du code qu'ils devraient construire et maintenir. C'étaient les deux seules options sur la table.

Présentation de la solution

Eon a déployé la pile complète d'Amazon Bedrock AgentCore : AgentCore Gateway, Policy dans Amazon Bedrock AgentCore, AgentCore Runtime et AgentCore Identity, toutes des capacités d'Amazon Bedrock AgentCore. Le diagramme suivant montre comment les requêtes des clients transitent par la couche d'authentification vers une passerelle unique. La passerelle achemine les appels d'outils autorisés vers des cibles hébergées sur des AgentCore Runtimes répartis sur plusieurs comptes AWS.

Figure 1 : architecture de passerelle centralisée d'Eon sur Amazon Bedrock AgentCore

L'architecture comporte cinq couches :

Clients

Les développeurs utilisant Claude Code, Cursor ou OpenAI Codex se connectent à une seule URL MCP. Un agent SRE autonome exécutant Claude sur Amazon Bedrock se connecte à la même passerelle avec une identité différente.

Plan d'identité

L'authentification unique (SSO) d'entreprise est fédérée via Amazon Cognito, qui génère le JSON Web Token (JWT) et le remet à la passerelle. Amazon API Gateway se trouve en première ligne comme point d'entrée OAuth pour les humains, en proxifiant la session MCP. Les agents s'authentifient auprès de Cognito client_credentials avec des octrois directement contre la passerelle.

Une seule passerelle, accès aux privilèges minimaux

Une seule AgentCore MCP Gateway sert de porte d'entrée à l'échelle de l'entreprise. Des stratégies Cedar en mode ENFORCE contrôlent quels principaux peuvent invoquer quels outils. Les opérations de lecture sont disponibles pour des groupes sélectionnés, et non pour chaque utilisateur authentifié. Les opérations d'écriture sont limitées aux actions de collaboration à faible impact, comme commenter une PR ou un ticket, et les outils de production sont en lecture seule.

Stratégie dans Amazon Bedrock AgentCore

Les stratégies Cedar associent chaque principal aux outils autorisés. Les opérations d'écriture sont limitées aux actions de collaboration à faible impact, comme commenter une PR ou un ticket, et les outils de production sont en lecture seule. La passerelle évalue chaque tools/call requête par rapport à Cedar avant de la transmettre à la cible.

Cibles

Des dizaines de serveurs MCP cibles exposant des centaines d'outils sur une seule passerelle, servis par des AgentCore Runtimes répartis sur plusieurs comptes AWS. Chaque Runtime convertit les serveurs MCP locaux basés sur stdio en points de terminaison Streamable HTTP accessibles via la passerelle.

Un développeur ouvre son environnement de développement intégré (IDE), configure une seule URL MCP, s'authentifie via le SSO d'entreprise, et la passerelle agrège des centaines d'outils en une seule tools/list réponse. Aucune configuration locale et aucun jeton par outil.

Séparation de l'identité et de l'accès

La décision de sécurité centrale consistait à appliquer des limites de lecture et d'écriture au moyen de stratégies Cedar au niveau de la passerelle.

Passerelle unique, séparation appliquée par stratégie :

La passerelle accepte à la fois les jetons JWT (humains via le SSO d'entreprise et Cognito) et les client_credentials jetons (agents). Les stratégies Cedar déterminent ce que chaque principal peut faire. Les humains des groupes approuvés obtiennent un accès en lecture. Les opérations d'écriture nécessitent des autorisations Cedar explicites accordées uniquement à des identités d'agents spécifiques.

Cedar renforce la granularité par outil :

// Agent "sre-bot" can add comments on GitHub PRs
permit(
    principal == Agent::"sre-bot",
    action == Action::"tools/call",
    resource == Tool::"github_add_pr_comment"
);

// No human principal can invoke mutation tools
forbid(
    principal in Group::"humans",
    action == Action::"tools/call",
    resource in ResourceGroup::"write-tools"
);

Les stratégies Cedar sont gérées comme du code via des PR GitHub avec des commentaires de révision, offrant à l'équipe un contrôle de version et une piste d'audit pour chaque modification d'autorisation.

Au sein de la passerelle, les stratégies Cedar délimitent l'accès aux outils par groupe SSO, et les groupes correspondent aux rôles professionnels. Les ingénieurs ont par défaut accès aux environnements de développement et de test. L'accès à la production suit les contrôles de sécurité et de conformité d'Eon : il est en lecture seule, accordé juste-à-temps via un processus d'approbation, et audité. Le groupe d'un nouveau membre de l'équipe est délimité de la même manière, par rôle plutôt que selon le service qu'il possède par hasard. Parce que chaque action d'agent est vérifiée par rapport à Cedar en mode ENFORCE et délimitée à un ensemble d'outils aux privilèges minimaux, l'agent autonome opère dans des limites sûres et bornées. Il ne peut invoquer que les outils spécifiques que son identité est explicitement autorisée à appeler.

« Avant, notre agent interne ne pouvait pas accéder aux mêmes outils d'investigation que ceux utilisés par les développeurs. Après, il utilise la même Gateway avec sa propre identité et un ensemble d'outils plus restreint. »

— Roei Zavida, Senior DevOps Engineer, Eon

Connectivité inter-comptes

Eon exécute des Runtimes sur plusieurs comptes AWS, organisés par environnement ou par frontière de service. AgentCore Gateway atteint chaque Runtime via l'assomption de rôle IAM inter-comptes. Le Runtime du compte B fait confiance au rôle d'exécution d'AgentCore Gateway du compte A au moyen d'une stratégie de confiance IAM standard.

Ce que cela a éliminé :

• La configuration de l'appairage VPC et la gestion des tables de routage sur plusieurs comptes AWS.
• Les coûts des points de terminaison PrivateLink par compte.
• La coordination des groupes de sécurité entre comptes.
• Des jours de configuration par nouveau compte (remplacés par une seule stratégie de confiance IAM, déployable en quelques minutes).

Modèles d'attachement des cibles :

Selon le modèle d'authentification et d'hébergement de chaque outil, Eon utilise deux modèles d'attachement principaux. Le tableau suivant résume quand utiliser chaque modèle et en donne un exemple.

La plupart des cibles utilisent Runtime + IAM. Eon se contente d'envelopper un MCP distant pour réduire son catalogue ou insérer un identifiant que la passerelle ne peut autrement fournir.

Déroulement de la session d'enquête

Le flux suivant retrace l'enquête d'un développeur sur un incident en production :

1. Authentification. Le développeur ouvre Claude Code (ou Cursor/Codex) et se connecte à l'URL MCP de la passerelle. L'IDE initie OAuth via le SSO d'entreprise. Cognito émet un JWT portant l'identité du développeur et ses appartenances aux groupes.
2. Découverte d'outils. La passerelle agrège `tools/list` provenant de dizaines de cibles connectées et renvoie un manifeste unifié de centaines d'outils à l'IDE. Le développeur voit tous les outils d'investigation disponibles dans une seule liste.
3. Invocation d'outil. Le développeur demande : « Montre-moi le pic de taux d'erreur du service de paiements sur la dernière heure. » L'agent de l'IDE sélectionne l'outil de requête Grafana et envoie une requête `tools/call`.
4. Évaluation des politiques. La passerelle évalue la requête à l'aide de Cedar. L'appartenance du développeur au groupe lui accorde l'accès à l'outil Grafana. La requête est acceptée.
5. Exécution à l'exécution. La passerelle transfère la requête vers le Runtime hébergeant le serveur MCP de Grafana (exécuté dans un compte AWS distinct). Le Runtime s'authentifie auprès de Grafana à l'aide d'une information d'identification de service stockée dans le coffre AgentCore Identity, exécute la requête et renvoie les résultats.
6. Corrélation entre outils. L'agent effectue ensuite le suivi en vérifiant le statut du déploiement Kubernetes et la pull request GitHub associée, chacun étant acheminé vers des Runtimes différents. Le développeur voit des résultats corrélés sans changer d'outils ni se réauthentifier.

Leçons apprises à grande échelle

Le déploiement auprès de plus de 100 développeurs et d'environ 10,000 sessions a mis en évidence des défis de production :

Gestion de la taille des politiques Cedar

Chaque schéma d'outil que la passerelle pré-indexe contribue à la taille de la politique Cedar. Avec des dizaines de cibles exposant des manifestes d'outils étendus, la politique d'Eon a approché le quota de taille. La solution : le mode de listage DYNAMIC pour les cibles comptant un grand nombre d'outils. En mode DYNAMIC, la passerelle transfère les tools/list appels vers le serveur MCP au moment de la requête au lieu de pré-indexer les schémas, n'ajoutant aucun octet à la politique.

Le compromis est que la recherche sémantique d'outils n'est pas disponible pour les cibles DYNAMIC. Eon utilise une configuration hybride : le mode DEFAULT pour les cibles nécessitant un OAuth par utilisateur (petit nombre d'outils, schémas pré-indexés requis pour le flux de consentement) et le mode DYNAMIC pour les cibles à grand catalogue.

Liaison de session OAuth pour les clients MCP standards

Claude Code, Cursor et Codex attendent le paramètre OAuth state pour la protection contre la falsification de requête intersites (CSRF). AgentCore utilise la liaison par URI de session. Eon a construit un shim Amazon API Gateway qui traduit entre les deux protocoles afin que les clients MCP standards puissent compléter le flux OAuth sans modification.

Filtrage des surfaces d'outils

Certains serveurs MCP exposent des centaines d'outils. Les développeurs individuels n'ont besoin que d'un sous-ensemble pour leur service. Eon a construit un wrapper Runtime qui filtre le manifeste d'outils au niveau du Runtime, réduisant le bruit dans les tools/list réponses et empêchant l'invocation accidentelle d'opérations non pertinentes. Cette approche permet également de conserver ces cibles en mode DEFAULT, préservant la recherche sémantique et les fonctionnalités embarquées que le mode DYNAMIC sacrifie.

Résultats

L'architecture à passerelle unique est utilisée en production par l'équipe d'ingénierie interne d'Eon depuis plusieurs mois. Le résultat le plus manifeste concerne l'intégration des développeurs. La configuration de l'accès à l'ensemble des outils est passée d'environ deux jours de configuration d'identifiants et de serveurs MCP locaux à environ deux minutes. Un nouvel ingénieur connecte une seule URL de passerelle, s'authentifie via le SSO d'entreprise et voit immédiatement les outils autorisés par son rôle.

L'agent interne représente la majeure partie du temps gagné, car il accède à davantage de contexte via la passerelle, ce qui améliore la précision des investigations. Les ingénieurs économisent le temps auparavant consacré à la configuration des outils d'IA, puisqu'ils n'ont qu'à se connecter à l'URL de la passerelle.

Eon étudie comment ces mêmes modèles peuvent prendre en charge des capacités d'IA dans son propre produit.

« AgentCore nous a fourni une seule passerelle MCP authentifiée au lieu de jetons par outil et de processus MCP locaux. Les développeurs et notre agent interne accèdent désormais à Kubernetes, Grafana, GitHub et à nos comptes cloud depuis une seule URL. »

— Roei Zavida, Senior DevOps Engineer, Eon

Conclusion

Cet article a décrit comment Eon a remplacé les identifiants par outil et les processus MCP locaux par une seule passerelle MCP Amazon Bedrock AgentCore. Il en résulte une séparation des identités basée sur Cedar, une connectivité inter-comptes sans peering VPC et un accès unifié aux outils pour plus de 100 développeurs et agents autonomes répartis sur trois clouds. L'architecture à passerelle unique, l'application du moindre privilège avec Cedar et le mode de politique hybride DEFAULT et DYNAMIC sont des modèles réutilisables pour les ISV qui connectent des agents et des développeurs à des outils sur plusieurs clouds.

Pour en savoir plus sur le développement avec Amazon Bedrock AgentCore, consultez ces ressources :

• Documentation d'Amazon Bedrock AgentCore Gateway.
• Documentation d'Amazon Bedrock AgentCore Runtime.
• Atelier Getting Started with Amazon Bedrock AgentCore.

À propos des auteurs