Mettre à l’échelle la gouvernance des agents IA avec AWS Bedrock AgentCore et Okta

Amazon Web Services a publié la deuxième partie d’un guide technique détaillant la mise à l’échelle des opérations sécurisées des agents IA. Publié le 6 novembre 2026, cet article explique comment remplacer les connexions directes entre agents et outils par une architecture de passerelle centralisée. Cette approche utilise Amazon Bedrock AgentCore, Okta Cross App Access et les moteurs de politique Cedar pour gérer les autorisations sur des centaines d’agents et d’outils.

Ce qui s’est passé

Dans la première partie de cette série, les ingénieurs ont construit un agent mono-tâche agissant au nom des utilisateurs connectés. Cette configuration initiale reposait sur une topologie réduite où l’agent détenait les adresses d’exécution des serveurs Model Context Protocol (MCP) et effectuait directement les échanges de jetons. Bien que fonctionnel pour les scénarios de preuve de concept, cette méthode crée une matrice de câblage complexe à mesure que les systèmes évoluent. Chaque nouvel outil nécessite des mises à jour de tous les agents ayant besoin d’y accéder, et chaque agent doit détenir des identifiants pour chaque ressource potentiellement accessible.

Le nouveau guide répond à ces limites d’évolutivité en introduisant Amazon Bedrock AgentCore Gateway comme point d’entrée unique. Au lieu d’appeler directement les outils, les agents acheminent leurs requêtes via la Gateway. Ce composant gère la rédemption d’identité et applique les politiques d’accès avant toute invocation d’outil. La mise à jour introduit également un second agent exécuté sur Amazon Elastic Kubernetes Service (Amazon EKS) afin de démontrer que le modèle de gouvernance fonctionne indépendamment de l’hébergement de l’agent. Ce changement transfère la logique de sécurité des serveurs individuels vers un moteur de politique centralisé, réduisant ainsi la duplication de code et la complexité d’audit.

Fonctionnement

L’architecture repose sur la Gateway AgentCore, qui accepte une Identity Assertion JWT Authorization Grant (ID-JAG) émise par l’agent. Ce jeton prouve que l’utilisateur a autorisé l’agent à agir. L’autoriseur entrant de la Gateway valide que le jeton a été spécifiquement émis pour cet agent par Okta. Une fois validé, la Gateway consulte un moteur de politique basé sur Cedar. Ces politiques définissent précisément quels outils un agent peut utiliser en fonction de son identité et des scopes accordés par l’utilisateur. Si la politique autorise l’action, la Gateway utilise AgentCore Identity pour échanger l’ID-JAG contre un jeton d’accès à scope restreint auprès d’Okta.

Ce processus garantit que les agents ne manipulent jamais d’identifiants secrets ni n’effectuent eux-mêmes d’échanges de jetons. Le rôle d’exécution de l’agent n’a plus besoin d’autorisations pour l’échange de jetons ou la lecture de secrets. À la place, la Gateway détient ces privilèges. Les serveurs MCP continuent d’effectuer des vérifications finales sur les groupes d’utilisateurs, mais la décision d’autorisation principale est prise au niveau de la Gateway. Cette séparation permet aux organisations de mettre à jour les règles d’accès en un seul endroit plutôt que de modifier le code sur des milliers de serveurs. Toutes les décisions sont journalisées sous forme de spans OpenTelemetry, offrant une piste d’audit complète.

Détails clés

• Gateway centralisée : Les agents se connectent à un endpoint unique de la Gateway au lieu de gérer des connexions directes à plusieurs serveurs MCP, simplifiant ainsi la topologie réseau.
• Moteur de politique Cedar : Le contrôle d’accès est défini à l’aide de politiques Cedar qui lient des outils spécifiques aux agents et aux scopes, appliquant une posture par défaut « deny ».
• Externalisation de l’échange de jetons : La Gateway effectue la rédemption des grants Okta pour obtenir des jetons d’accès, supprimant le besoin pour les agents de détenir des permissions d’identifiants ou des secrets.
• Support multi-environnements : La solution prend en charge les agents exécutés à la fois sur le runtime Bedrock AgentCore et sur Amazon EKS, en utilisant des méthodes cohérentes de vérification d’identité.
• Observabilité unifiée : AgentCore Observability collecte les traces issues des composants Gateway, Policy et Identity, qui peuvent être jointes aux System Logs d’Okta dans Amazon CloudWatch.
• Schémas d’outils statiques : Les cibles doivent utiliser des schémas d’outils statiques pour garantir la stabilité des références de politique, car les listes dynamiques peuvent compliquer l’application des politiques.

Pourquoi c’est important

Pour les équipes logicielles développant des applications IA d’entreprise, l’évolutivité de la sécurité constitue un goulet d’étranglement majeur. Gérer les permissions pour des dizaines d’agents et des centaines d’outils devient rapidement ingérable si chaque agent maintient sa propre logique de connexion. En centralisant l’autorisation, les organisations peuvent réduire le risque de dérive de configuration. Les équipes de sécurité peuvent auditer et mettre à jour les politiques en un seul emplacement, garantissant que les modifications s’appliquent de manière cohérente à tous les agents. Ce modèle minimise également la surface d’attaque, car les agents ne stockent plus d’identifiants sensibles ni ne disposent de permissions étendues pour échanger des jetons.

L’intégration avec les outils d’observabilité offre une visibilité cruciale sur le comportement des agents. Dans les secteurs réglementés, il est essentiel de pouvoir prouver qui a autorisé une action et quand. La capacité de joindre les événements de grant Okta aux traces d’exécution détaillées dans CloudWatch permet aux ingénieurs de reconstituer le contexte complet de toute action d’agent. Ce niveau de transparence aide les équipes à déboguer les problèmes d’autorisation et à satisfaire les exigences de conformité sans devoir construire une infrastructure de journalisation personnalisée depuis zéro.

Actions recommandées

• Examiner le code d’exemple : Étudiez l’exemple AWS 08-okta-xaa-delegation-chain sur GitHub pour comprendre l’architecture de base avant d’ajouter les composants Gateway.
• Implémenter la Gateway : Configurez une AgentCore Gateway avec un autoriseur entrant qui valide les ID-JAG provenant de votre serveur d’autorisation Okta.
• Définir les politiques Cedar : Rédigez des politiques uniquement en mode « permit » qui associent les client IDs des agents et les scopes à des actions d’outils spécifiques, assurant une posture par défaut « deny ».
• Configurer l’observabilité : Activez CloudWatch Transaction Search et configurez Okta Log Streaming vers EventBridge pour créer une vue d’audit unifiée.
• Tester les agents multi-environnements : Déployez un agent secondaire sur Amazon EKS pour vérifier que la Gateway traite correctement les identités provenant de l’extérieur du runtime Bedrock.
• Valider les scopes des jetons : Assurez-vous que les scopes demandés par la Gateway correspondent à ceux présents dans l’ID-JAG afin d’éviter les échecs d’échange de jetons.