人工智能
ServiceNow与贝德罗克特工Core Gateway的半个代号交换
AI agents代表用户与企业API互动，需要在整个请求链中保持用户身份。 没有身份宣传，API的呼叫就随着应用程序本身而不是发起行动的用户而到达下游服务。 这打破了审计线索，绕过用户级别的访问控制，违反了最少特权的原则。
Amazon Bedrock Agent Core是一个在规模上构建，连接，优化agents的平台，拥有任何框架或模型。 此帖子显示如何配置 Agent Core Gateway，是 Amazon Bedrock Agent Core 的一种能力，用于与 Microsoft Entra ID 进行半(OBO)符号交换。 AI agent随后可以给ServiceNow REST API打电话，同时保留呼叫用户的身份。 您在网关目标上配置符号交换，Agent Core Gateway 执行每次请求的交换。 该模式可以应用于OAuth保护的其他REST API.
在生产过程中，您可使用Amazon Bedrock Guardrail进行额外的对称身份传播，过滤有害内容并验证agent的输入和输出。
解决方案概述
该架构涉及通过Agent Core Gateway连接的三个关键组件：
- AI agent申请，通过OAuth申请登记得到Microsoft Entra ID的保护。
- 一个模式背景协议(MCP)服务器，使用Agent Core Gateway执行，坐落在agent和ServiceNow之间。
- ServiceNow REST API，配置为与Microsoft Entra ID绑定的入境OAuth集成。
下图显示端对端解决方案架构，包括AWS内部的组件，Microsoft Entra ID，以及ServiceNow.
如图1所示，用户收购 a JSON Web Token(JWT)引用agent 1. agent认证为网关，带有JWT标志，范围为agent自己的申请注册2. 然后，该网关用OBO流量交换该标志，换成ServiceNow API连接器的新标志，原用户身份保存3. ServiceNow收到一个有效的符号，其首选的用户名对已有的ServiceNow用户的主张地图，并将该用户的权限应用于API调用4.
OBO 信使交换如何在这方面发挥作用
当agent调用网关时，它会呈现一个JWT的观众称号与agent的客户端ID相匹配(例如3ff88e17-XXXX-XXXX-XXXX-XXXXXXXXXXXX-XXXXXXXXXXXX). 然而，ServiceNow期望有一个与自己的API连接器客户端ID(5d4a7a11-XXXX-XXXX-XXXX-XXXXXXXXXXXX-XXXXXXXXXXXX)相匹配的观众称号的代号。
OBO的流量弥补了这一缺口。 Agent Core Gateway 向 Entra 令牌端点发送入境令牌，同时发送 agent 应用程序的客户端证书，目标范围，以及请求的参数 token use: on bess of. Entra证实打电话的用户同意代表团，然后为ServiceNow API发行了新的代号，原用户的声称完好无损。
先决条件
在开始前，您需要以下内容：
-AWS账户访问Core Gateway探员
- Microsoft Entra身份证租户，有权建立申请登记。 您的账户至少需要应用程序开发者的角色来注册应用程序。
- ServiceNow实例，可进行行政访问，配置入境的OAuth集成。 您可以在 ServiceNow 个人开发者实例注册页面 https://developer.servicenow.com/ 创建 ServiceNow个人开发者实例(PDI).
- 两个Entra申请注册：一个代表AI agent，一个代表ServiceNow API连接器。
配置 Microsoft 密码
首先创建一个应用程序注册，以代表ServiceNow API连接器。 以下截图为Microsoft Entra ID中的ServiceNow API连接器的应用注册页。
在创建后，在概览页中注释应用程序(客户端)ID.
在导航菜单中扩展管理并选择 Expose API，并使用默认的应用程序 ID URI 添加一个名为 user imperation 的范围。 这个范围是OBO在交换令牌时要求的。 以下截图显示如何在 Microsoft Entra ID中曝光 API.
接下来为AI agent创建申请注册。 以下截图为Microsoft Entra ID中的显示应用程序注册页面，用于ServiceNow Agent应用程序。
请注意ServiceNow代理的应用程序(客户)ID。
在此注册上创建客户端秘密。 网关需要这些证书才能进行OBO交换。 以下截图显示如何在 Microsoft Entra ID 的应用程序注册上创建客户端秘密。
然后配置 agent 应用程序，以拥有 API 权限来调用 ServiceNow API 连接器应用程序。 以下截图显示您需要配置在 Microsoft Entra ID 中的 ServiceNow Agent 应用程序注册上的 API 权限。
Entra 配置不需要修改，超出您为两个应用程序之间任何标准 OBO 集成而设置的配置。
配置 ServiceNow
在ServiceNow行政控制台中，导航到System OAuth > 入境集成，并创建一个新的入境集成(由OIDC支持身份提供者发行的第三方ID令牌). 从您在 Entra 创建的 ServiceNow API 连接程序注册中指定客户端ID。 以下截图为显示在ServiceNow的入境集成配置。
在同一屏幕中，创建新的 OpenID 连接(OIDC)提供者配置，并为您的 Entra 租户输入 OIDC 元数据 URL。 将用户要求映射到适当的用户字段。 例如，如果您的 Entra 租户将用户的电子邮件放入首选的用户名要求中，请将它映射到ServiceNow的电子邮件字段。 如果你的 Entra 租户没有将它列为代币，请明确 JTI 的验证。 Entra在它发出的信物上使用了一种名为uti的内部主张，这相当于JTI. 考虑将这一未动用的主张绘制为jti主张，以提供额外的回放保护和拒绝列名。 以下截图显示如何配置 ServiceNow 中的 OIDC 提供者。
最后，在同一屏幕中，创建集成的认证范围(例如APIConnector). 以下截图显示如何在 ServiceNow 创建新的认证范围。
将认证范围限制在表 API 上，或以 ServiceNow API 为准，您 agent 需要访问，如下图所示。
在此配置完成后，ServiceNow 接受您 API 连接器客户端ID 的受众的授权符，并从首选的用户名请求中解决调用用户。
配置代理 Core 网关
随着Entra和ServiceNow的配置，现在可以设置Agent Core Gateway来本土处理OBO交换。
步骤1：创建外部认证配置
在 AgentCore 中创建一个新的外向认证配置(choose Building > ID > 添加外向认证 > 添加 OAuth 客户端)，并选择自定义的提供者。 从您的 agent 应用程序注册中输入客户端ID 和客户端机密，以及以下截图显示的 Entra 发现 URL。
扩展附加配置，并选择JWT授权授权，如下截图所示。 这告诉网关使用基于JWT的赠款类型进行象征性交换。
第2步：用MCP版本创建网关 2025-11-25
创建新的代理 Core 网关( 新建 > 网关 > 创建网关)。 在定义网关细节时，扩展附加配置——可选，并选择MCP版本2025-11-25，如下截图所示。 本地的OBO支持需要这个版本。 无法打开本地的OBO
使用您的 agent 的应用程序注册( 选择使用现有的身份提供者配置) 配置输入身份，就像您对接受 Entra 认证请求的任何网关一样。
在 JWT 授权配置下，添加我们先前为 ServiceNow Agent 记录的应用程序 ID，如以下截图所示。
步骤 3：添加一个带有符号交换的目标
将目标添加到指向您的 ServiceNow REST 端点的网关中。 定义内含的策略。 例如，要曝光一个名为ListIncents的工具，它叫ServiceNow Table API，您可以使用以下的OpenAPI规格(替换服务器的URL，换成您的PDI).
以下截图显示如何用 OpenAPI 计划配置 Agent Core Gateway 中的 REST API 目标。
对于目标上的Outround Auth配置，选择OAuth作为Outround的身份提供者，并选择您在步骤1中创建的Outround Auth配置。
现在扩展附加配置部分并选择Token交换赠款。 配置如下：
范围：api://5d4a7a11-xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
这是您在 Entra 的 ServiceNow API 连接器申请注册上所暴露的范围。
自定义参数( 键值对)：请求的 token use: on bemal of
这一参数至关重要。 Entra不执行OBO交换
最终配置如下截图所示。
步骤4：保存和测试
保存目标配置。 Agent Core Gateway 现在自动交换有效ServiceNow令牌的入境令牌，保留用户身份，没有自定义代码。
当agent调用网关时，以下会透明地发生：
- 网关接收agent的JWT(听众：agent客户端ID).
- 网关向Entra的标志端点发送OBO赠款。
- Entra发布新的代号(听众：ServiceNow API连接客户端ID)，与原用户的声称。
- 网关将请求与交换符一起转发到ServiceNow。
- ServiceNow从符中解析用户并应用其权限。
下面的代码片断显示是一个通过MCP服务器与ServiceNow相互作用的最小聊天agent.
解决问题
如果您收到ServiceNow认证错误，请核实：
- 交换符号地图中首选的用户名要求到ServiceNow的有效用户电子邮件。
-ServiceNow入境集成的认证范围允许进入你的agent呼叫的API端点
- agent应用程序在Entra拥有ServiceNow API连接器应用程序的API权限。
清理
为避免持续收费，如果创建用于测试，则删除以下资源：
- Core Gateway探员及其目标
- 外向的认证配置。
- Entra应用程序注册(如果是专门为这种走过而创建的)。
- ServiceNow入境集成和OIDC供应商配置。
结论
在Agent Core Gateway的本地OBO支持取消了定制AWS Lambda拦截器执行符号交换的需要。 您直接在网关目标上配置符号交换，网关在每次请求时都会透明地处理它。 这种方法在整个agent到API链中保持用户身份，支持ServiceNow的用户级访问控制，并取消了需要单独维护的自定义代码。
要从Core Gateway探员开始，请参见Amazon Bedrock探员Core文档。 更多关于Microsoft Entra的OBO流量，请参见Microsoft身份平台文件。
本文由 AI图鉴自动抓取并翻译，版权归原作者所有；如需查看原文请点下方链接。
Artificial Intelligence
ServiceNow on-behalf-of token exchange with Bedrock AgentCore Gateway
AI agents that interact with enterprise APIs on behalf of users need to maintain user identity throughout the request chain. Without identity propagation, API calls arrive at downstream services as the application itself rather than the user who initiated the action. This breaks audit trails, bypasses user-level access controls, and violates the principle of least privilege.
Amazon Bedrock AgentCore is a platform to build, connect, and optimize agents at scale, with any framework or model. This post shows how to configure AgentCore Gateway, a capability of Amazon Bedrock AgentCore, for an on-behalf-of (OBO) token exchange with Microsoft Entra ID. An AI agent can then call the ServiceNow REST API while preserving the calling user’s identity. You configure the token exchange on the gateway target, and AgentCore Gateway performs the exchange on each request. The pattern can be applied to other REST APIs protected by OAuth.
In production, you can additionally pair identity propagation with Amazon Bedrock Guardrails to filter harmful content and validate the agent’s inputs and outputs.
Solution overview
The architecture involves three key components connected through AgentCore Gateway:
- An AI agent application, protected by Microsoft Entra ID through an OAuth application registration.
- A Model Context Protocol (MCP) server, implemented using AgentCore Gateway, sitting between the agent and ServiceNow.
- The ServiceNow REST API, configured with an inbound OAuth integration tied to Microsoft Entra ID.
The following figure shows the end-to-end solution architecture, including components within AWS, Microsoft Entra ID, and ServiceNow.
As shown in Figure 1, the user acquires a JSON Web Token (JWT) to invoke the agent 1. The agent authenticates to the gateway with a JWT token scoped to the agent’s own application registration 2. The gateway then exchanges that token, using the OBO flow, for a new token scoped to the ServiceNow API connector, with the original user’s identity preserved 3. ServiceNow receives a valid token whose preferred_username claim maps to an existing ServiceNow user and applies that user’s permissions to the API call 4.
How OBO token exchange works in this context
When the agent calls the gateway, it presents a JWT with an audience claim matching the agent’s client ID (for example, 3ff88e17-XXXX-XXXX-XXXX-XXXXXXXXXXXX). ServiceNow, however, expects a token with an audience claim matching its own API connector client ID (5d4a7a11-XXXX-XXXX-XXXX-XXXXXXXXXXXX).
The OBO flow bridges this gap. AgentCore Gateway sends the inbound token to the Entra token endpoint along with the agent application’s client credentials, the target scope, and a parameter requested_token_use: on_behalf_of. Entra validates that the calling user consented to the delegation, then issues a new token for the ServiceNow API with the original user’s claims intact.
Prerequisites
Before you begin, you need the following:
- An AWS account with access to AgentCore Gateway.
- A Microsoft Entra ID tenant with permissions to create application registrations. Your account needs at least the Application Developer role to register applications.
- A ServiceNow instance with administrative access to configure inbound OAuth integrations. You can create a ServiceNow personal developer instance (PDI) at the ServiceNow personal developer instance signup page https://developer.servicenow.com/.
- Two Entra application registrations: one representing the AI agent, and one representing the ServiceNow API connector.
Configuring Microsoft Entra ID
Start by creating an application registration to represent the ServiceNow API connector. The following screenshot shows the application registration page for the ServiceNow API Connector in Microsoft Entra ID.
After creating, in the Overview page note the Application (client) ID.
In the navigation menu expand Manage and select Expose an API and add a scope named user_impersonation using the default Application ID URI. This scope is what the OBO flow requests when exchanging tokens. The following screenshot shows how to expose an API in Microsoft Entra ID.
Next, create an application registration for the AI agent. The following screenshot shows the application registration page in Microsoft Entra ID for the ServiceNow Agent application.
Note the Application (client) ID for the ServiceNowAgent.
Create a client secret on this registration. The gateway needs these credentials to perform the OBO exchange. The following screenshot shows how you can create a client secret on the ServiceNow Agent application registration in Microsoft Entra ID.
Then configure the agent application to have API permissions to call the ServiceNow API connector application. The following screenshot shows the API permissions that you need to configure on the ServiceNow Agent application registration in Microsoft Entra ID.
No changes to the Entra configuration are needed beyond what you would set up for any standard OBO integration between two applications.
Configuring ServiceNow
In the ServiceNow administrative console, navigate to System OAuth > Inbound Integrations and create a new inbound integration (Third party ID token issued by OIDC supporting identity provider). Specify the client ID from the ServiceNow API connector application registration you created in Entra. The following screenshot shows the configuration of the inbound integration in ServiceNow.
In the same screen, create a new OpenID Connect (OIDC) provider configuration and enter the OIDC metadata URL for your Entra tenant. Map the user claim to the appropriate user field. For example, if your Entra tenant places the user’s email in the preferred_username claim, map that to the Email field in ServiceNow. Clear JTI verification if your Entra tenant doesn’t include it in tokens. Entra uses an internal claim named uti on tokens it issues, which is equivalent to JTI. Consider mapping this uti claim to a jti claim to provide additional replay protection and denylisting. The following screenshot shows how to configure the OIDC provider in ServiceNow.
Finally, in the same screen, create an auth scope for the integration (for example, APIConnector). The following screenshot shows how to create a new auth scope in ServiceNow.
Limit the auth scope to the Table API, or whichever ServiceNow APIs your agent needs to access, as shown in the following screenshot.
After this configuration is complete, ServiceNow accepts authorization tokens with an audience of your API connector’s client ID and resolves the calling user from the preferred_username claim.
Configuring AgentCore Gateway
With Entra and ServiceNow configured, you can now set up AgentCore Gateway to handle the OBO exchange natively.
Step 1: Create an outbound auth configuration
Create a new outbound auth configuration (choose Build > Identity > Add Outbound Auth > Add OAuth client) in AgentCore and select Customized provider. Enter the client ID and client secret from your agent application registration, along with the Entra discovery URL as shown in the following screenshot.
Expand Additional configurations and select JWT authorization grant as shown in the following screenshot. This tells the gateway to use a JWT-based grant type for token exchange.
Step 2: Create the gateway with MCP version 2025-11-25
Create a new AgentCore Gateway (Build > Gateways > Create gateway). When defining the gateway details, expand Additional configurations — optional and select MCP version 2025-11-25 as shown in the following screenshot. This version is required for native OBO support. You can’t turn on native OBO for gateways created with earlier MCP versions.
Configure the inbound identity using your agent’s application registration (select Use existing identity provider configurations), as you would for any gateway that accepts Entra-authenticated requests.
Under JWT Authorization Configuration add the Application ID we documented earlier for the ServiceNowAgent as shown in the following screenshot.
Step 3: Add a target with token exchange
Add a target to the gateway pointing to your ServiceNow REST endpoint. Define the schema inline. For example, to expose a tool called ListIncidents that calls the ServiceNow Table API, you can use the following OpenAPI specification (replace the server URL with that for your PDI).
The following screenshot shows how to configure the REST API target in AgentCore Gateway with the OpenAPI schema.
For the Outbound Auth configuration on the target, select OAuth as the outbound identity provider and choose the outbound auth configuration you created in Step 1.
Now expand the Additional configurations section and select Token exchange grant. Configure the following:
Scope: api://5d4a7a11-xxxx-xxxx-xxxx-xxxxxxxxxxxx/user_impersonation
This is the scope you exposed on the ServiceNow API connector application registration in Entra.
Custom parameter (key-value pair): requested_token_use:on_behalf_of
This parameter is critical. Without it, Entra doesn’t perform the OBO exchange and the call to ServiceNow fails with an authentication error.
The final configuration is shown in the following screenshot.
Step 4: Save and test
Save the target configuration. AgentCore Gateway now automatically exchanges inbound tokens for valid ServiceNow tokens, preserving user identity, with no custom code.
When an agent calls the gateway, the following happens transparently:
- The gateway receives the agent’s JWT (audience: agent client ID).
- The gateway sends the token to Entra’s token endpoint with the OBO grant type.
- Entra issues a new token (audience: ServiceNow API connector client ID) with the original user’s claims.
- The gateway forwards the request to ServiceNow with the exchanged token.
- ServiceNow resolves the user from the token and applies their permissions.
The following code snippet shows a minimal chat agent that interacts with ServiceNow through the MCP server.
Troubleshooting
If you receive authentication errors from ServiceNow, verify that:
- The preferred_username claim in the exchanged token maps to a valid user email in ServiceNow.
- The auth scope on the ServiceNow inbound integration permits access to the API endpoints your agent is calling.
- The agent application has API permissions to the ServiceNow API connector application in Entra.
Cleaning up
To avoid ongoing charges, delete the following resources if you created them for testing:
- The AgentCore Gateway and its targets.
- The outbound auth configuration.
- The Entra application registrations (if created specifically for this walkthrough).
- The ServiceNow inbound integration and OIDC provider configuration.
Conclusion
The native OBO support in AgentCore Gateway removes the need for custom AWS Lambda interceptors to perform token exchanges. You configure the token exchange directly on the gateway target, and the gateway handles it transparently on every request. This approach maintains user identity across the agent-to-API chain, supports ServiceNow’s user-level access controls, and eliminates custom code that would need to be maintained separately.
To get started with AgentCore Gateway, see the Amazon Bedrock AgentCore documentation. For more on Microsoft Entra’s OBO flow, refer to the Microsoft identity platform documentation.
Auto-fetched and translated by AI Atlas. All rights belong to the original author.