.png)
AWS announced support for on-behalf-of (OBO) token exchange in Amazon Bedrock AgentCore Identity and Bedrock AgentCore Gateway. The release gives multi-tenant agents a standard way to call downstream APIs with a delegated user identity instead of collapsing everything onto the agent’s service account.
The core issue is simple: an agent that serves many tenants still has to invoke tools, APIs, and services on behalf of a specific user and tenant. If every downstream request arrives with the agent’s own identity, audit trails lose per-user attribution and authorization logic becomes too coarse. If the original user token is forwarded unchanged, downstream systems end up trusting a token that was minted for a different audience and a different hop, which creates confused-deputy risk.
That is exactly the space RFC 8693 was designed for. The AWS implementation uses token exchange to turn an inbound subject token into a new token scoped for the downstream resource, so the agent can act as a delegate without impersonating the user or overextending its own privileges.
The post’s implementation detail that matters most is the JWT claim rewrite across each hop. The inbound token lands at the agent, then AgentCore Identity performs token exchange, and the resulting token is bound to the downstream API audience rather than the original front-door audience. That audience binding is the difference between “the agent has a token” and “the agent has a token that this specific tool should accept.”
The blog uses Okta as the identity provider and walks through the exact OBO flow for a reference app called TravelBot, a multi-tenant booking assistant for two example tenants, Acme and Globex. The important properties are:
That design gives you defense in depth. Even if one component in the agent stack is compromised, the token minted for one audience cannot simply be replayed everywhere else.
AWS is positioning Bedrock AgentCore Identity as the token-exchange provider and AgentCore Gateway as the enforcement point that sits between the agent and downstream services. That separation is the right abstraction for production systems. Identity handles the standards-based token minting. Gateway handles tool mediation, audience control, and tenant-aware access checks.
The post also ties this release to earlier AgentCore patterns for multi-tenant agents and fine-grained access control with Gateway interceptors. That matters because OBO alone does not solve tenant isolation. You still need the gateway layer to decide which tools are visible, which tenants are allowed to reach them, and which claims are required before a delegated token can be exchanged or used.
For engineering teams, the practical implication is that identity policy and tool policy are no longer fused into application code. The agent can remain relatively stateless, while Gateway and Identity carry the tenancy and delegation semantics.
The post draws the boundary correctly: OBO is essential when one agent fronts multiple downstream services or tenants and the inbound token audience does not already match the target API. In that situation, direct token forwarding is the wrong default.
For a single-tenant setup where the original audience already matches the downstream service, forwarding may still be acceptable. But once the same agent serves multiple tenants, the delegation story needs to be explicit. OBO gives you a standards-based way to maintain user attribution without making every tool trust every frontend token.
For production teams, I would treat this as the preferred pattern whenever all three of these are true: the agent calls external tools, the agent serves multiple tenants, and downstream systems need to distinguish user identity from agent identity. That is the common case in enterprise agent deployments, which is why this release is more than a nice-to-have feature.
The reference implementation is being published in the aws-samples/sample-obo-flow-poc repository, which should make it easier to validate the flow end to end and inspect the JWT transformations rather than reverse-engineering them from docs alone.
