Contrôler l'accès des agents IA aux outils avec Amazon Bedrock AgentCore Gateway
L'équipe Amazon Web Services a détaillé dans un billet technique récent le fonctionnement d'Amazon Bedrock AgentCore Gateway, un service conçu pour centraliser l'accès des agents IA aux outils internes des entreprises. Le point de départ est concret : un ingénieur infrastructure ouvre l'ordinateur d'un collègue pour déboguer un build et découvre, dans un fichier de configuration nommé mcp.json, un mot de passe de base de données de production stocké en clair, accompagné d'un commentaire « TODO: rotate this ». Ce scénario illustre le problème que vise à résoudre AWS avec des assistants compatibles Model Context Protocol (MCP) comme Kiro, Claude Code, Cursor ou Amazon Quick. La solution proposée repose sur plusieurs briques : AgentCore Gateway comme point d'entrée unique et sécurisé, AgentCore Identity pour l'authentification et la gestion des identifiants, AgentCore Policy pour l'application de règles de sécurité, Amazon Bedrock Guardrails pour les contrôles de sécurité et de confidentialité, et AWS Agent Registry comme catalogue centralisé d'outils. Des alternatives auto-hébergées existent également, comme Kong Gateway, Open Policy Agent, NeMo Guardrails ou LangFuse.
Résumé et traduction réalisés par Le Fil IA à partir de AWS ML Blog. Lire l'article original →
Cette annonce répond à un risque de sécurité de plus en plus tangible à mesure que les agents IA se multiplient dans les organisations. AWS identifie cinq failles structurelles récurrentes dans les déploiements MCP en entreprise : la dispersion des identifiants, la dérive des politiques de sécurité, les angles morts d'audit, l'opacité des coûts et le « shadow IT ». L'exemple chiffré donné est parlant : une équipe utilisant dix assistants IA connectés à cinq API internes doit gérer manuellement cinquante jeux d'identifiants distincts, et la moindre modification de politique de sécurité doit être répliquée dans les cinquante configurations. Résultat, la plupart des équipes de sécurité sont aujourd'hui incapables de répondre en moins d'une minute à une question pourtant basique : quels agents ont accès aux données clients, qui leur a accordé cet accès, et quelle serait l'ampleur des dégâts si un identifiant venait à fuiter.
Plutôt que de recommander la construction d'une passerelle de sécurité complète avant tout déploiement d'IA, ce qui prendrait des mois et aboutirait souvent à une solution mal calibrée, AWS propose une montée en maturité progressive en plusieurs étapes. La première, baptisée « Connect », instaure une porte d'entrée unique avec authentification SSO, centralisation des identifiants et journalisation via AWS CloudTrail. La seconde, « Control », introduit des politiques d'accès basées sur les rôles et attributs via le moteur Cedar, la suppression de données personnelles sensibles, ainsi que des mécanismes de consentement et d'enregistrement dynamique des clients. La troisième étape, « Catalog », permet aux équipes de publier et découvrir des outils en libre-service, y compris ceux hébergés sur site. Cette approche par étapes reflète un enjeu plus large : à mesure que le protocole MCP s'impose comme standard de connexion entre agents IA et systèmes d'entreprise, la gouvernance de ces accès devient un chantier prioritaire pour les équipes de sécurité, bien au-delà du seul écosystème AWS.
Les entreprises europeennes utilisant Amazon Bedrock pourraient s'appuyer sur cette gateway pour securiser leurs deploiements d'agents IA, sans impact reglementaire direct.