Amazon Bedrock AgentCore Gateway 实现多租户 AI Agent 的 OBO 令牌交换指南
本文详细介绍了如何在 Amazon Bedrock AgentCore Gateway 中实现 OAuth 2.0 令牌交换（RFC 8693），以解决多租户 AI Agent 调用下游 API 时的身份传播和权限控制问题。通过 TravelBot 示例，展示了 JWT 声明转换、受众绑定等关键步骤，实现端到端用户身份保留和最小权限原则。
一句话看懂
AWS 发布 Bedrock AgentCore Gateway 实现指南，通过 OAuth 2.0 令牌交换解决多租户 AI Agent 调用下游 API 时的身份传播和权限控制问题。
详细发生了什么
AWS 官方博客发布了一篇实现指南，详细说明了如何在 Amazon Bedrock AgentCore Gateway 中实现 on-behalf-of (OBO) 令牌交换，以解决多租户 AI Agent 架构中的身份传播问题。当 Agent 代表用户调用下游 API 时，如果直接使用 Agent 的服务身份，会丢失审计线索；如果直接转发用户令牌，则可能引发“混乱的代理”（confused deputy）问题。OBO 模式通过 RFC 8693 标准，在每次调用下游服务时，将用户令牌交换为新的、受众绑定的令牌，既保留了原始用户的 sub 声明，又通过 aud 声明将令牌作用域限制在单个下游服务。
文章以 TravelBot（一个多租户预订助手）为例，展示了针对两个租户（Acme 和 Globex）的完整 OBO 设置。AgentCore Identity 原生支持 OAuth 2.0 令牌交换作为凭证提供者授权类型，Gateway 拦截器可以透明地执行交换，无需 Agent 代码参与。文章还对比了三种实现方式：服务账户模拟、直接用户令牌转发和 OBO 令牌交换，并明确指出只有 OBO 能同时满足端到端身份保留、最小权限和独立验证的要求。
中文圈视角
对于国内使用 AWS Bedrock 的开发者来说，这个模式有直接参考价值。多租户 SaaS 场景在国内同样普遍，例如为企业客户提供 AI 客服、数据分析 Agent 时，每个租户的数据和 API 权限必须隔离。OBO 模式通过令牌交换实现了租户级别的细粒度访问控制，避免了“一个 Agent 拥有所有租户权限”的安全风险。
国内云厂商如阿里云、腾讯云也提供类似的 Agent 构建服务，但原生支持 OBO 令牌交换的较少。开发者可能需要自行实现令牌交换逻辑，或依赖第三方 IdP（如 Authing、Okta 中国版）。此外，国内合规要求（如数据出境、等保）可能要求令牌交换在境内完成，部署时需注意 IdP 的物理位置。
一个值得关注的盲点是：国内很多 Agent 框架（如百度千帆、阿里百炼）目前更强调“插件”和“工具调用”的易用性，对身份传播和审计追踪的重视不足。随着多租户生产级部署需求增加，类似 OBO 的标准化身份模式会成为刚需。
几条值得记住的细节
- OBO 令牌交换基于 RFC 8693 标准，AgentCore Identity 原生支持作为凭证提供者授权类型。
- 每个下游调用都会获得一个全新的 JWT，其 aud 声明绑定到特定服务，sub 声明保留原始用户。
- 文章使用 Okta 作为 IdP 示例，但任何支持 token-exchange grant 的授权服务器均可替代。
- 直接用户令牌转发仅在单租户且受众匹配时可用，多租户场景必须使用 OBO。
- 参考实现 TravelBot 的代码将在 aws-samples/sample-obo-flow-poc 仓库发布。
一句话总结
多租户 AI Agent 必须用 OBO 令牌交换来保证身份隔离和审计完整性，AWS Bedrock 已提供原生支持。