Échange de jetons « on-behalf-of » entre ServiceNow et Bedrock AgentCore Gateway
Amazon Web Services détaille comment configurer AgentCore Gateway, une capacité d'Amazon Bedrock AgentCore, pour réaliser un échange de jetons « on-behalf-of » (OBO) avec Microsoft Entra ID. Un agent d'IA peut ainsi appeler l'API REST de ServiceNow en conservant l'identité de l'utilisateur à l'origine de la requête. L'architecture repose sur trois éléments : l'application d'agent, protégée par Entra ID via un enregistrement d'application OAuth, un serveur MCP (Model Context Protocol) implémenté par AgentCore Gateway entre l'agent et ServiceNow, et l'API REST de ServiceNow, dotée d'une intégration OAuth entrante liée à Entra ID. L'utilisateur obtient d'abord un jeton JWT pour invoquer l'agent. Celui-ci s'authentifie auprès de la passerelle avec un jeton dont l'audience correspond à son propre identifiant client. La passerelle l'échange ensuite auprès du point de terminaison de jetons d'Entra, en présentant les identifiants client de l'application d'agent, la portée cible et le paramètre requestedtokenuse: onbehalfof. Entra vérifie que l'utilisateur a consenti à la délégation et émet un nouveau jeton destiné au connecteur API de ServiceNow, avec les revendications de l'utilisateur intactes. ServiceNow fait correspondre la revendication preferred_username à un utilisateur existant et applique ses permissions. L'échange se configure sur la cible de la passerelle, qui l'exécute à chaque requête.
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 la traçabilité et le contrôle d'accès. Sans propagation d'identité, les appels d'un agent arrivent aux services en aval au nom de l'application elle-même. Les pistes d'audit perdent alors leur sens, les contrôles d'accès propres à chaque utilisateur sont contournés et le principe du moindre privilège est violé. Avec l'OBO, un agent ne peut accomplir dans ServiceNow que ce que l'utilisateur est lui-même autorisé à faire, et chaque action reste attribuable à une personne. Pour les entreprises qui déploient des agents sur des systèmes sensibles comme la gestion des services informatiques, cela réduit le risque d'élévation de privilèges involontaire. AWS souligne que le schéma s'applique à toute API REST protégée par OAuth, et recommande en production de le combiner avec Amazon Bedrock Guardrails pour filtrer les contenus nuisibles et valider les entrées et sorties de l'agent.
Cette approche s'inscrit dans la montée en puissance des agents autonomes connectés aux systèmes d'entreprise, où la gestion des identités devient un point de friction majeur. Le flux OBO est un mécanisme éprouvé du monde OAuth, déjà courant entre services Microsoft, qu'AWS adapte à la couche MCP. La mise en œuvre exige deux enregistrements d'application Entra, l'un pour l'agent et l'autre pour le connecteur ServiceNow, un compte AWS avec accès à AgentCore Gateway, un locataire Entra où l'on dispose au minimum du rôle Application Developer, et une instance ServiceNow administrable. Une instance de développeur personnelle gratuite suffit pour tester. Le guide détaille ensuite la configuration d'Entra ID en commençant par l'enregistrement du connecteur API de ServiceNow.
Pas d\'impact direct sur la France/UE