当一个 AI 代理替用户在 ServiceNow 里提交工单、查询 CMDB 或审批变更请求时，ServiceNow 收到的 API 调用究竟挂着谁的身份？如果答案是”代理应用本身”，那么这个代理就拥有了一把万能钥匙——它能触及应用注册时被授予的全部权限，而与发起请求的最终用户毫无关系。审计日志里只留下一个应用 ID，用户级访问控制形同虚设，最小特权原则被彻底架空。

AWS 在其官方机器学习博客上发布的技术方案，直接瞄准了这个”身份黑洞”：通过 Amazon Bedrock AgentCore Gateway 的 on-behalf-of（OBO）令牌交换机制，与 Microsoft Entra ID 集成，让 AI 代理在调用 ServiceNow REST API 时保持最终用户的身份。配置发生在网关层，交换发生在每次请求时，代理框架代码无需改动。

这篇文章将拆解这一方案的技术架构、配置逻辑与生态定位。

1. 身份黑洞：代理调用企业 API 的根本性安全缺陷

企业 IT 系统的访问控制模型建立在一个基本假设之上：每个 API 调用都可以追溯到一个具体的人类用户，该用户的权限决定了调用能看到什么、能做什么。ITSM 平台如 ServiceNow 的权限体系尤其依赖这一假设——不同角色的用户看到不同的工单队列，审批链按组织层级流转，敏感配置项的读写权限精确到人。

AI 代理的引入打破了这个假设。据 AWS 官方博客描述，没有身份传播（identity propagation）时，”API calls arrive at downstream services as the application itself rather than the user who initiated the action”。这句话的技术含义非常精确：下游服务（如 ServiceNow）收到的 JWT 令牌中，subject claim 是应用的 service principal，而非发起操作的具体用户。

这导致3个直接后果，AWS 博客逐一点明：审计链断裂（breaks audit trails）、用户级访问控制被绕过（bypasses user-level access controls）、违反最小特权原则（violates the principle of least privilege）。

将这3个后果放到 ServiceNow 的具体场景中理解：如果代理以应用身份调用 ServiceNow Table API 查询 incident 表，ServiceNow 的 ACL 引擎会按照该应用对应的 ServiceNow 用户记录来评估权限。通常，为了让代理”能工作”，管理员会给这个应用用户授予较高权限——否则代理替任何用户操作时都可能碰到权限墙。结果是，一个普通 IT 支持人员通过代理发起的查询，实际上以管理员权限执行。权限被架构性地放大了。

这个问题并非 ServiceNow 独有。任何通过 OAuth 2.0 保护的企业 REST API，只要代理以自身应用身份而非用户身份调用，都面临同样的困境。AWS 博客明确指出，本方案描述的 OBO 模式”can be applied to other REST APIs protected by OAuth”。

2. OBO 令牌交换：在网关层完成身份转换的技术机制

理解 OBO 令牌交换的技术细节，需要先理解 OAuth 2.0 中”audience”（受众）这个概念。一个 JWT 令牌的 audience claim 指定了该令牌的预期接收方。代理应用从 Microsoft Entra ID 获取的令牌，其 audience 是代理自身的应用注册 client ID；而 ServiceNow 期望收到的令牌，其 audience 必须是 ServiceNow API connector 的 client ID。两个 client ID 不同，令牌不能直接复用。

AWS 博客用具体的占位符 ID 说明了这一点：代理的 client ID 形如 3ff88e17-XXXX-XXXX-XXXX-XXXXXXXXXXXX，ServiceNow API connector 的 client ID 形如 5d4a7a11-XXXX-XXXX-XXXX-XXXXXXXXXXXX。代理持有的令牌 audience 指向前者，ServiceNow 要求 audience 指向后者。

OBO 流程正是为了桥接这个差距。根据 AWS 博客的描述，AgentCore Gateway 执行以下步骤：将入站令牌（代理持有的、audience 指向代理 client ID 的令牌）发送到 Entra ID 的 token endpoint，同时附带代理应用的 client credentials、目标 scope，以及关键参数 requested_token_use: on_behalf_of。Entra ID 验证调用用户已同意委托（consented to the delegation），然后签发一个新令牌——这个新令牌的 audience 指向 ServiceNow API connector，但原始用户的 claims 保持不变（”with the original user’s claims intact”）。

