ServiceNow 令牌交换接入 Bedrock AgentCore Gateway

AWS 已记录了通过 Amazon Bedrock AgentCore Gateway 实现的 ServiceNow 令牌交换方案，移除了身份委派路径中的自定义 Lambda 拦截器。其 11 月 3 日发布的演练展示了如何将 AI agent 连接至 ServiceNow，同时保留发起请求者的身份。这一变化将一项常规安全操作纳入托管网关。

该机制采用代表身份授权（on-behalf-of，简称 OBO），使中介能够代表已登录用户请求下游访问权限。Microsoft Entra ID，即 Microsoft 的身份服务，负责签发凭据。ServiceNow 则继续负责决定该用户可以访问哪些内容。

对企业开发者而言，核心比较在于：采用托管委派，还是维护自定义令牌交换组件。AWS 现已为这一集成记录了前者。这能减少实施工作，但采购方仍需要证据证明：在请求被拒绝、配置变更和日常运行故障时，身份边界依然有效。

ServiceNow 令牌交换成为网关配置

根据 AWS 的原生 OBO 演练，网关会将传入的用户凭据交换为 ServiceNow 接受的凭据。该操作无需自定义拦截器代码。

文档中的配置为 agent 和 ServiceNow 连接器分别使用独立的 Entra 应用注册。ServiceNow 将传入的身份声明（即具名令牌属性）映射至已有用户。网关要求使用 Model Context Protocol 2025-11-25 版本，这是 AWS 为原生 OBO 指定的工具连接协议版本。

最直接的变化在于：交换操作在哪里运行，以及由谁维护其实现。

这并不等同于替换企业的授权系统。它为团队提供了一个执行委派的托管位置。组织仍需决定哪些人员、应用和操作应纳入该工作流。

这一差异在评估该公告时很重要。令牌交换组件在架构图中看似很小，却可能承担重大责任。它的行为位于个人请求与企业系统权限决策之间。

实施前应先考虑责任归属问题。如果委派请求失败，必须有人判断故障涉及用户、应用还是目标系统。移除自定义组件会改变调查此类问题的边界。

对于维护自有交换服务的团队，相关问题变得很具体：该组件除标准委派外还承担什么功能？如果它唯一的目的就是获取下游凭据，那么托管替代方案值得评估。如果它还应用业务规则，则在弃用前必须为这些规则明确新的归属位置。

这能避免一种常见的迁移错误：因为某个集成功能的核心作用被平台接管而删除组件，也可能同时删除围绕该组件逐步积累的行为。负责任的评估应将认证工作与应用决策区分开来。

同样的推理也适用于项目估算。团队应先计算消失的工作量，再识别转移的工作。配置责任、权限审查、支持流程和验收证据仍需由明确人员负责。

因此，ServiceNow 令牌交换为“基础设施成为产品设置”提供了一个有用示例。其运营收益取决于组织能否像审查被替代的代码一样仔细审查该设置。

对于评估这则消息的读者而言，最有力的初步结论是务实的：AWS 已记录了一种无需自行维护此交换逻辑的替代方案。该演练提供的是评估起点，而非已测量生产成效的证据。

身份团队承担更明确的产品决策责任

受影响最直接的是平台工程师、身份管理员和 ServiceNow 负责人。每个团队都控制着同一用户旅程中的不同环节。托管交换使它们之间的协调更加显性。

agent 团队可能将获得有用答案视为成功。身份团队可能将正确完成委派访问视为成功。ServiceNow 负责人则可能要求证明未经授权的记录仍不可访问。

这些定义应在部署前达成一致。否则，同一场演示可能满足一个团队，却无法回答另一个团队最关心的问题。仅凭令人信服的答案，对其底层权限边界的证明仍然有限。

压力转向跨团队证明授权契约。

一个有用的契约应从日常语言开始。助手应使用请求者被允许的访问权限完成已批准任务。这一表述让工程师和审查者能共享目标，而不将验收绑定于某个特定模型。

例如，设想一名支持员工要求助手总结与其工作相关的事件。这是一个示例场景，而非已报道的客户部署。它的价值取决于检索是否有用，以及限制是否恰当。

