AgentCore Preserves User Permissions When Calling ServiceNow, No Custom Token Exchange Required

A corporate AI agent can open an incident in ServiceNow, but an uncomfortable question arises: on whose behalf is it doing so? If every request arrives under the application's technical account, ServiceNow stops seeing the real initiator. The audit log shows the gateway instead of the employee, user restrictions don't work as intended, and the agent may end up with more permissions than it needs.

AWS has added native token exchange using the On-Behalf-Of (OBO) flow to Amazon Bedrock AgentCore Gateway. The gateway accepts the user's token, contacts Microsoft Entra ID, and obtains a different token, one intended for the ServiceNow API but still tied to the original user. A custom intermediary for this exchange is no longer needed.

What it looks like in a simple example

Suppose an employee asks the agent to show active incidents. First, the user obtains a JWT for the agent application. The audience field of this token contains the agent's identifier, so ServiceNow will not accept it: the corporate system expects a token issued for its own API connector.

The agent passes the JWT to AgentCore Gateway. The gateway sends it to Entra ID along with the application's credentials, the target scope, and the requested_token_use parameter set to on_behalf_of. Entra verifies the permitted delegation and issues a new token with the ServiceNow connector's audience, preserving the user's data.

Next, Gateway calls the ServiceNow REST API. The platform maps the preferred_username claim, for example a work email address, to an existing employee record and applies that person's roles. If a person can only read incidents, the agent will not be able to modify them either. The audit log keeps a clear trail: the action is tied to the user who gave the command.

What you need to configure

Microsoft Entra ID requires two app registrations: one represents the AI agent, the other the ServiceNow API connector. The connector publishes a delegated scope, user_impersonation, and the agent application is granted permission to request that scope.

In ServiceNow, an inbound OAuth integration is created with Entra as the OIDC provider. It is important to map the user claim correctly and to limit the auth scope to only the APIs the agent actually needs. For example, a gateway that only views incidents has no reason to open access to every table on the platform.

In AgentCore, an outbound OAuth configuration is created with a JWT authorization grant. Then a Gateway is set up with MCP version 2025-11-25: earlier versions do not support native OBO. For the REST target, you specify the connector's scope and the parameter requested_token_use:on_behalf_of. After that, the exchange happens automatically on every request.

Where things can go wrong

Native token exchange does not replace careful access configuration. The user from preferred_username must exist in ServiceNow, the agent application must have the delegated permission, and the auth scope must allow the endpoint being called. A mistake in any of these places will end in an authorization failure.

Protection against token reuse deserves separate attention. Entra passes an internal uti claim instead of the standard jti. AWS suggests considering mapping it to jti so that ServiceNow can apply additional validation and token blocking. Guardrails also do not replace authorization: they filter content, whereas OBO determines whether the user has the right to perform the action.

The practical takeaway is simple: if an agent works with corporate systems, don't hide all users behind a single service account. Pass identity along the entire chain, narrow the scope to the necessary operations, and test scenarios separately for employees with different roles. The boundary between the agent and the business system is where it is decided whether automation becomes manageable or turns into a new privileged hole.