ServiceNow 收到这个新令牌后，读取其中的 preferred_username claim，将其映射到 ServiceNow 内部的用户记录，然后按该用户的权限执行 API 调用。整个过程中，用户身份从代理应用穿透到了 ServiceNow，权限没有被放大。

架构的3个组件

AWS 博客描述的端到端架构涉及3个关键组件，通过 AgentCore Gateway 连接：

第1个组件：AI 代理应用。 该应用受 Microsoft Entra ID 保护，通过 OAuth 应用注册获得身份。用户首先获取一个 JWT 来调用代理（博客中标记为步骤1），代理随后使用一个 audience 指向自身应用注册的 JWT 向网关认证（步骤2）。

第2个组件：AgentCore Gateway 充当 MCP 服务器。 据 AWS 博客描述，Gateway 在代理与 ServiceNow 之间扮演 Model Context Protocol（MCP）服务器的角色。MCP 是当前 AI 代理生态中用于工具调用的标准化协议。Gateway 在此处不仅是协议适配层，更是身份转换层——它在步骤3中执行 OBO 令牌交换。

第3个组件：ServiceNow REST API。 配置了与 Microsoft Entra ID 关联的 inbound OAuth integration。ServiceNow 在步骤4中接收有效令牌，按 preferred_username claim 映射用户并执行权限评估。

这个架构的核心设计哲学是”配置在网关、执行在每请求”。OBO 令牌交换的配置写在 Gateway Target 上，一次配置完成后，AgentCore Gateway 在每次请求时自动执行交换。代理应用的代码不需要知道 OBO 流程的存在，不需要持有 ServiceNow API connector 的 client secret，不需要自己调用 Entra ID 的 token endpoint。身份转换的复杂性被完全封装在网关层。

3. 配置实操：从 Entra ID 到 Gateway Target 的关键步骤

AWS 博客提供了详细的配置指南，涉及 Microsoft Entra ID、ServiceNow 和 AgentCore Gateway 3个平台。以下是关键配置节点的技术分析。

Entra ID 侧：2个应用注册与 scope 声明

整个方案需要在 Microsoft Entra ID 中创建2个应用注册（application registrations）：1个代表 ServiceNow API connector，1个代表 AI 代理。

对于 ServiceNow API connector 的应用注册，关键操作是在”Expose an API”页面添加一个名为 user_impersonation 的 scope，使用默认的 Application ID URI。AWS 博客特别指出，”This scope is what the OBO flow requests when exchanging tokens”——这个 scope 就是 OBO 令牌交换时请求的目标权限范围。

这个 scope 的命名并非随意选择。user_impersonation 是 Microsoft Entra ID 生态中约定俗成的 scope 名称，表示”允许应用代表已登录用户访问资源”。当 AgentCore Gateway 向 Entra ID 的 token endpoint 发起 OBO 请求时，它会在请求中指定目标 scope 为 ServiceNow API connector 的 user_impersonation scope。Entra ID 据此判断：代理应用是否被授权请求这个 scope？用户是否同意了这个委托？两个条件都满足时，才签发新令牌。

对于 AI 代理的应用注册，据 AWS 博客说明，执行者需拥有至少 Application Developer 角色才能在 Entra ID 中注册应用。这是 Microsoft Entra ID 的标准权限要求，确保应用注册操作本身受到适当的访问控制。

ServiceNow 侧：inbound OAuth integration

AWS 博客要求配置者拥有 ServiceNow 实例的管理员权限，以配置 inbound OAuth integration。博客还提到，可以在 ServiceNow 开发者门户（developer.servicenow.com）创建个人开发者实例（PDI）用于测试。

ServiceNow 的 inbound OAuth integration 将 Entra ID 签发的令牌与 ServiceNow 的用户表关联。当 ServiceNow 收到一个 JWT 时，它提取 preferred_username claim（通常是用户的 UPN，如 john.doe@contoso.com），在 ServiceNow 的 sys_user 表中查找匹配的用户记录，然后以该用户的身份和权限执行后续的 API 操作。

这意味着 ServiceNow 中必须存在与 Entra ID 用户对应的用户记录，且用户名映射关系必须正确。这是一个容易被忽视的前置条件——如果 ServiceNow 中没有对应的用户记录，OBO 令牌虽然有效，但 ServiceNow 无法完成用户映射，API 调用将失败。

Gateway Target 配置：OBO 参数的注入点

AWS 博客反复强调的一个设计决策是：OBO 令牌交换的配置写在 Gateway Target 上。Gateway Target 是 AgentCore Gateway 中代表一个下游服务的配置实体。在本方案中，Gateway Target 代表 ServiceNow REST API。

