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.

The architecture involves three key components connected through AgentCore Gateway:

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

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.

Create a new AgentCore Gateway ( Build > Gateways > Create gateway ). When defining the gateway details, expand Additional configurations — optional and select MCP version 2025-11-25 as shown in the following screenshot. This version is required for native OBO support. You can’t turn on native OBO for gateways created with earlier MCP versions.

The native OBO support in AgentCore Gateway removes the need for custom AWS Lambda interceptors to perform token exchanges. You configure the token exchange directly on the gateway target, and the gateway handles it transparently on every request. This approach maintains user identity across the agent-to-API chain, supports ServiceNow’s user-level access controls, and eliminates custom code that would need to be maintained separately.

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.

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 ).

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.