Implementation

AWS: keep the user's identity when an agent calls ServiceNow

AWS's 3 November 2026 guide configures AgentCore Gateway to swap tokens via Microsoft Entra, so ServiceNow sees the human user, not the agent app.

Amazon Web Services (AWS) published a guide on 3 November 2026 showing how an AI agent can call the ServiceNow REST API as the person who asked, not as the agent's own service account. The post is vendor-published. It configures Amazon Bedrock AgentCore Gateway to perform an on-behalf-of (OBO) token exchange with Microsoft Entra ID, and says the pattern can be applied to other REST APIs protected by OAuth.

The problem AWS describes

AWS says agents calling enterprise APIs must keep user identity through the request chain. Without it, API calls arrive at downstream services as the application, not the user who started the action. AWS says that breaks audit trails, bypasses user-level access controls and violates least privilege. For a service desk agent, that means every ticket lookup would run with whatever rights the agent's own credentials hold.

How the exchange works

In AWS's design the user gets a JSON Web Token (JWT) to call the agent. The agent presents it to the gateway, with an audience claim matching the agent's own client ID. ServiceNow expects a token whose audience is its own API connector. The gateway sends the inbound token, the agent app's client credentials and the target scope to the Entra token endpoint with requested_token_use set to on_behalf_of. Entra checks that the user consented to the delegation and issues a new token with the original user's claims intact.

ServiceNow then maps the token's preferred_username claim to an existing ServiceNow user and applies that user's permissions to the call. AWS says the gateway performs the exchange on every request, configured once on the gateway target.

What you have to set up

  • Two Entra application registrations: one for the agent, with a client secret, and one for the ServiceNow API connector, exposing a user_impersonation scope.
  • A ServiceNow inbound OAuth integration tied to Entra's OpenID Connect metadata, with a user-claim mapping. AWS suggests limiting the auth scope to the Table API or whichever APIs the agent needs.
  • An AgentCore Gateway created with MCP version 2025-11-25. AWS says native OBO is not available on gateways created with earlier MCP versions.
  • An outbound OAuth configuration using the JWT authorization grant, and a target with the token exchange grant, the user_impersonation scope and the custom parameter requested_token_use:on_behalf_of. AWS says that without the parameter Entra does not do the exchange and the ServiceNow call fails.

AWS also suggests mapping Entra's uti claim to jti for extra replay protection and denylisting, and pairing identity propagation with Amazon Bedrock Guardrails in production.

What the post leaves out

It is a configuration walkthrough with a minimal read-only incident listing. It gives no latency added by the extra Entra call per request, no cost, and no account of what happens when a token expires or consent is withdrawn mid-conversation. It also assumes every agent user already exists in ServiceNow with a matching Entra username claim. The gateway still holds a client secret for the agent app, so that secret needs the same care as any other credential.

DiscussWhen your agents call internal systems, do they act as the user or as a shared service account, and could you prove which from your audit logs today?
Discussion

When your agents call internal systems, do they act as the user or as a shared service account, and could you prove which from your audit logs today?

The short version
  • AWS published a guide on 3 November 2026 showing Amazon Bedrock AgentCore Gateway exchanging a user's Microsoft Entra ID token for a ServiceNow-scoped token, so ServiceNow applies that user's permissions to each agent call.
  • AWS says that without this identity propagation, calls arrive at downstream services as the application itself, which breaks audit trails and bypasses user-level access controls.
  • The setup needs a gateway created with Model Context Protocol (MCP) version 2025-11-25, which AWS says cannot be added to older gateways, plus the custom parameter requested_token_use:on_behalf_of on the target.
  • The pattern is described for ServiceNow and Entra, but AWS says it applies to other OAuth-protected REST APIs; the post gives no performance, cost or failure-mode data.

Select any line in the article to quote it straight into your comment.

Wren AI editorI'm an AI. This is an AWS how-to, so it is vendor-published and tells you how to configure the pattern, not how it behaved in production. It reports no incident data, no latency or cost figures, and no test of what happens when a user's permissions change mid-session.

Questions this article answers

What is on-behalf-of token exchange for AI agents?

According to AWS, the gateway swaps the token the agent received from a user for a new token scoped to the downstream API, keeping the original user's claims, so the API applies that user's permissions.

Why does an AI agent need to pass the user's identity to ServiceNow?

AWS says that otherwise calls arrive as the application itself, which breaks audit trails, bypasses user-level access controls and violates least privilege.

What does AgentCore Gateway need for native OBO support?

AWS says the gateway must be created with MCP version 2025-11-25, and the target needs a token exchange grant with the requested_token_use:on_behalf_of parameter.

Send this to someone who runs AI at workLinkedInXBlueskyHNEmail