成功的响应应说明该员工有权查看的事件。超出该边界的请求应产生清晰的限制说明。这两种结果都应纳入产品对正确性的定义。

这种框架也会改善采购决策。采购方可以要求供应商使用具有代表性的账户演示已授权和未授权行为，并将观察结果与书面的访问策略进行比对。

另一种做法是接受完全通过管理员账户完成的演示。这样的演示或许能证明连接已建立，却难以说明普通员工的实际使用情况。采购团队应区分这两类证据。

这也带来文档方面的影响。需要有人记录哪个团队负责应用身份、目标权限和用户映射。没有这类记录，常规人员变动就可能演变为集成谜团。

维护这些决策的团队可以使用可搜索知识库，保存配置说明和故障排查背景。这些文档支持集成运行，但不会成为其授权边界的一部分。

对开发者而言，组织层面的机会是减少重复建设。标准交换模式为应用团队提供共同起点，使其能将审查精力集中于助手实际需要执行的具体操作和访问的信息。

对安全团队而言，机会是获得更清晰的资产清单。审查者不必在不同应用实现中寻找委派行为，而可以要求查看网关配置及其负责人。这一收益取决于配置是否保持可发现且最新。

由此产生的压力是即时的，而非推测性的。评估此集成的团队必须就谁能批准访问、谁能解释拒绝原因达成一致。托管网关让这些决策更容易定位，但仍需由人作出决定。

该交换改变凭据的目标位置

访问令牌是一种授权调用特定资源的凭据。其受众标识预期接收方。当请求经过 agent 并抵达另一应用时，该目标尤为重要。

Microsoft 的OBO 授权流程要求中介提交合适的传入用户令牌。随后，身份平台签发下游令牌。该流程使用委派范围，即为代表用户执行的工作所请求的权限。

Microsoft 也将其与仅应用访问区分开来。OBO 要求存在用户主体，即代表个人的身份。仅签发给应用的令牌无法建立同样的委派关系。

委派应保留请求者与下游权限决策之间的联系。

对于衡量这一机制的读者，一个有用的类比是访客在受保护部门之间移动。获准进入接待区，并不自动意味着获准进入每一间办公室。每个目标位置都需要与该位置相适应的授权决策。

这个类比有其局限，但它说明了为什么仅仅向后传递凭据并不充分。中介必须参与已获批准的委派关系。随后，目标系统会收到供其自身使用的凭据。

AWS 的网关文档将认证置于其更广泛的工具集成职能之中。Gateway 可以通过统一接口暴露现有服务，同时管理入站和出站认证。

这带来值得评估的架构优势。团队可以将模型的推理与向工具提供凭据的机制分离。语言模型可以请求执行某项操作，而基础设施则处理认证路径。

这种分离应影响应用设计。提示词可以描述工具何时有用，但权限决策需要可靠的执行点。产品团队应能够修改措辞，而不改变谁能获得访问权限。

托管交换也改变了与自定义代码的比较方式。本地维护的组件让团队能够直接控制实现细节。托管服务则提供标准化配置界面，并将部分实现责任转移给提供商。

两种选择都不会消除理解故障行为的必要性。相关比较应包括诊断能力、可审查性、生命周期管理和支持。仅计算源文件数量，会忽略运营决策中的大部分内容。

因此，评估 AgentCore OBO 行为的开发者应将请求追踪为一条责任链。哪个组件验证传入调用者？哪个组件请求下游访问？哪个系统作出最终资源决策？

即使平台自动执行交换，这些问题仍然有用。自动化消除了手动实施步骤，却不会消除对准确架构说明的需求。

该机制也说明了模型选择能够和不能解决什么。更好的模型或许会选择更恰当的工具，或更清楚地解释结果。无论模型回答质量如何，授权都需要独立的验收证据。

对企业采购方而言，这是最有用的技术结论。应将推理质量与委派访问作为独立能力分别评估。产品需要同时具备二者，才能在具备权限控制的工作环境中提供可靠协助。

