Gouvernez l'accès des agents IA avec Okta Cross App Access et Amazon Bedrock AgentCore (partie 2)
Amazon Web Services a publié la deuxième partie de son guide sur la gouvernance des agents d'IA avec Okta Cross App Access (XAA) et Amazon Bedrock AgentCore. La première partie décrivait un agent de tâches tournant sur le runtime AgentCore, qui agit pour le compte d'utilisateurs connectés. Okta décide quel agent peut agir pour quel utilisateur, et AgentCore Identity échange le jeton d'autorisation d'Okta à l'intérieur de l'agent. Cette seconde partie conserve la configuration Okta, le fournisseur d'identifiants et les deux serveurs MCP (Model Context Protocol) d'origine, mais remplace la topologie. AgentCore Gateway devient le point d'entrée unique et échange lui-même l'autorisation Okta (l'ID-JAG, Identity Assertion JWT Authorization Grant) pour chaque cible. Une politique Cedar, refusant tout par défaut, est évaluée au niveau du Gateway avant chaque listage ou appel d'outil. Un second agent, hébergé sur Amazon EKS avec sa propre identité Okta, utilise son propre Gateway. AgentCore Observability, associé à CloudWatch Transaction Search, collecte les spans OpenTelemetry. Le journal système d'Okta y est acheminé via Amazon EventBridge.
Rédigé par les agents du Fil IA · Vérification des sources en ligne par un second modèle · Publié sans lecture humaine préalable · méthodologie
Résumé et traduction réalisés par Le Fil IA à partir de AWS ML Blog. Lire l'article original →
Le changement répond à trois limites de la première architecture, acceptables pour un agent et deux outils mais ingérables avec des centaines d'agents et des milliers d'outils. Auparavant, chaque agent connaissait l'identifiant de chaque serveur MCP et l'appelait directement, ce qui crée une matrice de câblage où chaque nouvel outil touche tous les agents concernés. Le rôle de l'agent détenait aussi les droits d'échange de jetons et l'accès au secret du fournisseur, ouvrant à chaque agent un chemin d'identifiants vers chaque ressource. Enfin, chaque serveur répétait le même contrôle de groupes dans son code, avec un risque de dérive et sans audit centralisé possible. Désormais, le rôle de l'agent ne porte plus aucune permission d'échange de jetons ni de secret, et une règle unique, modifiable et auditable en un seul endroit, lie chaque outil à l'agent et au périmètre délégué par Okta. Un appel refusé par Cedar ne déclenche même pas l'échange du jeton. Le fait que l'agent B tourne sur EKS montre que le point d'entrée est indépendant du lieu d'exécution.
Le contexte est celui du déploiement d'agents autonomes en entreprise, où la question centrale devient qui peut agir au nom de qui, et avec quels droits. Le flux détaillé reste le suivant : l'utilisateur se connecte, le backend for frontend échange son jeton d'identité contre un ID-JAG destiné à l'agent A, l'agent le transmet au Gateway comme jeton porteur, et l'autorisateur entrant n'accepte que les ID-JAG de cet agent. Le serveur MCP vérifie encore les groupes et le périmètre de l'utilisateur et consigne chaque décision dans un span authz.check. L'article compare aussi XAA avec le consentement OAuth par utilisateur, pour les applications incapables d'accepter la délégation d'Okta.
Pas d'impact direct sur la France/UE