Okta et AgentCore placent les agents IA sous contrôle : révocation de l'accès en 1 seconde

Un agent qui met à jour un ticket ou consulte une fiche client travaille au nom d'une personne, au sein des applications auxquelles celle-ci a accès. Pour l'équipe de sécurité, cela soulève une question embarrassante : quel agent précisément a le droit d'agir pour quel utilisateur, dans quelle application, et comment l'arrêter. Les consentements OAuth accordés application par application et les comptes de service partagés n'y répondent pas. Dans la première partie de son analyse, AWS propose une réponse fondée sur l'association d'Okta Cross App Access (XAA) et d'Amazon Bedrock AgentCore.

Qui est responsable de quoi

La répartition est simple. Okta est le plan de contrôle : il décide quel agent peut agir pour quel utilisateur et sur quelle ressource. AgentCore Identity est le plan d'exécution : il stocke les identifiants de l'agent, transforme la décision d'Okta en un jeton que la ressource acceptera, et y conserve les deux identités, celle de l'utilisateur et celle de l'agent.

Trois jetons interviennent dans chaque requête. Le jeton d'identité (ID token) indique qui est l'utilisateur. L'ID-JAG est la décision d'Okta proprement dite : il est à usage unique et valable 5 minutes. Le jeton d'accès (access token) est celui qu'accepte la ressource cible ; il est lui aussi valable 5 minutes, désigne à la fois l'utilisateur et l'agent, et transporte les groupes de l'utilisateur.

La chaîne se déroule ainsi. L'utilisateur se connecte au frontend (BFF) via OpenID Connect. Le BFF échange son ID token contre un ID-JAG auprès d'Okta selon la RFC 8693, en s'authentifiant en tant qu'agent.

Okta vérifie que l'agent est actif, que l'utilisateur lui est affecté et que l'administrateur a connecté l'agent au bon serveur d'autorisation avec les bons scopes. Le BFF appelle ensuite l'agent dans le runtime AgentCore en transmettant l'ID-JAG comme jeton bearer, et l'autorisateur JWT du runtime n'accepte que les ID-JAG émis par Okta pour cet agent précis. AgentCore Identity échange alors l'ID-JAG contre un jeton d'accès selon la RFC 7523, et l'agent s'en sert pour interroger les serveurs MCP.

Le task manager vérifie que le jeton a été obtenu par un agent enregistré et que le groupe et le scope de l'utilisateur autorisent l'outil concerné.

Les pièges à éviter

Les auteurs énumèrent en toute franchise les écueils sur lesquels ils ont eux-mêmes buté.

Premièrement, Okta rejette la demande d'ID-JAG si elle contient des scopes OpenID Connect tels que openid ou profile (erreur invalid_scope). Il faut au moins un scope personnalisé et aucun scope standard.

Deuxièmement, l'ID token doit provenir de la même application que celle liée à l'agent. Un jeton issu d'une autre application fait échouer l'échange avec une erreur indiquant que le client n'est pas enregistré pour la délégation.

Troisièmement, chaque agent Okta nécessite son propre credential provider : tenter d'utiliser l'ID-JAG d'un agent au nom d'un autre se solde par un refus, en raison d'une discordance de client_id.

Quatrièmement, le SDK stocke le workload access token dans BedrockAgentCoreContext, et non dans les en-têtes de la requête. La première version des auteurs le cherchait dans les en-têtes, ne le trouvait pas et, sur l'ensemble des 21 requêtes testées, basculait sur la voie de secours avec un second workload identity. Le jeton doit être lu depuis le contexte.

Enfin, dans la politique IAM, le segment d'ARN s'écrit oauth2credentialprovider, sans tiret ; avec un tiret, chaque appel échouait avec une AccessDeniedException. Le rôle de l'agent n'a besoin que de deux statements : GetResourceOauth2Token et la lecture du secret du fournisseur.

Chiffres et limites

Après que l'administrateur a retiré l'affectation de l'utilisateur à l'agent, Okta a refusé les nouvelles requêtes en environ 1 seconde, tandis que les jetons déjà émis ont expiré dans un délai de 5 minutes. Le premier appel, avec échange de l'ID-JAG, a pris environ une demi-seconde, et AgentCore Identity a ajouté au total environ 0,6 s à une requête d'une durée d'environ 30 s. Le second appel, vers un autre serveur MCP, a renvoyé le même jeton depuis le stockage en 58 ms en moyenne, sans nouvel échange de l'ID-JAG à usage unique. Un nouvel ID-JAG pour le même utilisateur produit un nouveau jeton, de sorte que chaque requête reflète la décision actuelle d'Okta.

Réserves : le code est un exemple pédagogique, non destiné à la production, et les extraits illustrent un modèle plutôt qu'une solution clé en main. Les tests ont été réalisés sur Okta Integrator gratuit, dans une seule région AWS (Oregon). Le pas-à-pas prend environ une heure. Pour la production, il faut de l'authentification multifacteur (MFA), la rotation du secret (ou Private Key JWT à la place d'un secret partagé) ainsi qu'une validation par les équipes de sécurité et juridiques.

Que faire

Si vos agents accèdent aux systèmes internes via un compte de service partagé, c'est une raison de revoir ce schéma. Déclarez l'agent comme une entité distincte dans l'IdP, limitez les scopes, gardez des jetons de courte durée et vérifiez les droits de l'utilisateur dans les outils eux-mêmes, et pas seulement à l'entrée. La seconde partie promet de traiter la même question avec AgentCore Gateway, les politiques Cedar, un agent sur EKS et l'audit dans CloudWatch.