Amazon Bedrock AgentCore Gatewayでマルチテナントエージェントの代理トークン交換を実装するImplement on-behalf-of token exchange for multi-tenant agents with Amazon Bedrock AgentCore Gateway

Amazon Web Services has published guidance on implementing on-behalf-of (OBO) token exchange within Amazon Bedrock AgentCore Gateway, a pattern aimed at helping developers build multi-tenant agentic applications that can call downstream APIs while preserving the identity and permissions of the end user. As organizations move generative AI agents from prototypes into production, controlling precisely what an agent is permitted to do—and on whose behalf—has become one of the central security challenges, especially when a single deployment serves many customers at once.

The core problem is delegation. An AI agent frequently acts as an intermediary: a user asks it to retrieve records, update a support ticket, or query a service, and the agent must call an API to complete the task. In a naive design, the agent might use a single, broadly scoped service credential for every request. That approach undermines tenant isolation, because the downstream API cannot distinguish which user or tenant initiated an action, and it risks granting the agent more access than any individual user should hold. OBO token exchange addresses this by having the agent trade the user's token for a new token scoped to the specific downstream resource, while still representing the original user rather than a generic machine identity.

AgentCore Gateway sits between agents and the tools or APIs they consume, functioning as a managed layer that handles authentication, authorization, and protocol translation. According to the AWS description, the Gateway can perform token exchange based on the OAuth 2.0 Token Exchange specification (RFC 8693), accepting an inbound user token and exchanging it with an identity provider for a token that is valid against the target API. This allows the downstream service to apply its own access controls using the delegated identity, so permissions are evaluated per user rather than through a shared credential. In practice this keeps the principle of least privilege intact across the agent workflow.

In a multi-tenant setup, each tenant typically maps to its own identity provider configuration, or to a distinct set of scopes and claims. The Gateway is configured to recognize the tenant context carried in the inbound token and to request the appropriate exchange for that tenant. The flow generally involves a subject token that represents the user, credentials that represent the agent or client, and a requested audience or scope for the destination resource. Because the exchanged token encodes the user's identity, audit logs on the downstream API can attribute activity back to a specific person and tenant, which supports both compliance requirements and incident investigation.

This capability is part of the wider AgentCore family, which AWS positions as a set of building blocks for deploying and operating agents at scale. Alongside the Gateway, the suite includes components commonly referenced as Runtime for execution, Memory for state, Identity for credential handling, and Observability for monitoring. The Gateway and Identity pieces are the most relevant to token exchange, since together they manage how agents obtain and present credentials. AgentCore Gateway also exposes tools in a way compatible with the Model Context Protocol (MCP), an increasingly adopted standard for connecting language models to external systems, which means the same delegation model can apply across MCP-based tool calls.

The broader context is an industry-wide effort to define identity for AI agents. Traditional OAuth flows were designed for users and applications, not for autonomous software acting on a user's behalf across multiple hops. Vendors including Microsoft and Okta, the latter through its Auth0 identity platform, have introduced their own approaches to agent authorization, and standards bodies continue to refine token exchange and delegation patterns. AWS's use of RFC 8693 aligns AgentCore with an established specification rather than a proprietary scheme, which is likely to ease integration with existing enterprise identity providers such as Amazon Cognito, Okta, and Microsoft Entra ID.

For teams evaluating the approach, the practical prerequisites appear to include a configured identity provider that supports token exchange, clearly defined scopes for each downstream API, and a tenant model that maps users to their respective boundaries. Developers should also weigh operational considerations such as token lifetimes, refresh handling, and the latency added by an extra exchange step. Used carefully, the OBO pattern offers a route to combining flexible agent-to-API integration with the tenant isolation and traceability that regulated environments typically demand, though the security outcome still depends on how rigorously scopes and identity mappings are defined.