通过 Bedrock AgentCore Gateway 实现 ServiceNow 代理令牌交换

在企业级 AI 应用场景中，智能体往往需要以用户身份调用各类内部系统 API。若 API 调用以应用程序自身而非发起操作的用户身份到达下游服务，审计日志将无法追溯真实操作者，用户级访问控制形同虚设，最小权限原则也随之被打破。Amazon Bedrock AgentCore 正是为解决这一痛点而设计的智能体构建与优化平台，其核心能力之一 AgentCore Gateway 可在不引入任何自定义代码的前提下，原生完成 OBO 令牌交换。

整体方案架构围绕三个关键组件展开。首先，AI 智能体应用通过 Microsoft Entra ID 的 OAuth 应用注册获得保护；其次，AgentCore Gateway 以 MCP 服务器形式作为智能体与 ServiceNow 之间的中间层；最后，ServiceNow REST API 配置了与 Entra ID 绑定的入站 OAuth 集成。用户在发起请求时获取 JWT，智能体携带该令牌向网关认证，网关再通过 OBO 流程向 Entra 令牌端点申请一个新令牌，新令牌的受众声明指向 ServiceNow API 连接器，而非智能体本身的客户端 ID。

OBO 令牌交换的核心逻辑在于弥合两个应用注册之间的受众差异。智能体持有的 JWT 受众为其自身客户端 ID，而 ServiceNow 期望收到受众为其 API 连接器客户端 ID 的令牌。AgentCore Gateway 在每次请求时，将入站令牌连同智能体的客户端凭据、目标作用域以及 requested_token_use: on_behalf_of 参数一并发送至 Entra 令牌端点。Entra 验证用户已授权委托后，签发一个携带原始用户声明的新令牌，整个过程对上下游均透明。

在 Microsoft Entra ID 侧，需要创建两个应用注册：一个代表 ServiceNow API 连接器，另一个代表 AI 智能体。ServiceNow API 连接器注册需暴露名为 user_impersonation 的作用域，这是 OBO 流程交换令牌时所请求的目标作用域。智能体注册则需创建客户端密钥，并配置调用 ServiceNow API 连接器应用的 API 权限。上述配置与标准 OBO 集成无异，无需额外的 Entra 特殊设置。

在 ServiceNow 侧，需在管理控制台的系统 OAuth 入站集成中新建一条集成记录，类型选择支持 OIDC 身份提供商的第三方 ID 令牌，并填入 Entra 租户的 OIDC 元数据 URL。用户声明映射是关键步骤：若 Entra 将用户邮箱置于 preferred_username 声明中，则需将其映射至 ServiceNow 的 Email 字段，确保令牌到达后能正确识别用户身份并应用对应权限。此外，建议将 Entra 的 uti 声明映射为 jti，以提供额外的重放保护能力。

该方案的价值不仅限于 ServiceNow 场景。任何受 OAuth 保护的 REST API，只要支持 OBO 流程，均可复用相同的网关配置模式。在生产环境中，还可将身份传播与 Amazon Bedrock Guardrails 结合使用，对智能体的输入输出进行有害内容过滤与合规校验，进一步强化企业级安全防护。AgentCore Gateway 原生承担令牌交换职责，使开发团队得以专注于业务逻辑，而非身份管道的维护。

要点

• AgentCore Gateway 原生支持 OBO 令牌交换，无需编写拦截器 Lambda 或任何自定义代码，显著降低身份传播的实现复杂度。
• OBO 流程通过在网关层替换令牌受众声明，确保 ServiceNow 等下游系统收到的令牌携带真实用户身份，审计链与最小权限原则得以完整保留。
• Entra ID 侧仅需两个标准应用注册及 user_impersonation 作用域配置，与常规 OBO 集成无差异，迁移成本低。
• ServiceNow 的用户声明映射配置是身份识别的关键，preferred_username 与用户邮箱字段的正确对应直接决定权限应用是否准确。
• 该架构模式可推广至所有支持 OAuth OBO 流程的 REST API，具备较强的通用性与可复用性。