AIToday

AWS Bedrock adds OAuth token exchange for multi-tenant AI agents

Amazon AI Blog3h ago
AWS Bedrock adds OAuth token exchange for multi-tenant AI agents

Key takeaway

AWS Bedrock AgentCore Identity now supports OAuth 2.0 Token Exchange (RFC 8693), allowing multi-tenant AI agents to automatically exchange user tokens for new tokens scoped to each downstream service. This solves a core identity problem in agentic systems: preserving audit trails and enforcing least privilege when an agent calls multiple downstream APIs on behalf of users from different tenants, without requiring the agent to implement exchange logic itself.

Summaries like this, in your inbox every morning.

Sign up free →

3 Key Points

  • What happened

    Amazon Bedrock AgentCore Identity now supports OAuth 2.0 Token Exchange (RFC 8693) natively, allowing the AgentCore Gateway to automatically exchange an incoming user token for a new token scoped to each downstream service before the agent calls it. AWS published a reference implementation called TravelBot, a multi-tenant booking assistant serving two example tenants (Acme and Globex), with code to be made available in the aws-samples/sample-obo-flow-poc repository.

  • Why it matters

    Multi-tenant AI agents face an identity problem: if they call downstream APIs using the agent's own identity, the audit trail collapses and every downstream system must trust the agent unconditionally; if they forward the user's token unchanged, downstream tools cannot validate which tenant the request belongs to. Token exchange solves this by preserving the original caller's identity (sub claim) while binding each downstream call to a single service (aud claim), so the downstream API can answer both 'who is this for?' and 'who is doing this?' from one token, and audit/authorization decisions remain traceable to the original user.

  • What to watch

    The OBO pattern is essential only when an agent fronts multiple downstream services or tenants and the inbound token's audience differs from the downstream API. For single-tenant agents where the inbound audience already matches the downstream service, direct token forwarding may be sufficient. The implementation requires alignment across the agent runtime, authorization servers, and downstream APIs; Bedrock AgentCore Gateway and AgentCore Identity remove that coordination burden by handling the exchange transparently.

Context & Analysis

Multi-tenant AI agents deployed in production face a fundamental identity challenge that neither simple impersonation nor direct token forwarding adequately solves. When an agent handles requests from users across multiple tenants—for example, a booking assistant serving both Acme and Globex—the agent must somehow signal to downstream APIs both who the original user is and which tenant they belong to, while keeping the audit trail intact and preventing any single compromised component from accessing resources it should not. The OAuth 2.0 Token Exchange specification (RFC 8693) addresses this problem at the standards level, but implementing it requires coordinating between the agent runtime, authorization servers, and every downstream API.

By baking RFC 8693 support directly into Amazon Bedrock AgentCore Identity and having the AgentCore Gateway intercept tool calls, AWS removes the burden of implementing token exchange logic from the agent code itself. The Gateway transparently identifies the target tenant, exchanges the inbound token for a new one scoped to that tenant's downstream service, and issues the call with a token whose sub claim still points to the original user. This approach gives downstream APIs cryptographic proof of the delegation chain—they can validate the token independently without trusting the agent, and they can distinguish authorization decisions (based on sub) from audit and rate-limiting decisions (based on the actor claim that records AgentCore as the delegate).

FAQ

When should I use on-behalf-of token exchange instead of direct token forwarding?
You should use OBO when an agent fronts multiple downstream services or tenants and the inbound token's audience differs from any single downstream API. For a single-tenant agent where the inbound audience already matches the downstream service, direct token forwarding can be sufficient.
What identity information is preserved in an OBO token exchange?
The original caller's identity is preserved end to end through the sub claim, even as the audience (aud claim) changes per tenant. A separate actor claim records who performed the exchange (in this case, AgentCore), so downstream APIs can determine both 'who is this for?' (sub) and 'who is acting on their behalf?' (actor).

Discussion

No comments yet. Be the first to share your thoughts!

Log in to join the discussion

Related Articles

Stay ahead with AI news

Get curated AI news from 200+ sources delivered daily to your inbox. Free to use.

Get Started Free

Free · takes 30 seconds · unsubscribe anytime

1 minute a day. The AI essentials.

200+ sources · Email / LINE / Slack

Get it free →