AgentCore préserve les autorisations de l’utilisateur lors des appels à ServiceNow sans échange de jetons personnalisé

Un agent d’IA d’entreprise sait ouvrir un incident dans ServiceNow, mais une question délicate se pose : au nom de qui agit-il ? Si toutes les requêtes arrivent sous le compte technique de l’application, ServiceNow ne voit plus leur véritable initiateur. Le journal d’audit affiche la passerelle à la place de l’employé, les restrictions propres à l’utilisateur ne fonctionnent plus comme prévu et l’agent peut obtenir davantage de droits que nécessaire.

AWS a ajouté à Amazon Bedrock AgentCore Gateway un échange natif de jetons selon le modèle On-Behalf-Of, ou OBO. La passerelle reçoit le jeton de l’utilisateur, contacte Microsoft Entra ID et obtient un autre jeton, cette fois destiné à l’API ServiceNow, tout en restant associé à l’utilisateur d’origine. Il n’est donc plus nécessaire de développer un intermédiaire personnalisé pour effectuer cet échange.

Fonctionnement à travers un exemple simple

Supposons qu’un employé demande à l’agent d’afficher les incidents actifs. L’utilisateur obtient d’abord un JWT destiné à l’application de l’agent. Le champ audience de ce jeton contient l’identifiant de l’agent ; ServiceNow ne l’acceptera donc pas, car le système d’entreprise attend un jeton émis pour son propre connecteur d’API.

L’agent transmet le JWT à AgentCore Gateway. La passerelle l’envoie à Entra ID avec les identifiants de l’application, le scope cible et le paramètre requested_token_use défini sur on_behalf_of. Entra vérifie que la délégation est autorisée, puis émet un nouveau jeton dont l’audience correspond au connecteur ServiceNow, tout en conservant les données de l’utilisateur.

Gateway appelle ensuite l’API REST de ServiceNow. La plateforme fait correspondre le claim preferred_username, par exemple l’adresse e-mail professionnelle, à un compte d’employé existant et applique ses rôles. Si cette personne peut uniquement consulter les incidents, l’agent ne pourra pas non plus les modifier. Le journal conserve une trace claire : l’action est associée à l’utilisateur qui a donné l’instruction.

Configuration nécessaire

Microsoft Entra ID nécessite deux inscriptions d’applications : l’une représente l’agent d’IA et l’autre le connecteur d’API ServiceNow. Le connecteur publie le scope délégué user_impersonation, et l’application de l’agent reçoit l’autorisation de demander ce scope.

Dans ServiceNow, il faut créer une intégration OAuth entrante utilisant Entra comme fournisseur OIDC. Il est essentiel de faire correctement correspondre le claim utilisateur et de limiter l’auth scope aux seules API dont l’agent a réellement besoin. Une passerelle destinée à consulter les incidents n’a, par exemple, aucune raison d’accéder à toutes les tables de la plateforme.

Dans AgentCore, il faut créer une configuration OAuth sortante avec le type d’autorisation JWT authorization grant. Il faut ensuite déployer Gateway avec la version MCP 2025-11-25 : les versions antérieures ne prennent pas en charge le mode OBO natif. Pour la cible REST, on indique le scope du connecteur et le paramètre requested_token_use:on_behalf_of. L’échange s’effectue alors automatiquement à chaque requête.

Sources d’erreur possibles

L’échange natif de jetons ne dispense pas d’une configuration rigoureuse des accès. L’utilisateur indiqué dans preferred_username doit exister dans ServiceNow, l’application de l’agent doit disposer de l’autorisation déléguée et l’auth scope doit autoriser l’endpoint appelé. Une erreur à l’un de ces niveaux entraînera un refus d’autorisation.

La protection contre la réutilisation d’un jeton mérite une attention particulière. Entra transmet le claim interne uti au lieu du claim standard jti. AWS recommande d’envisager de le faire correspondre à jti afin que ServiceNow puisse appliquer une validation supplémentaire et bloquer les jetons. Les guardrails ne remplacent pas non plus l’autorisation : ils filtrent le contenu, tandis qu’OBO détermine si l’utilisateur a le droit d’effectuer l’action.

La conclusion pratique est simple : si un agent interagit avec des systèmes d’entreprise, ne masquez pas tous les utilisateurs derrière un unique compte de service. Propagez l’identité sur toute la chaîne, réduisez le scope aux opérations indispensables et testez séparément les scénarios concernant des employés aux rôles différents. C’est à la frontière entre l’agent et le système métier que se décide si l’automatisation restera maîtrisée ou deviendra une nouvelle faille privilégiée.