ServiceNow on-behalf-of token exchange with Bedrock AgentCore Gateway

AI agents that interact with enterprise APIs on behalf of users need to maintain user identity throughout the request chain. Without identity propagation, API calls arrive at downstream services as the application itself rather than the user who initiated the action. This breaks audit trails, bypasses user-level access controls, and violates the principle of least privilege. Amazon Bedrock AgentCore is a platform to build, connect, and optimize agents at scale, with any framework or model. This post shows how to configure AgentCore Gateway , a capability of Amazon Bedrock AgentCore, for an on-behalf-of (OBO) token exchange with Microsoft Entra ID. An AI agent can then call the ServiceNow REST API while preserving the calling user’s identity. You configure the token exchange on the gateway target, and AgentCore Gateway performs the exchange on each request. The pattern can be applied to other REST APIs protected by OAuth. In production, you can additionally pair identity propagation with Amazon Bedrock Guardrails to filter harmful content and validate the agent’s inputs and outputs. Solution overview The architecture involves three key components connected through AgentCore Gateway: An AI agent application, protected by Microsoft Entra ID through an OAuth application registration. A Model Context Protocol (MCP) server, implemented using AgentCore Gateway, sitting between the agent and ServiceNow. The ServiceNow REST API, configured with an inbound OAuth integration tied to Microsoft Entra ID. The following figure shows the end-to-end solution architecture, including components within AWS, Microsoft Entra ID, and ServiceNow. Figure 1: Solution architecture across AWS, Microsoft Entra ID, and ServiceNow As shown in Figure 1, the user acquires a JSON Web Token (JWT) to invoke the agent 1. The agent authenticates to the gateway with a JWT token scoped to the agent’s own application registration 2. The gateway then exchanges that token, using the OBO flow, for a new token scoped to the ServiceNow API connector, with the original user’s identity preserved 3. ServiceNow receives a valid token whose preferred_username claim maps to an existing ServiceNow user and applies that user’s permissions to the API call 4. How OBO token exchange works in this context When the agent calls the gateway, it presents a JWT with an audience claim matching the agent’s client ID (for example, 3ff88e17-XXXX-XXXX-XXXX-XXXXXXXXXXXX ). ServiceNow, however, expects a token with an audience claim matching its own API connector client ID ( 5d4a7a11-XXXX-XXXX-XXXX-XXXXXXXXXXXX ). The OBO flow bridges this gap. AgentCore Gateway sends the inbound token to the Entra token endpoint along with the agent application’s client credentials, the target scope, and a parameter requested_token_use: on_behalf_of . Entra validates that the calling user consented to the delegation, then issues a new token for the ServiceNow API with the original user’s claims intact. Prerequisites Before you begin, you need the following: An AWS account with access to AgentCore Gateway. A Microsoft Entra ID tenant with permissions to create application registrations . Your account needs at least the Application Developer role to register applications. A ServiceNow instance with administrative access to configure inbound OAuth integrations. You can create a ServiceNow personal developer instance (PDI) at the ServiceNow personal developer instance signup page https://developer.servicenow.com/ . Two Entra application registrations: one representing the AI agent, and one representing the ServiceNow API connector. Configuring Microsoft Entra ID Start by creating an application registration to represent the ServiceNow API connector. The following screenshot shows the application registration page for the ServiceNow API Connector in Microsoft Entra ID. Figure 2: Application registration for the ServiceNow API connector in Microsoft Entra ID After creating, in the Overview page note the Application (client) ID. In the navigation menu expand Manage and select Expose an API and add a scope named user_impersonation using the default Application ID URI. This scope is what the OBO flow requests when exchanging tokens. The following screenshot shows how to expose an API in Microsoft Entra ID. Figure 3: Exposing the user_impersonation scope in Microsoft Entra ID Next, create an application registration for the AI agent. The following screenshot shows the application registration page in Microsoft Entra ID for the ServiceNow Agent application. Figure 4: Application registration for the ServiceNow Agent in Microsoft Entra ID Note the Application (client) ID for the ServiceNowAgent. Create a client secret on this registration. The gateway needs these credentials to perform the OBO exchange. The following screenshot shows how you can create a client secret on the ServiceNow Agent application registration in Microsoft Entra ID. Figure 5: Creating a client secret on the ServiceNow Agent application registration Then configure the agent application to have API permissions to call the ServiceNow API connector application. The following screenshot shows the API permissions that you need to configure on the ServiceNow Agent application registration in Microsoft Entra ID. Figure 6: API permission configuration in Microsoft Entra ID No changes to the Entra configuration are needed beyond what you would set up for any standard OBO integration between two applications. Configuring ServiceNow In the ServiceNow administrative console, navigate to System OAuth > Inbound Integrations and create a new inbound integration (Third party ID token issued by OIDC supporting identity provider). Specify the client ID from the ServiceNow API connector application registration you created in Entra. The following screenshot shows the configuration of the inbound integration in ServiceNow. Figure 7: Configuring the inbound integration in ServiceNow In the same screen, create a new OpenID Connect (OIDC) provider configuration and enter the OIDC metadata URL for your Entra tenant. Map the user claim to the appropriate user field. For example, if your Entra tenant places the user’s email in the preferred_username claim, map that to the Email field in ServiceNow. Clear JTI verification if your Entra tenant doesn’t include it in tokens. Entra uses an internal claim named uti on tokens it issues, which is equivalent to JTI. Consider mapping this uti claim to a jti claim to provide additional replay protection and denylisting. The following screenshot shows how to configure the OIDC provider in ServiceNow. Figure 8: Configuring the OAuth OIDC provider in ServiceNow Finally, in the same screen, create an auth scope for the integration (for example, APIConnector ). The following screenshot shows how to create a new auth scope in ServiceNow. Figure 9: Creating a new auth scope in ServiceNow Limit the auth scope to the Table API, or whichever ServiceNow APIs your agent needs to access, as shown in the following screenshot. Figure 10: Limiting the auth scope to the Table API in ServiceNow After this configuration is complete, ServiceNow accepts authorization tokens with an audience of your API connector’s client ID and resolves the calling user from the preferred_username claim. Configuring AgentCore Gateway With Entra and ServiceNow configured, you can now set up AgentCore Gateway to handle the OBO exchange natively. Step 1: Create an outbound auth configuration Create a new outbound auth configuration (choose Build > Identity > Add Outbound Auth > Add OAuth client ) in AgentCore and select Customized provider . Enter the client ID and client secret from your agent application registration, along with the Entra discovery URL as shown in the following screenshot. Figure 11: Adding an OAuth client in AgentCore Gateway Expand Additional configurations and select JWT authorization grant as shown in the following screenshot. This tells the gateway to use a JWT-based grant ty