在 Gateway Target 上配置 OBO 令牌交换，需要提供以下信息：代理应用的 client credentials（client ID 和 client secret）、Entra ID 的 token endpoint URL、目标 scope（即 ServiceNow API connector 的 user_impersonation scope）。配置完成后，AgentCore Gateway 在每次收到指向该 Target 的请求时，自动从入站令牌中提取用户身份，执行 OBO 交换，用新令牌替换原始令牌，再将请求转发给 ServiceNow。

这种”配置一次、每请求执行”的模式，将身份转换逻辑从代理代码中完全剥离。对于使用不同框架（如 LangChain、Strands Agents 或自定义框架）构建的代理，只要它们能向 AgentCore Gateway 提交带有有效 JWT 的请求，身份传播就自动生效。框架无关性是这个架构的重要特征。

4. 安全边界的纵深：OBO 与 Guardrails 的组合

AWS 博客在描述方案时提到了一个额外的安全层：”In production, you can additionally pair identity propagation with Amazon Bedrock Guardrails to filter harmful content and validate the agent’s inputs and outputs。”

这句话揭示了一个更完整的安全模型：OBO 令牌交换解决的是”以谁的身份调用”的问题，而 Bedrock Guardrails 解决的是”调用的内容是否安全”的问题。两者分别对应身份安全和内容安全，是代理安全的2个正交维度。

笔者判断，在生产环境中，仅有 OBO 令牌交换是不够的。即使代理以用户身份调用 ServiceNow，如果代理被提示注入（prompt injection）攻击，它可能在用户不知情的情况下执行用户权限范围内的恶意操作——比如批量关闭工单、修改配置项。OBO 确保了权限不被放大，但不能防止权限被滥用。Guardrails 在代理的输入和输出端进行内容过滤和验证，可以在一定程度上缓解这类风险。

5. 生态拼图：从连接到治理的 AgentCore Gateway 演进

将 ServiceNow OBO 方案置于 AgentCore Gateway 近期的能力扩展中，可以看到一条从”连接”到”治理”的演进路线。

身份安全层：ServiceNow OBO 方案

本文分析的 ServiceNow OBO 方案解决的问题是”代理以谁的身份调”：当代理调用下游 API 时，如何确保用户身份穿透到下游服务，权限不被放大。AgentCore Gateway 在此充当身份转换层。

数据治理层：EDB Postgres AI 语义层方案

据 AWS 机器学习博客发布的另一篇文章描述，EDB Postgres AI 将语义层置于 Postgres 数据库内部，通过 AIDB 扩展实现。据该博客介绍，业务语义通过标准 Postgres COMMENT 语句定义，表间关系通过外键推导连接路径，访问控制通过 Postgres GRANT 和行级安全（row-level security）实现。

这个方案的治理模型与 ServiceNow OBO 方案有一个共同的设计理念：权限执行发生在数据源侧，而非代理侧。在 OBO 方案中，ServiceNow 根据用户令牌执行 ACL 评估；在 EDB 方案中，Postgres 根据数据库角色执行 GRANT 和行级安全策略。据 EDB 博客描述，”two Postgres roles asking the same question get different answers”——同一个代理、同一段提示词、同一套工具，不同的数据库角色看到不同的数据。

据该博客介绍，EDB 方案通过 MCP 端点暴露工具目录，并注册为 AgentCore Gateway 上的 MCP Target。AgentCore Gateway 处理入站授权，AgentCore Identity 持有出站凭证。这与 ServiceNow OBO 方案的架构模式一致——Gateway 作为统一的入站安全层，Identity 作为出站凭证管理层。

将两个案例并列来看：ServiceNow OBO 解决”身份与权限”，EDB Postgres AI 解决”语义与数据治理”。两者共同构成了企业级代理部署的关键治理维度，而 AgentCore Gateway 是贯穿这些维度的基础设施层。

6. OBO 模式的可推广性与技术边界

AWS 博客明确指出，本方案描述的 OBO 模式可应用于 ServiceNow 之外的其他 OAuth 兼容 REST API。这一判断的技术基础是：OBO 令牌交换是 OAuth 2.0 的标准扩展（RFC 8693 Token Exchange 和 Microsoft Entra ID 的 OBO 流程），不依赖 ServiceNow 的特定实现。

