产品 AWS Machine Learning·原文 2026年11月4日

AWS介绍AgentCore Gateway原生on-behalf-of令牌交换，让AI代理以用户身份调用ServiceNow API

AWS机器学习博客发文，说明如何在Amazon Bedrock AgentCore Gateway上配置on-behalf-of（OBO）令牌交换，使AI代理调用ServiceNow REST API时保留发起请求用户的身份，无需再写Lambda拦截器。

AI解读：AWS的说法是，AgentCore Gateway可在网关目标上直接完成OBO令牌交换，调用ServiceNow时保留用户身份，因此不需要维护自定义Lambda拦截器。来源没有给出延迟、成本或安全测试数据，这一“去掉自定义代码”的判断只在配置流程范围内成立。

要使用原生OBO，来源给出的硬性条件是网关必须选择MCP版本 2025-11-25，更早版本创建的网关无法开启该功能。此外目标侧需配置scope（如api://<ServiceNow连接器客户端ID>/user_impersonation）和自定义参数requested_token_use=on_behalf_of；缺少该参数时Entra不会执行OBO交换，调用会因认证失败而报错。

适用对象是使用Microsoft Entra ID做身份管理、并希望代理以具体用户权限访问ServiceNow的组织；来源称同样模式可用于其他由OAuth保护的REST API，但演示只覆盖ServiceNow Table API的查询场景。

用户身份匹配依赖令牌中preferred_username声明映射到ServiceNow现有用户，映射不上则认证出错。代理能否实际操作，还受ServiceNow侧授权范围限制，来源建议把auth scope限制在Table API或代理实际需要的接口。

AWS机器学习博客发布教程，介绍如何把Amazon Bedrock AgentCore Gateway配置为使用on-behalf-of（OBO）令牌交换，让AI代理在调用ServiceNow REST API时保留发起操作的用户身份。文章作者Greg Biegel称，该交换在网关目标上配置后由网关在每次请求时执行，无需自定义代码。

博客给出的背景是：代理代表用户访问企业API时，如果身份不向下游传递，API调用会以应用自身身份到达下游服务，而不是发起操作的用户，这会破坏审计记录、绕过用户级访问控制。

教程架构包含三部分：由Microsoft Entra ID通过OAuth应用注册保护的代理应用、作为MCP服务器的AgentCore Gateway，以及配置了绑定Entra ID的入站OAuth集成的ServiceNow REST API。

令牌交换的流程与配置条件

按文章描述，用户先取得JWT调用代理；代理由自身应用注册的JWT向网关认证；网关用OBO流程把该令牌换成面向ServiceNow API连接器的令牌；ServiceNow收到令牌后，按preferred_username声明匹配现有用户，并套用该用户的权限。

配置上需要在Entra ID创建两个应用注册：一个代表ServiceNow API连接器，并暴露user_impersonation范围；一个代表AI代理，并创建客户端密钥、授予调用前者的API权限。ServiceNow侧要新建入站集成和OIDC提供方配置，映射用户声明，并创建授权范围。

在AgentCore侧，先建出站认证配置，选Customized provider，填入代理应用客户端ID、密钥和Entra discovery URL，并在附加配置中选JWT authorization grant；再创建网关，必须选MCP版本 2025-11-25，文章明确该版本是原生OBO的前提，更早版本创建的网关无法开启。最后添加指向ServiceNow REST端点的目标，出站认证选OAuth，并在附加配置中选Token exchange grant。

必需参数：scope填ServiceNow连接器应用注册上暴露的api://<客户端ID>/user_impersonation，自定义参数requested_token_use填on_behalf_of。
文章提醒，缺少requested_token_use参数时Entra不执行OBO交换，调用ServiceNow会返回认证错误。
ServiceNow侧建议把授权范围限制在Table API或代理实际需要的API；示例用ListIncidents工具调用Table API查询事件记录。
文章还提到，生产中可将身份传递与Amazon Bedrock Guardrails搭配，用于过滤有害内容并校验代理的输入输出。