在 Amazon Bedrock AgentCore Gateway 上实现多租户代理的 OBO 令牌交换

在多租户生产环境部署生成式 AI 代理时，身份问题是绕不开的工程难点。代理代表用户调用下游 API 时，应当随调用一起传递的是哪个身份？如果完全使用代理自身的服务身份，下游系统就不得不无条件信任代理，审计线索随之断裂；若原样转发用户令牌，下游工具又会变成被诱导执行操作的“混淆代理人”。当一个代理服务大量租户、且下游调用发生时用户并不在线时，这两种做法都无法扩展。

OAuth 2.0 Token Exchange 规范（RFC 8693）专门应对这一挑战，Amazon Bedrock AgentCore Identity 已原生将其作为凭证提供方支持的授权类型。借助该能力，AgentCore Gateway 能在调用下游工具前自动把入站用户令牌交换为 audience 受限的新令牌，代理自身无需实现交换逻辑。具体收益包括：跨租户边界的身份传递（sub 声明贯穿始终）、基于密码学的最小权限（每个下游调用对应独立的 aud 声明）、代理侧无额外交换代码以及基于开放标准的协议对齐。

对于面向多租户的代理，正确选项只有 OBO 令牌交换一种。服务账号冒充使每一个被攻陷的代理都能冒充任意用户对任意租户发起操作，直接转发用户令牌则要求入站令牌的 audience 恰好命中下游 API，这在多租户系统里几乎不可能成立，更不必说代理面前还有工具网关拦截。OBO 交换则由授权代理把入站主体令牌换成新令牌，sub 保留为原始用户、aud 锁定为下游 API、签名由下游 API 信任的授权服务器签发，从而获得密码学层面的单次调用单用户作用域。

在 OBO 交换中，入站令牌的 sub 声明被原样保留，aud 声明则被改写为下游服务，交换执行者由单独声明记录（RFC 8693 中的 act，Okta 中表现为 cid）。下游 API 因此能凭借同一令牌回答两个问题：被代理的是谁（sub），以及谁在执行该动作（actor claim）。授权决策应基于 sub，审计日志与限流决策则参考 actor。这种拆分是直接转发完全无法做到的，正是 OBO 模式的核心价值。

本文提供的参考实现 TravelBot 是一款多租户预订助手，承接 Acme 与 Globex 两个示例租户。完整示例代码将在发布后托管于 aws-samples/sample-obo-flow-poc 仓库。在整体方案中，AgentCore Gateway 拦截代理对工具的调用，识别目标租户后指示 Identity 完成与该租户授权服务器之间的令牌交换，然后再发起下游调用。这种设计把原本要在代理运行时、授权服务器和下游 API 三方对齐的工作压到网关内部，显著降低了协调负担，也避免了任一环节配置错误时安全姿态悄悄降级的风险。

要点

• OBO 令牌交换可让 AgentCore Gateway 自动把入站用户令牌转换为 audience 受限的下游令牌，无需改动代理代码。
• 跨租户调用中，sub 声明保留原始用户身份，aud 声明锁定具体下游服务，再配合 act 或 cid 记录执行者，从而实现最小权限审计。
• 服务账号冒充与直接令牌转发在多租户场景下都会引发混淆代理人问题，只有 OBO 交换能保留端到端用户身份。
• 实施 RFC 8693 需要代理运行时、授权服务器与下游 API 三方协同，AgentCore Gateway 与 Identity 简化了这一协调流程。
• TravelBot 参考实现展示了如何基于 Okta 完成端到端的多租户 OBO 配置，为生产化部署提供可复用模板。