笔者判断，该模式的可推广性取决于3个前置条件：

第1，下游服务必须支持基于 JWT claims 的用户映射。 ServiceNow 通过 preferred_username claim 映射用户。其他企业服务（如 Salesforce、SAP、Jira）是否支持类似的 JWT 用户映射机制，决定了 OBO 模式能否直接复用。大多数现代 SaaS 平台支持 OIDC/OAuth 2.0 集成，但具体的 claim 映射配置各有不同。

第2，身份提供者必须支持 OBO 令牌交换。 本方案使用 Microsoft Entra ID 作为身份提供者。对于使用 Okta、Ping Identity 或其他 IdP 的企业，需要确认其 IdP 是否支持 OBO 流程或等效的令牌交换机制。据 ietf.org，RFC 8693 定义了标准的 Token Exchange 协议 [3]，但各 IdP 的实现程度不一。

第3，AgentCore Gateway 必须支持目标 IdP 的令牌交换协议。 当前博客展示的是与 Microsoft Entra ID 的集成。AgentCore Gateway 是否已支持或计划支持其他 IdP 的 OBO 流程，截至本文发布时暂无公开数据。

OBO 模式的局限

OBO 令牌交换解决了”权限不放大”的问题，但它有一个固有局限：它要求用户在代理调用时已经完成了对委托的同意（consent）。据 AWS 博客描述，Entra ID 在执行 OBO 交换时会验证”the calling user consented to the delegation”。这意味着在用户首次使用代理之前，必须有一个同意流程——用户明确授权代理应用代表自己访问 ServiceNow。

在企业环境中，这个同意流程通常由 Entra ID 管理员通过”admin consent”批量完成，而非让每个用户逐一同意。但这引入了一个治理问题：admin consent 是一个全有或全无的开关，管理员一旦授予同意，所有用户都被纳入委托范围。如果企业希望只允许特定用户群组使用代理访问 ServiceNow，需要在 Entra ID 的应用注册中配置用户分配（user assignment），这增加了配置复杂度。

另一个需要注意的边界是令牌生命周期。OBO 交换产生的新令牌有自己的过期时间。如果代理执行一个长时间运行的任务（如跨多个 ServiceNow API 调用的复杂工作流），新令牌可能在任务完成前过期。AgentCore Gateway 如何处理令牌刷新——是自动刷新还是要求代理重新发起请求——博客中未详细说明。

7. 从”能不能调”到”以谁的身份调”

ServiceNow OBO 令牌交换方案标志着企业级 AI 代理安全讨论的一个转向：从”代理能不能调用企业 API”转向”代理以谁的身份调用企业 API”。

第1个问题在过去2年已经被大量的 API 集成方案、MCP 协议和工具框架基本解决。代理可以调用几乎任何有 REST API 的企业服务。第2个问题——身份传播——才是企业大规模部署代理时的真正卡点。

AWS 的方案将身份转换逻辑封装在 AgentCore Gateway 层，实现了3个解耦：代理框架与身份协议解耦（代理不需要知道 OBO 流程的存在）、身份配置与请求执行解耦（配置一次、每请求自动执行）、上游身份提供者与下游服务解耦（Gateway 在中间完成令牌的 audience 转换）。

笔者判断，这种网关层身份转换的模式，将成为企业级代理部署的标准架构模式。原因很简单：企业不会为每个代理框架、每个下游服务分别实现身份传播逻辑。它们需要一个集中的、可配置的、与代理框架无关的身份转换层。AgentCore Gateway 正在填补这个位置。

但这也意味着 AgentCore Gateway 本身成为了一个高价值攻击目标——它持有代理应用的 client credentials，能够为任何入站令牌执行 OBO 交换。Gateway 自身的安全加固、凭证存储方式、审计日志的完整性，将决定整个方案的安全上限。

企业 AI 代理的安全模型正在从”应用级信任”演进为”用户级信任”。OBO 令牌交换是这个演进中的一个关键机制，而 AgentCore Gateway 是将这个机制从理论变为可部署方案的基础设施。

主题分类：企业AI落地

参考资料

  1. ServiceNow on-behalf-of token exchange with Bedrock AgentCore Gateway — AWS Machine Learning Blog, 2026-11-03
  2. Build a semantic layer for agentic AI with EDB Postgres AI and Amazon Bedrock AgentCore — AWS Machine Learning Blog, 2026-11-03
  3. RFC 8693 - OAuth 2.0 Token Exchange — IETF