Contrôler l'accès des agents IA avec Okta Cross App Access et Amazon Bedrock AgentCore (partie 1)
Okta Cross App Access (XAA) permet de gouverner, depuis le fournisseur d'identité, les agents d'IA qui agissent pour le compte d'utilisateurs, et Amazon Bedrock AgentCore exécute cette décision côté AWS. Dans l'architecture décrite, l'agent est enregistré dans Okta, un administrateur approuve les applications qu'il peut atteindre, et Okta évalue sa politique à chaque demande d'action pour un utilisateur. Lors des tests, après le retrait de l'affectation d'un utilisateur à l'agent, Okta a refusé les nouvelles requêtes en environ une seconde, et les jetons déjà émis ont expiré en moins de cinq minutes. Chaque requête porte trois jetons : le jeton d'identité (ID token) qui désigne l'utilisateur, l'Identity Assertion JWT Authorization Grant (ID-JAG), qui est la décision d'Okta, et le jeton d'accès accepté par la ressource. Le flux commence par la connexion de l'utilisateur via OpenID Connect sur un backend pour frontend (BFF). Ce dernier échange l'ID token contre un ID-JAG auprès d'Okta, en s'authentifiant comme l'agent (RFC 8693). Okta vérifie que l'agent est actif, que l'utilisateur lui est assigné et qu'un administrateur l'a relié au serveur d'autorisation cible. L'ID-JAG, à usage unique, expire en cinq minutes. AgentCore Runtime le valide, puis AgentCore Identity l'échange (RFC 7523) contre un jeton d'accès de cinq minutes nommant l'utilisateur et l'agent, sans que le code de l'agent ne voie les identifiants. Cet ajout représente environ 0,6 seconde sur une requête d'environ 30 secondes.
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 →
L'enjeu est de répondre à une question que le consentement OAuth par application et les comptes de service partagés laissent ouverte : quel agent peut agir pour quel utilisateur, dans quelle application, et comment l'arrêter. Pour les équipes d'identité et de sécurité, la décision est centralisée dans un seul point de contrôle déjà utilisé pour les humains. La révocation d'une affectation dans Okta suffit à couper l'accès de l'agent, sans intervenir application par application. Le jeton final consigne à la fois l'utilisateur et l'agent, ce qui préserve la traçabilité de qui a fait quoi. Les autorisations de chaque utilisateur sont en outre appliquées dans les outils eux-mêmes, de sorte qu'un agent ne dépasse pas les droits de la personne qu'il représente. Le surcoût de latence mesuré reste faible au regard du temps de traitement d'une requête d'agent.
Cet article est la première partie d'une série de deux. Il montre comment construire un agent de tâches sur AgentCore Runtime qui agit pour des utilisateurs connectés via XAA et AgentCore Identity, comment configurer les éléments d'AgentCore Identity nécessaires, et détaille ce que chaque contrôle refuse, les pratiques retenues et la rapidité d'effet des contrôles d'Okta. Okta joue le rôle de plan de gouvernance, tandis qu'AgentCore Identity constitue le plan d'exécution : il détient les identifiants de l'agent et conserve le jeton dans son coffre. Dans l'exemple, l'agent et deux serveurs MCP (Model Context Protocol) tournent tous sur AgentCore Runtime. La seconde partie placera la même gouvernance derrière AgentCore Gateway, avec des politiques Cedar, un second agent sur Amazon EKS et une piste d'audit dans Amazon CloudWatch.
Pas d'impact direct sur la France/UE