ServiceNow 与 Bedrock AgentCore Gateway 的 on-behalf-of 令牌交换配置

AI 智能体代表用户调用企业 API 时，如果请求链路上不传递用户身份，下游服务看到的调用方就是应用本身，而不是发起操作的用户。这会破坏审计记录、绕过用户级访问控制，也违背最小权限原则。AWS 的这篇技术文章给出了一个具体做法：在 Amazon Bedrock AgentCore Gateway 上配置 on-behalf-of（OBO）令牌交换，让智能体调用 ServiceNow REST API 时保留调用用户身份。

方案由三部分组成

架构中有三个关键组件，通过 AgentCore Gateway 连接：

• 受 Microsoft Entra ID 保护的 AI 智能体应用，通过 OAuth 应用注册接入；
• 用 AgentCore Gateway 实现的 Model Context Protocol（MCP）服务器，位于智能体与 ServiceNow 之间；
• 配置了入站 OAuth 集成的 ServiceNow REST API，该集成与 Microsoft Entra ID 关联。

请求流程是：用户先取得 JSON Web Token（JWT）调用智能体；智能体用自身应用注册范围内的 JWT 向网关认证；网关通过 OBO 流程把该令牌换成面向 ServiceNow API 连接器的新令牌，并保留原用户身份；ServiceNow 收到令牌后，将 preferred_username 声明映射到已有用户，按该用户权限执行 API 调用。

OBO 交换解决的是什么问题

智能体调用网关时出示的 JWT，其 audience 声明对应智能体自己的 client ID；而 ServiceNow 期望的令牌 audience 对应它自己的 API 连接器 client ID。OBO 流程负责弥合这一差异：AgentCore Gateway 把入站令牌连同智能体应用的客户端凭据、目标范围和 requested_token_use: on_behalf_of 参数发送到 Entra 令牌端点。Entra 验证调用用户已同意该委托后，签发一个面向 ServiceNow API、保留原用户声明的新令牌。

前置条件与配置要点

开始前需要：可访问 AgentCore Gateway 的 AWS 账户；有创建应用注册权限的 Microsoft Entra ID 租户，账户至少具备 Application Developer 角色；有管理入站 OAuth 集成权限的 ServiceNow 实例；以及两个 Entra 应用注册，分别代表 AI 智能体和 ServiceNow API 连接器。

在 Entra 侧，先为 ServiceNow API 连接器创建应用注册，记录 Application (client) ID，并在 Expose an API 中用默认 Application ID URI 添加名为 user_impersonation 的范围，这是 OBO 流程请求的范围。再为 AI 智能体创建应用注册，记录其 client ID 并创建客户端密钥，网关执行 OBO 交换需要这组凭据；随后为该智能体应用配置调用 ServiceNow API 连接器应用的 API 权限。文章指出，除标准 OBO 集成所需配置外，Entra 侧无需额外改动。

在 ServiceNow 侧，进入 System OAuth > Inbound Integrations 新建入站集成（第三方 ID token，由支持 OIDC 的身份提供方签发），填入 Entra 中 ServiceNow API 连接器应用注册的 client ID，并在同一界面创建 OpenID Connect（OIDC）提供方配置。

编辑部观察

这篇文章的价值在于把“身份透传”从原则落到了可操作的网关配置：令牌交换发生在网关目标上，由 AgentCore Gateway 对每个请求执行，业务代码不必自行处理多段令牌。文章也明确该模式适用于其他受 OAuth 保护的 REST API，并提到生产环境可将身份透传与 Amazon Bedrock Guardrails 搭配，用于过滤有害内容、校验智能体输入输出。

需要留意的是，文章给出的是配置路径与组件关系，未披露性能数据、价格或可用区域信息；实际落地前，读者应自行核对 Entra 委托同意流程、ServiceNow 用户映射规则以及网关目标的具体参数。