Pour contrôler l’accès d’un agent IA, le schéma décrit par AWS répartit les vérifications entre Okta, Amazon Bedrock AgentCore Gateway, Cedar et le serveur MCP de l’outil. Okta émet un jeton d’autorisation déléguée ; le Gateway le valide, Cedar décide si l’agent peut utiliser l’outil demandé, puis le serveur vérifie les droits de l’utilisateur. Cette architecture contrôle chaque appel, mais un participant à une discussion technique souligne qu’il faut aussi considérer ce qu’un agent pourrait déduire en combinant plusieurs résultats autorisés. AWS décrit cette architecture et ses essais dans un tutoriel publié le 6 novembre 2026.
Une autorisation par appel vérifie l’action demandée. Pensez aussi aux informations qu’un agent pourrait déduire en combinant plusieurs réponses.
Qui vérifie l’accès d’un agent IA ?
Un ID-JAG est un jeton qui porte une autorisation déléguée. Dans le parcours décrit par AWS, Okta l’émet, l’agent le transmet à son Gateway, puis plusieurs contrôles s’enchaînent avant que l’outil soit appelé.
Le Gateway vérifie l’émetteur, l’audience, le client autorisé et les portées, c’est-à-dire les catégories d’actions permises. Les portées configurées pour la cible doivent correspondre à celles de l’ID-JAG ; l’exemple utilise xaa:read et xaa:write. Cedar, le langage de politiques utilisé dans cet exemple, évalue ensuite si cet agent peut consulter la liste des outils ou appeler un outil précis. Une politique avec autorisations explicites et refus par défaut ne laisse pas passer une action qui n’a pas été permise.
Le contrôle ne s’arrête pas là : le serveur MCP vérifie à son tour les groupes et les portées de l’utilisateur. Cedar décide si l’agent peut appeler l’outil ; le serveur MCP contrôle si cet utilisateur a le droit d’effectuer l’action. AWS attribue ainsi à chaque composant un rôle distinct. Dans ce modèle, chaque agent possède son propre Gateway et son propre fournisseur d’identifiants.
XAA et consentement OAuth individuel
Le choix dépend de la façon dont l’application cible gère l’autorisation. Cross App Access (XAA) convient, dans l’exemple d’AWS, aux cibles dont le serveur d’autorisation accepte les ID-JAG. Pour une application qui possède son propre serveur d’autorisation, comme GitHub dans le tutoriel, le parcours décrit repose sur le consentement OAuth de chaque utilisateur.
| Modèle d’accès | Qui autorise ? | Consentement de l’utilisateur | Comportement rapporté par AWS lors d’une suspension ou d’une révocation |
| XAA avec ID-JAG | Un administrateur Okta détermine quels agents peuvent agir pour quels utilisateurs ; Okta réévalue la politique à chaque demande de jeton. | Pas d’invite de consentement pour l’utilisateur dans l’exemple. | La suspension empêche l’émission de nouveaux ID-JAG. Ceux déjà émis expirent en environ cinq minutes. |
| Consentement OAuth individuel | Chaque utilisateur autorise l’application cible. | L’utilisateur doit connecter son compte et donner son consentement. | Dans l’essai d’AWS, la suspension d’Alice n’a pas invalidé le jeton d’une heure déjà émis ni supprimé l’autorisation enregistrée. Une nouvelle connexion a été refusée ; après la levée de la suspension, l’accès est revenu sans nouveau consentement. La révocation de l’autorisation enregistrée a ensuite empêché l’accès. |
Ces différences sont celles des parcours testés par AWS : elles ne décrivent pas le comportement de toutes les applications. Dans cet essai, le type d’autorisation de la cible déterminait aussi la manière dont une suspension affectait les jetons et les autorisations déjà enregistrés.
Ce qu’AWS rapporte de ses essais
Dans le test d’AWS, l’agent A affichait six outils. La politique Cedar masquait les outils d’écriture de l’agent B, qui en affichait quatre. Le serveur MCP a refusé la création de tâches par Alice et Carol, tandis que Bob a pu en créer une avec l’agent A ; l’agent B ne proposait pas d’outil d’écriture pour Bob. AWS rapporte aussi que l’agent B a rejeté en 98 ms l’ID-JAG destiné à l’agent A, avant tout appel au modèle.
AWS a relevé pendant 24 heures les durées de spans de Gateway A dans CloudWatch Omni. La médiane, ou p50, correspond au point sous lequel se situent la moitié des observations ; le p90, au point sous lequel s’en situent 90 %. Voici les mesures rapportées, en millisecondes :
| Span | p50 | p90 |
Gateway.InboundAuth | 34 | 69 |
Identity.Authorize | 25 | 60 |
Identity.GetWorkloadAccessToken | 48 | 94 |
Identity.GetResourceOauth2Token | 70 | 439 |
Policy.AuthorizeAction par appel | 47 | 56 |
Policy.PartiallyAuthorizeActions par liste d’outils | 65 | 75 |
Gateway.TargetInvocation vers un serveur MCP sur AgentCore | 5 565 | 6 273 |
AWS estime à environ 0,2 seconde, à la médiane, le total des spans d’identité et de politique associés à un appel d’outil. L’invocation de la cible apparaît séparément dans les mesures. Ces chiffres décrivent le déploiement testé par AWS, pas une référence universelle de performance.
Pour le suivi, AWS relie les traces d’AgentCore aux événements du journal système Okta dans CloudWatch ; dans son essai, les événements Okta y arrivaient environ une seconde après leur publication. AWS précise aussi que ses extraits sont conceptuels, ne constituent pas une solution complète prête à déployer et que le code d’exemple est destiné à un usage non productif.
Des résultats autorisés peuvent-ils révéler une information sensible ?
Un participant de r/LLMDevs propose un scénario hypothétique : un outil fournit les totaux de paie par équipe, un autre le nombre de personnes dans chaque équipe. Si une équipe ne compte qu’un membre, le rapprochement de ces deux réponses pourrait révéler son salaire. Le participant suggère d’évaluer la demande combinée dans un outil soumis à une politique, ou d’empêcher la combinaison des résultats.
Ce scénario n’est pas un incident rapporté par AWS. Il met en évidence une question différente du contrôle de chaque appel : une politique peut autoriser séparément deux réponses sans tenir compte de l’information que leur rapprochement rend déductible. Le résultat peut alors révéler le salaire d’une personne dans l’exemple d’une équipe d’un seul membre.