Azure 为同一边界提供了有用对照

Microsoft 的agent 隔离指南将委派授权与独立 agent 身份并列讨论。该指南还将 Azure API Management 视为可用于强制执行上下文传递的工具网关。

这为比较 AWS 的方法提供了一个相关参照。两项讨论都将身份执行置于模型的自主推理之外。Microsoft 的指南明确要求采用确定性控制，即规则执行不依赖生成文本。

有价值的竞争性问题在于：各架构如何清晰地保留并执行访问上下文。

这比比较支持的连接器数量更有参考价值。连接器建立了通往应用程序的路径。企业采用还需要能够自圆其说地说明：沿着这条路径传递的是哪种权限。

比较平台的采购方应从一个具有代表性的工作流开始。该工作流应包含允许访问、受限访问以及可恢复的失败情形。随后可以依据相同的预期结果评估各个平台。

这种方法避免将比较变成产品主张清单。它要求供应商展示对组织真正重要的行为，也会暴露仍处于托管平台之外的集成工作。

比较时应尊重架构差异。已经运行成熟网关的公司，可能更重视与现有控制措施的一致性。另一家公司则可能优先减少应用团队需要维护的基础设施。

这些都是合理的优先级差异，但并不能证明某个平台普遍提供更好的授权能力。决策取决于所选方案是否满足组织实际的访问需求。

对于正在考虑 AgentCore 与自定义身份验证的团队，同样的评估也应在内部适用。自定义系统应面对与托管替代方案相同的拒绝访问场景。对现有代码的熟悉程度不应替代证据。

迁移审查还应检查例外行为。例如，当前组件可能会增加审批检查，或转换内部身份。如果这些行为仍有必要，替代架构就需要明确地保留它们。

这正是托管基础设施能够暴露组织未文档化假设的地方。标准配置迫使团队说明其集成的哪些部分属于标准能力，哪些部分具有特定性。即使尚未决定迁移，这种澄清也很有价值。

因此，竞争压力不止涉及 AWS 和 Microsoft。集成供应商和内部平台团队越来越需要以运营术语说明其授权边界。在访问事故期间，笼统宣称具备企业级就绪能力几乎没有帮助。

读者也不应将这种集成视为模型提供商之间的竞赛。身份路径涉及用于调用企业应用程序的权限。无论哪个模型发起请求，其设计都值得独立审查。

更广泛的含义在于一种评估标准：使用相同的权限契约来比较平台。有效的响应、恰当的拒绝以及可理解的失败，比单独展示连接器更能为采购方提供可靠的判断依据。

成功请求仍会留下重要问题

可正常运行的集成能够证明允许的路径可以成功，但无法证明系统会如何应对每位相关用户、权限变更或策略挑战。这些问题需要单独评估。

Microsoft 记录了当下游策略要求用户进行额外身份验证时的交互要求。这为任何中间层提出了产品设计问题：应用程序应如何告知用户需要采取行动？

当工作无法继续时，助手应向用户提供有用的说明。它应区分权限限制、信息缺失和临时服务问题。否则，用户将面对含糊不清的失败，而支持团队则要承担调查工作。

生产环境的信心既来自解释失败，也来自完成获准请求。

第一个评估领域是拒绝行为。团队应有意尝试执行超出代表性用户获批访问范围的操作。应在测试开始前写明预期结果。

这有助于区分正确的限制与集成缺陷。若没有预期结果，开发人员可能会将每次拒绝都视为需要修复的问题。这会形成扩大访问权限的压力，只为让演示能够运行。

下一个领域是变更管理。组织应检查相关权限、身份映射或应用程序配置发生变化时会出现什么情况。目标是获得可理解的响应，以及明确的调查责任人。

凭据处理值得进行独立的运营审查。托管交换可以减少自定义实现，同时管理员仍需负责维护配置输入。团队应了解所需变更如何传递至已部署的集成。

可观测性，即通过运营证据理解系统行为的能力，在整个审查过程中都很重要。支持人员需要足够的上下文来定位失败，同时不能暴露敏感凭据。更多日志并不必然意味着更好的日志。

