Enterprise developers are currently facing a dangerous crossroads in the deployment of B2B AI agents. To make an agent functional across multiple client accounts, the easiest path is often the most perilous: granting the agent a high-privilege service account or a super-user token that can access all tenant data. While this eliminates permission errors during the prototype phase, it creates a catastrophic security hole where a single prompt injection or logic error could allow one customer to access another customer's private data. This tension between operational fluidity and strict tenant isolation has become the primary bottleneck for scaling autonomous agents in regulated industries.
The Architecture of Amazon Bedrock AgentCore and RFC 8693
To resolve this systemic vulnerability, Amazon Bedrock AgentCore has integrated the RFC 8693 standard for OAuth 2.0 Token Exchange. This implementation moves the burden of identity management away from the application logic and into the infrastructure layer. At the heart of this system is the Amazon Bedrock AgentCore Identity service, which supports token exchange as a native credential-provider grant type. The operational flow is managed by the AgentCore Gateway, which acts as an intelligent interceptor. When an AI agent attempts to call a downstream tool or API, the Gateway automatically intercepts the inbound user token and exchanges it for a new, target-service-specific token before the request ever reaches the destination.
This mechanism is demonstrated through a reference implementation called TravelBot, a reservation assistant designed to handle two distinct tenants, Acme and Globex. By using the OBO flow, TravelBot ensures that a request originating from an Acme user can never accidentally trigger a reservation action within the Globex environment, even though the same AI agent is processing both requests. The full technical implementation and proof-of-concept code are available in the official repository at https://github.com/aws-samples/sample-obo-flow-poc.
The entire architectural chain consists of six critical components: the User, the Agent, the AgentCore Gateway, the AgentCore Identity service, the Tenant Auth Server, and the Downstream API. By decoupling the identity provider from the agent's execution logic, the system ensures that the agent never possesses long-lived, broad-spectrum permissions. Instead, it operates on a just-in-time basis, acquiring only the specific permissions required for the immediate task at hand.
The Shift from Direct Forwarding to OBO Token Transformation
To understand why this shift is necessary, one must examine the failure of the Direct Forwarding pattern. In a direct forwarding scenario, the agent simply passes the user's original inbound token to the downstream API. On the surface, this seems secure because the user's identity is preserved. However, this creates a critical mismatch in the JWT (JSON Web Token) claims. The original token's `aud` (audience) claim is set to the Agent API, not the downstream service. For the downstream API to accept this token, developers are often forced to disable audience validation or allow a wide range of audiences. This creates the Confused Deputy problem, where a privileged entity is tricked into using its authority to perform an action on behalf of an unauthorized user.
Amazon Bedrock's OBO (On-Behalf-Of) flow solves this by performing a precise transformation of JWT claims. During the exchange process, the `sub` (subject) claim, which identifies the actual user, is preserved. This ensures the final API knows exactly who the human requester is. Simultaneously, the `aud` claim is rewritten to match the specific downstream service being called, ensuring the token cannot be reused elsewhere. To maintain a complete audit trail, the system adds an `act` (actor) claim—or a `cid` claim in Okta environments—which records that the AgentCore is the entity performing the action on behalf of the user.
This transformation allows for a sophisticated dual-layer of control. The downstream API can use the `sub` claim to make authorization decisions based on the user's specific permissions, while using the `act` claim to apply rate limits or logging specific to the AI agent. Furthermore, the OBO flow allows the system to shrink the `scp` (scope) of the token to the absolute minimum required for that specific tool call. If a token for a specific reservation API is compromised, it cannot be used to access a billing API or a user profile API, effectively neutralizing the risk of lateral movement within the cloud environment.
Beyond the security logic, the system is designed for massive infrastructure flexibility. Amazon Bedrock AgentCore Identity is vendor-agnostic, supporting custom authentication servers from Okta, Auth0, and Keycloak. For organizations deeply integrated into the Microsoft ecosystem, it provides native support for RFC 7523 based flows via the `grantType: JWT_AUTHORIZATION_GRANT` configuration. This allows the system to handle JWT bearer token exchanges internally, removing the need for developers to manually construct complex authentication request messages.
Adaptability is further enhanced through the use of a `customParameters` map. This allows administrators to adjust `subject_token_type`, `audience`, and `actor-token` settings at runtime. If a company switches its identity provider or updates its API specifications, the change can be implemented via configuration updates rather than source code modifications. This is particularly critical for high-security sectors like finance and government, where the system must operate within a VPC (Virtual Private Cloud). The AgentCore Gateway supports private connections to internal identity providers via secure tunnels, ensuring that sensitive authentication traffic never traverses the public internet.
For B2B AI practitioners, the implication is clear: the era of the super-user AI agent is over. The security of a multi-tenant agent depends not on the permissions granted to the agent, but on how those permissions are delegated and restricted during the transit from the user to the API. By implementing a gateway-level token exchange, organizations can finally achieve a zero-trust architecture for AI agents, where every single tool call is independently verified, scoped, and audited.
True enterprise AI governance is achieved when the agent is treated as a transparent conduit rather than a privileged entity.
