Amazon Bedrock AgentCore Gateway has added built‑in support for an on‑behalf‑of token exchange with Microsoft Entra ID, enabling AI agents to invoke the ServiceNow REST API with the caller’s identity intact. Engineers who need to preserve user context across API calls can now rely on the gateway to perform the exchange, eliminating ad‑hoc token translation logic.
Solution Overview
The pattern consists of three linked pieces:
- An AI agent registered in Entra ID, protected by OAuth.
- AgentCore Gateway acting as a Model Context Protocol (MCP) server that sits between the agent and ServiceNow.
- A ServiceNow instance configured with an inbound OAuth integration that trusts Entra ID.
When a user obtains a JWT and calls the agent, the agent presents a token whose audience claim matches its own client ID. The gateway forwards this token to the Entra token endpoint, requests a new token for the ServiceNow connector client ID, and includes requested_token_use: on_behalf_of. Entra validates the delegation and returns a token that retains the original user’s claims, including preferred_username. ServiceNow receives this token, maps the username to a local user, and applies that user’s permissions to the request.
Configuring the OBO Flow
Implementation steps, as described in the source, are:
- Provision an AWS account with access to AgentCore Gateway.
- Create two Entra application registrations: one for the AI agent and one for the ServiceNow API connector.
- In the ServiceNow instance, set up an inbound OAuth integration that points to the connector’s client ID.
- Configure the gateway target to use the OBO flow, supplying the connector client ID as the target scope and the agent’s client credentials for authentication.
During each request, the gateway automatically performs the token exchange; no code changes are required in the agent or ServiceNow side beyond the initial OAuth setup.
Operational and Security Implications
From an operations perspective, the exchange moves token handling into a managed service, reducing the surface area for custom secret management. However, practitioners must still ensure that the Entra application registrations have appropriate consent and that the connector client ID is limited to the ServiceNow API scope.
Security considerations include:
- Preserving the original user’s claims means audit logs in ServiceNow will reflect the true initiator, supporting compliance and least‑privilege enforcement.
- The gateway’s OBO exchange relies on Entra’s validation of user consent; missing or overly broad consent could unintentionally broaden access.
- Because the gateway forwards the inbound token to Entra, network connectivity and token endpoint availability become part of the request path; monitoring for latency or failures is advisable.
- Pairing the flow with Amazon Bedrock Guardrails (as suggested) can add content‑level checks, but those checks are separate from authentication and should be evaluated as an additional control.
Related CloudNinjas coverage: AWS.
What This Means For Practitioners
Adopting the built‑in OBO exchange simplifies the architecture for any AI‑driven integration that must act on behalf of a user. Teams can eliminate custom token‑translation services, rely on a single source of truth for identity, and keep auditability intact. Before rollout, verify Entra consent scopes, test the token flow end‑to‑end, and instrument monitoring for gateway latency and token‑endpoint health. The pattern is reusable for any OAuth‑protected REST API, not just ServiceNow.
