Amazon Bedrock AgentCore Gateway 如何实现 ServiceNow 的 on-behalf-of 令牌交换

企业 API 场景中，AI 智能体代用户发起调用时若不做身份传递，下游服务只会看到应用自身身份，导致审计链断裂、绕过用户级访问控制并违反最小权限原则。Amazon Bedrock AgentCore Gateway 通过在网关目标上配置 on-behalf-of（OBO）令牌交换解决这一问题，网关对每个请求自动完成交换，使智能体调用 ServiceNow REST API 时保留发起用户的身份。 方案由三部分组成：受 Microsoft Entra ID 保护的智能体应用、以 AgentCore Gateway 实现的 MCP 服务器，以及配置了入站 OAuth 集成的 ServiceNow REST API。用户先获取 JWT 调用智能体，智能体以自身应用注册为范围的 JWT 向网关认证，网关再通过 OBO 流程换取面向 ServiceNow API connector 的新令牌，原用户身份保持不变；ServiceNow 收到令牌后，将 preferred_username claim 映射到已有用户并按其权限执行调用。 OBO 交换的关键在于 audience claim 的差异：智能体令牌的 audience 对应自身 client ID，而 ServiceNow 期望的 audience 是其 API connector 的 client ID。网关将入站令牌连同智能体应用凭据、目标 scope 和 requested_token_use: on_behalf_of 参数发送至 Entra 令牌端点，Entra 校验用户已同意委派后签发保留原用户 claims 的新令牌。 配置流程覆盖三侧：在 Entra ID 中为 ServiceNow API connector 创建应用注册并暴露 user_impersonation scope，为智能体创建应用注册、生成 client secret 并授予调用 API connector 的权限；在 ServiceNow 中创建入站集成、配置 OIDC provider 并映射用户 claim，同时将 auth scope 限制到 Table API；在 AgentCore 中创建 outbound auth 配置并选择 JWT authorization grant，创建网关时须选用 MCP version 2025-11-25，该版本才支持原生 OBO，早期版本无法开启。 随后为网关添加指向 ServiceNow REST 端点的目标，以内联 OpenAPI schema 暴露工具（如 ListIncidents），出站认证选择前述 OAuth 配置并启用 Token exchange grant，scope 填 api://<connector-id>/user_impersonation。生产环境还可结合 Amazon Bedrock Guardrails 过滤有害内容并校验智能体输入输出。