Amazon Bedrock AgentCore Uses Entra OBO to Call ServiceNow as the Signed-In User

What's new​

An AWS Machine Learning blog post describes configuring AgentCore Gateway for an OBO token exchange with Microsoft Entra ID, so an agent can call the ServiceNow REST API while preserving the calling user's identity. The gateway does the exchange natively, with no interceptor Lambda or custom code. The Chenab Times covered the same walkthrough on November 4.

The "native" part is the real change. An earlier community walkthrough, written when the gateway did not support this exchange, had to run a separate compute function to perform it. That glue code is now configuration.

The architecture​

Three pieces are involved. AgentCore Gateway acts as an MCP server between the agent and ServiceNow. The ServiceNow REST API has an inbound OAuth integration tied to Microsoft Entra ID. The third piece is the agent application, which authenticates users through Entra.

The Chenab Times describes the token problem this solves:

• The agent calls the gateway with a token whose audience is the agent.
• ServiceNow wants a token whose audience is its own API connector.
• The gateway sends the inbound token, the agent's credentials and the target scope to the Entra token endpoint.
• Entra returns a new ServiceNow-scoped token that keeps the user's claims.
• ServiceNow then identifies the user and applies that user's permissions.

Not every OBO is the same protocol​

AWS's developer guide says AgentCore Identity supports two standards for OBO. RFC 8693 token exchange submits the inbound token as a subject token. RFC 7523 JWT authorization grants present it as an assertion. Entra falls in the second camp.

The AWS docs list the built-in Microsoft provider as using the JWT_AUTHORIZATION_GRANT mode. They describe Microsoft's OBO flow as a proprietary delegation pattern built on the JWT-bearer grant. The requested_token_use=on_behalf_of parameter is added automatically unless you override it. An independent write-up on agentgateway makes the same point, noting that Entra does not speak RFC 8693.

The practical consequence is that a generic RFC 8693 setup will not work against Entra. If you configure a custom provider, choose the grant type your identity provider actually expects.

The reported setup​

The following comes from the Chenab Times' account of the walkthrough. I have not verified each console step against ServiceNow or Microsoft documentation.

Prerequisites

• An AWS account with AgentCore Gateway access.
• An Entra tenant where you can register applications (the report cites the Application Developer role).
• Admin access to a ServiceNow instance for inbound OAuth.
• Two Entra app registrations: one for the agent, one for the ServiceNow API connector.

Entra

• Expose a user_impersonation scope on the connector registration.
• Give the agent registration a client secret.
• Grant the agent registration API permission to call the connector.

ServiceNow

• Create an inbound integration under System OAuth, using the connector's client ID.
• Add an OIDC provider configuration pointing at the Entra tenant's metadata URL.
• Map a user claim such as preferred_username to a ServiceNow field. One community author mapped it to Email, since in their tenant the user email appears in that claim.
• Create an authorization scope that limits the agent to specific APIs, such as the Table API.

AgentCore

• Create an outbound auth configuration with the agent's client ID and secret and the Entra discovery URL, using the JWT authorization grant.
• Configure the gateway's inbound identity from the agent's app registration.
• Add a target with the ServiceNow REST endpoint and an OpenAPI spec.
• Choose OAuth for the outbound identity.
• Set a token exchange grant using the connector's scope and the custom parameter requested_token_use: on_behalf_of.

If authentication fails, the report suggests checking three things:

• the claim mapping in ServiceNow
• the authorization scope permissions
• the API permissions in Entra

These checks are sensible, but the AWS documentation I reviewed does not independently confirm them.

A claim I would not repeat: the MCP version requirement​

The Chenab Times says you must select MCP version 2025-11-25 because earlier versions lack native OBO. AWS's gateway documentation does not support that limit. It lists the supported MCP protocol versions as 2026-07-28, 2025-11-25, 2025-06-18 and 2025-03-26. It does not tie OBO to any one of them.

AWS also says accounts enabled for MCP version updates can change a gateway's versions with UpdateGateway. Otherwise the versions are fixed at creation. Choosing a current version when you create the gateway is sensible, but treat the "required" wording as unverified.

A real constraint: listing mode​

For MCP-server targets that use OBO as outbound authorization, AWS documents a listing-mode consideration.

• Authorization server supports machine-to-machine (client-credentials) auth: you can use DEFAULT listing mode. The gateway syncs a target's tools in the background using a machine token, because no user token exists during control-plane operations.
• Authorization server does not support machine-to-machine auth: use DYNAMIC mode. The gateway discovers capabilities at invocation time, when a user token is present.

AWS also says DYNAMIC mode does not work with semantic search or outbound three-legged OAuth. The sources I reviewed don't say which mode applies to the ServiceNow example. That target is built from an OpenAPI specification, so check the target-type documentation before assuming the MCP-server rules apply.

What this does and doesn't buy you​

Benefits

• Audit trails can reflect the human, not "the AI agent service account."
• AWS says the exchanged token carries both the agent's identity and the original caller's identity, so downstream systems can authorize on both.
• Developers don't handle the inbound token or the client secret directly. AgentCore Identity brokers the exchange.

Caveats

• The authorization server makes the final call. AWS says Entra decides whether to grant the scopes and permit the delegation.
• Identity propagation is not the same as least privilege. The downstream API's permissions, scope design and claim mapping still decide what an agent can do.
• If the ServiceNow scope is broad, or the user is over-permissioned, the agent inherits that.
• The agent registration holds a client secret. Treat it like any other privileged credential, with rotation and ownership.

Why Windows and Entra admins should care​

Entra ID is increasingly the control plane for agent access, even when the agent runtime isn't Microsoft's. Admins who own Entra app registrations will be asked to create these two registrations. Review them as you would any delegated-permission app: scope names, who can consent, and secret lifetime.

Independent write-ups show the pattern spreading beyond AWS. One open-source agent gateway project recently added native Entra on-behalf-of support so agents can call downstream APIs as the user.

Bottom line​

AWS documents OBO token exchange in AgentCore Identity and Gateway, and its ServiceNow walkthrough shows Entra doing the delegation. The mechanics are well supported: JWT-bearer grant, requested_token_use=on_behalf_of, and an Entra app registration on each side. Two points from the news coverage are not backed by AWS documentation. One is the "MCP 2025-11-25 only" requirement. The other is the framing of this as a new ServiceNow partnership; the ServiceNow piece is an AWS-published configuration example. Test in a non-production tenant before rolling it out.