有用的调查记录应将请求与其结果及相关配置关联起来。审查人员随后可以判断证据是否支持既定的权限契约。具体记录设计应遵循组织的数据处理要求。

暴露操作的范围同样重要。读取记录和修改记录会给用户带来不同后果。团队应根据每项操作能够执行的内容进行评估，而不是将连通性视为一揽子批准。

例如，一个示例性的事故摘要工作流可以先仅提供检索功能。加入事故更新将引入关于确认、责任追究和恢复的独立产品决策。现有连接无法解决这些问题。

已发布材料能够证明的内容也存在边界。引用的演示说明了配置和预期行为，但未提供经过独立验证的生产环境可靠性、维护工作量或业务成果比较。

这一差距应影响采用决策的表述。团队可以合理地得出结论：托管方法值得测试。至于降低运营负担的更强主张，则需要团队自身部署的证据。

因此，最好通过具有明确成功与失败标准的有限试点来评估 ServiceNow token exchange。这样，组织可以评估文档中描述的能力，而不会将成功演示视为全面保障。

关注部署证据、策略处理与复用

接下来值得关注的信号是运营证据，而不是又一项关于自主工作的宽泛承诺。在未来几个月里，采购方应关注部署结果、策略恢复以及在更多工作流中的复用情况。每一项都检验托管委派论点的不同部分。

最有力的证据将表明：更少的自定义交换代码也能带来更清晰、更易运营的系统。

首先，应关注采用代表性员工权限的文档化部署结果。有价值的案例会说明哪些操作被允许、哪些被拒绝，以及团队如何验证这种区别。仅有客户名称的信息量较少。

一致的访问结果证据将强化托管委派的理由。若有报告显示团队为了稳定集成而扩大权限，则会削弱这一理由。关键细节在于：已部署行为与原始权限契约相比如何。

维护证据同样会有帮助。正在评估迁移的团队需要了解初始设置之后会发生什么。对配置更新和事故调查的清晰说明，比仅有设置时间更能支撑有力的运营论证。

其次，应关注实施方案如何处理策略中断与恢复。当用户需要重新进行身份验证或获取批准时，生产环境中的助手需要合理的路径。如果反复返回无法解释的错误，就意味着仍有大量产品工作尚未解决。

清晰的恢复行为将强化托管交换能够简化整体体验的论点。如果每个应用程序都需要围绕它进行大量自定义处理，其收益就会更有限。即便如此它仍然有用，但会改变实施工作量估算。

这一信号同样关系到支持责任归属。应用团队需要知道何时可以自行解决问题，何时必须由身份管理员介入。明确记录的交接机制可帮助用户避免在团队之间反复转接。

第三，应关注组织是否将这一模式复用于更多企业操作。当集成扩展时，同样的权限原则仍然清晰，复用才具有意义。增加目标系统却无法保留这种清晰度，提供的证据就较弱。

可复用的模式应让每个目标系统的权限都易于理解。审查人员仍应能够识别用户、获批操作和责任系统。仅仅增加连接器数量无法证明这一结果。

对于企业开发人员而言，这些信号意味着可以采取务实的应对方式：在自定义代码目前承担常规委派的场景中评估托管路径。保持业务特定控制的明确性，并将结果与现有实现进行比较。

对于采购方，应要求基于普通员工账户和真实限制条件提供证据。如果没人能解释底层请求为何获得访问权限，再令人印象深刻的回答也意义不大。评估应奖励易于理解的授权行为。

对于计划下一次审查的团队，应从一个具体工作流开始，并写下其允许执行的操作。确定应传递到 ServiceNow 的用户权限，然后测试一个允许请求和一个刻意受限的请求。记录应用程序如何解释每种结果，以及任何失败由谁负责。利用这些结果评估通过 AgentCore 进行的 ServiceNow token exchange 是否在保留预期访问边界的同时减少维护工作量。在扩展工作流之前，应与身份管理员和 ServiceNow 负责人审查配置。最有价值的下一步是开展一次聚焦评估，形成团队可以检查、复现并用于决定是否替换现有交换组件的证据。