Agentic Enterprise 的受信客服人员身份

随着企业采用代理模式，出现了一个新的安全挑战：**最终用户身份如何通过自主 AI 客服人员网络？**在传统 API 架构中，用户验证一次，应用程序代表用户调用后端服务。身份链简短，易于理解，通常在单个 Trust 域中管理。然而，客服人员架构具有更长的链，其中单个请求会跨多个客服人员、服务和模型上下文协议 (MCP) 服务器扇出，每个服务器都可能跨越服务边界、Trust 域，甚至组织边界。如果没有审慎的身份传播策略，企业将面临安全和功能之间的选择，这是架构师不应面对的困境。

MuleSoft 通过其受信客服人员身份功能解决了身份传播的复杂性。此解决方案利用基于策略的网关受管策略，确保跨各种交互类型维护最终用户身份，包括客服人员对客服人员 (A2A) 协议、MCP 工具调用和 REST API 请求。通过出站身份验证策略在 Flex Gateway 层集中身份管理，企业可以保护整个客服人员网络，而无需修改后端服务或客服人员。

本文档使用一系列渐进的场景来逐步解决身份传播的挑战，每个场景都会引入额外的复杂性。这些情况共同说明了为什么受信客服人员身份是任何企业级客服人员部署的基本要求。

在常规应用程序中，身份流（OAuth JWT 流）简单明了：用户登录，收到令牌，应用程序使用该令牌访问后端资源。令牌嵌入用户的身份（包括他们是谁以及他们被授权做什么），并随每个请求一起传递。呼叫链较短，通常是一或两跳，解决了身份传播问题。

然而，客服人员架构的特点是呼叫链更长，其中单个用户请求可能会跨各种客服人员、后端服务和模型上下文协议 (MCP) 服务器扇出。每个请求目标构成单独的一跳。虽然这些挑战 – – 例如多跳身份传播、混合授权模式、跨域 Trust 边界 – – 在任何分布式 API 设置中都很常见,但不同_的是_,当前的生态系统默认如何响应。今天,客服人员到客服人员和客服人员到 API 通信的主要模式依赖于客户端凭据、API 密钥或共享密码。这意味着：

  • **默认情况下，用户身份会丢失。**当客服人员使用客户端凭据调用 MCP 服务器或下游 API 时，该请求会携带客服人员的服务身份，而不是最终用户的身份。下游服务无法知道是_哪个用户_发起的操作,这使得每个用户的授权和审计跟踪变得不可能。
  • **将忽略混合授权需求。**并非所有下游服务都需要用户上下文。虽然一些服务管理特定于用户的信息，例如交易或产品组合，但其他服务提供面向公众或系统级别的数据，例如参考材料或市场趋势。由于当前标准完全依赖于客户端凭据，因此无法区分这些需求，或仅在必要时有选择地传播用户身份。
  • **跨域 Trust 边界未处理。**B2B 和受监管场景中的客服人员可能需要与完全独立的身份提供商 (IdP) 管理的系统进行交互。例如，外部银行系统无法解释公司单点登录 (SSO) 令牌，但仍必须得到用户的同意和意图。客户端凭据流没有这方面的机制。

其结果是，企业对用户可归因的、最低权限的访问的要求与当前生态系统对缺乏用户上下文的服务级别身份验证的依赖之间存在差距。弥合这一差距需要谨慎、分层的身份传播方法。为了说明这些概念,以下场景使用虚构的 fintech 应用程序 Finport 来提供这些架构模式的实际示例。

Finport 是一个面向消费者的虚构 Fintech 产品组合管理 Web 应用程序，由客服人员架构提供支持。客服人员代理(使用 MuleSoft 客服人员代理构建)协调多个下游客服人员和 MCP 服务器，以满足用户请求。

Finport 公开了三个核心功能，每个功能都有不同的身份要求：

  1. **“向我展示我的产品组合。”:**用户请求他们的个人持有量和交易历史。由于这些数据是特定于用户的,下游证券服务代理和证券MCP服务器必须知道要返回_哪些_用户的数据,并且必须验证用户是否有权访问这些数据。用户身份必须通过每个跳转传播。
  2. “当前市场趋势如何 ? “:用户请求公共市场数据和资产价格。因为数据是公开的，不因用户而异，所以下游市场数据代理和资产市场 MCP 服务器不需要或不需要用户范围的令牌。经纪人自己的服务凭据就足够了。
  3. “将 5,000 美元转到我的外部储蓄账户。“:用户向使用不同 IdP 的银行发起资金转移（例如，Auth0，而不是 Okta）。用户的 Finport 令牌对银行系统毫无意义。用户必须直接与银行进行身份验证（对话中的内联），然后才能继续转移。

其中每个功能都映射到不同的身份传播模式。以下场景从标准基准（没有客服人员）逐步构建到每个不同的模式，说明了 Flex Gateway 中的出站策略如何在不修改客服人员或后端服务的情况下满足每个要求。

在介绍客服人员之前，重要的是要建立基准：用户使用客户端应用程序进行身份验证并访问后端服务。

流:

  1. 用户打开 Finport，并被重定向到 IdP 的登录页面（例如 Okta）。
  2. 用户进行身份验证（用户名、密码、SSO、多重身份验证 (MFA) 和任何其他要求）。
  3. IdP 向 Finport 应用程序颁发签名的 JWT 访问令牌。
  4. Finport 现在有一个代表用户身份的用户令牌：他们是谁、他们被授予什么范围以及令牌何时过期。它可以代表该用户将其呈现给任何下游服务。

这将建立:此流程遵循标准 OAuth 2.0 架构模式。由受信 IdP 验证的初始用户令牌是所有后续操作的重要基础。每个后续场景都基于此令牌。

询问:经过身份验证后，用户会启动资金转移、市场分析或投资组合审查等操作。这些请求通过客服人员代理处理，可能涉及多个下游客服人员或 MCP 服务器。这提出了关键问题:如何在这些分布式请求中维护用户的身份？当下游服务使用完全不同的 IdP 时会发生什么？

用户要求 Finport 客服人员_“向我显示产品组合 ” 。_此交互会触发后端链，从使用 MuleSoft 代理代理构建的 Finport 代理代理开始。经纪人将任务交给证券服务代理,后者再查询证券MCP服务器。用户的初始身份验证令牌现在必须经过多个跳转才能访问请求的产品组合记录。

传递原始令牌违反了最小权限原则，而使用服务帐户会丢失用户的身份。

Finport 代理接收用户的令牌，但不能简单地将相同的令牌转发到产品组合服务代理，因为这将违反最小权限原则，并且不能正确地确定下游服务的请求范围。相反，使用服务帐户会导致完全丢失用户身份。投资组合服务代理和投资组合MCP服务器将无法知道要返回_哪个_用户的投资组合,审计跟踪会将每项行动归因于经纪人的服务身份,而不是最终用户。

Flex Gateway 通过其出站 OAuth 2.0 令牌交换策略透明地解决了这些身份传播的复杂性。此解决方案在呼叫链的每个跳跃处拦截出站请求，并将传入用户令牌与 IdP 交换为专为下游服务确定的新凭据。代表客户 (OBO) 策略支持 OAuth 2.0 令牌交换 (RFC ⁇ ) 和 Microsoft Entra ID 代表客户协议。

关键架构优势:整个流程由 Flex Gateway 出站策略处理。经纪人和客服人员包含 0 个身份验证逻辑。相反，它们只关注业务逻辑，而网关层强制执行身份传播。

流:

  1. 用户使用 Okta 进行身份验证，Finport 应用程序通过 Flex Gateway 发送请求。
  2. 经纪人收到验证的用户令牌，并确定需要产品组合服务代理。
  3. Flex Gateway 的出站 OBO 策略将用户令牌与 IdP 交换为范围为产品组合服务代理的令牌。
  4. 产品组合服务代理收到正确范围的令牌，并调用产品组合 MCP 服务器。
  5. Flex Gateway 再次交换令牌，这次的范围是 MCP 服务器。
  6. 产品组合 MCP 服务器返回用户的特定产品组合数据。
  7. 存在完整的审计跟踪。每个跳转都归因于原始最终用户。

为何如此重要:如果没有 OBO 令牌交换，企业必须在转发原始令牌（这违反了最低权限）或使用服务帐户（这有丢失用户身份的风险）之间进行选择。OBO 模式消除了这种权衡，因为用户的身份在每个跳上都被保留，每个令牌都以其目标为范围，并且客服人员自己仍然完全不知道身份机制。

不是每个下游服务都需要用户上下文。用户会询问 Finport 客服人员 , _” 什么是当前市场趋势 ? “_与场景 1 中的产品组合请求不同，市场趋势数据在不因用户而异时是公开的。下游市场数据代理和资产市场 MCP 服务器不需要或不需要用户范围的令牌。

在不需要的地方传播用户令牌会扩大攻击范围。

如果 Finport Agent 经纪人使用场景 1 中的 OBO 模式将用户的令牌传播到 Market Data Agent，这将有效，但没有必要。在不需要的地方传播用户令牌会扩大攻击范围，对令牌交换的 IdP 产生不必要的依赖性，并违反最小权限原则。市场数据客服人员只需知道请求来自授权的服务，而不是哪个_用户_正在询问。

Flex Gateway 的出站 OAuth 2.0 客户端凭据策略会透明地处理此问题。该策略不是交换用户的令牌，而是通过客户端凭据授权将经纪人自己的服务凭据注入出站请求。下游市场数据代理会收到经过正确身份验证的服务级别令牌，其中不会传播用户身份，因为不需要。

关键架构优势:身份传播策略不是一刀切的，而是根据数据的性质和目标服务的要求来确定每条下游路由。Flex Gateway 的出站策略使该策略可以根据路线进行配置。同一个 Finport Agent Broker 可以参与 OBO 流（在场景 1 中）和 S2S 流，而无需任何代码更改。出口网关上的策略配置决定了哪个模式适用于哪个下游呼叫。

流：

  1. 用户会询问 Finport 客服人员 , ” 什么是当前市场趋势 ? ”
  2. 经纪人确定需要市场数据客服人员来满足请求。
  3. Flex Gateway 的出站客户端凭据策略使用经纪人自己的凭据获取服务级别令牌（不交换或传播用户令牌）。
  4. 市场数据客服人员收到经过正确身份验证的服务请求，并调用资产市场 MCP 服务器。
  5. 资产市场 MCP 服务器返回公共市场数据。
  6. 按设计，链中不存在用户身份，因为此类数据不需要用户身份。

为何如此重要:Flex Gateway 的策略驱动框架使架构师能够为每次交互选择最佳的身份模型，从而解决在通用用户令牌传播（会增加开销和安全风险）和全局服务帐户使用（牺牲用户上下文和合规性）之间的艰难选择。

最复杂的身份场景出现在客服人员需要与由完全不同的 IdP 控制的系统进行交互时，IdP 无法识别现有的用户令牌。

场景:Finport 用户要求 Finport 客服人员_“将 $5,000 转入我的外部储蓄账户 ” 。_该请求涉及两个不同的下游路径：

  1. 组合服务代理核实用户持有量的路径
  2. 执行实际转移的交易代理 → 交易 MCP 服务器 → 用户的银行路径

事务代理需要与用户的银行交互，该银行使用自己的 IdP。用户来自 Finport 的 Okta 令牌对银行的系统毫无意义，因为银行与 Finport 的 IdP 没有 Trust 关系。无论是 OBO 模式(来自场景 1)还是 S2S 模式(来自场景 2)都不能解决这个问题。OBO 在同一 IdP 中交换令牌，S2S 使用根本不携带用户身份的服务凭据。银行要求用户直接使用自己的银行凭据进行身份验证，可能包括 MFA。

弯曲网关上的出站 A2A 任务内授权代码策略在客服人员对话中使用质询响应机制。如果在联系银行时缺少次要令牌，策略将返回身份验证要求的质询。此挑战包含所有必要的详细信息，例如端点、范围和 PKCE 参数，以便客户与银行提供商一起启动 OAuth 2.0 流。

然后，Finport 应用程序会显示银行的登录内联，以便进行直接用户身份验证。完成后，客户端返回 A2A 请求的令牌。该策略为银行系统提取此令牌，并将其从消息正文中清除，以确保安全性。

关键架构优势:网关策略层会编排整个跨域身份验证流程，确保经纪人和客服人员都不要与原始凭据交互，也不要Knowledge银行的 IdP。通过使用这个挑战响应框架，用户保持完全控制：他们明确同意与外部系统进行身份验证，而生成的令牌通过策略层安全地传输。

流:

  1. 用户要求 Finport 发起转移。该请求通过经纪人流动。
  2. 经纪人扇出，使用投资组合 (OBO) 来验证持有量，并使用交易（任务内）来执行转移。
  3. 事务路径会从 Flex Gateway 上的任务内策略触发身份验证要求的挑战。
  4. 挑战会扩散回 Finport 应用程序，这将向用户内联显示银行的登录流。
  5. 用户通过银行进行身份验证，包括 MFA（如果需要）。
  6. 银行标记包含在后续 A2A 请求中。该策略将其提取、设置在授权标题中，并转发请求。
  7. 事务 MCP 服务器收到带有银行令牌的请求并执行转移。

**为何如此重要：**跨域身份是代理架构中的一个主要挑战。如果没有任务内身份验证，企业必须预先在每个 IdPin 网络之间建立复杂的 Trust 关系，或者要求用户向客服人员提供银行凭据。任务内模式通过允许与外部提供商进行直接用户身份验证来解决这个问题；该策略管理令牌机制，同时保持客服人员与外部身份域分离。

在所有三种情况下，一个架构原则都成立：**身份传播在网关层强制执行，而不是在客服人员或服务中。**客服人员和 MCP 服务器包含零身份验证逻辑。他们的角色仅限于处理经过身份验证的请求和返回结果，而 Flex Gateway 出站策略层管理所有与身份相关的操作。

这之所以有效是因为 Flex Gateway 的出站身份验证策略在正确的时间点拦截流量：在客服人员做出路由决策后，但在请求到达下游服务之前。该策略转换令牌 - 无论是 OBO 交换、客户端凭据注入还是任务内质询响应 - 并转发经过正确身份验证的请求。下游服务永远不会知道有什么不同，因此客服人员永远不必关心。身份验证逻辑集中在网关，而不是分散在各个服务中。后端服务不需要更改代码，并且相同的策略配置可以在多条路线上重复使用。

这种方法也是与协议无关的。因为策略在 HTTP 层操作，所以无论客服人员是通过 REST、MCP、A2A 还是 Webhook 进行通信，它们都一致适用。如客服人员结构深度挖掘中所述,所有 A2A 和 MCP 流量都通过 Flex Gateway 进行路由,以确保在每个端点上应用策略,这意味着无论通信协议如何,身份传播都会统一实施。

三种可组合模式涵盖了客服人员架构中的全部身份要求：

模式策略用户身份用户交互用例
代表客户 (OBO)OAuth 2.0 OBO 凭据注入策略保留无（透明）同一 Trust 域中的用户特定数据
服务器到服务器 (S2S)出站 OAuth 2.0 客户端凭据未传播无公共数据，系统级操作
任务内授权代码出站 A2A 任务内授权代码主要 + 次要必需（内联身份验证）跨域、多身份提供商、高风险操作

这些模式并不相互排斥。如 Finport 场景所示，单个客服人员经纪人可将 OBO 用于一个下游呼叫，将 S2S 用于另一个下游呼叫，并将任务内呼叫用于第三个下游呼叫。每个出站路由上的策略配置决定应用哪个模式。没有客服人员代码更改，也没有服务修改，只有策略。

上述网关强制模式保护了个人交互，但身份传播不是孤立的问题。这是更广泛的 MuleSoft 客服人员结构治理模型的基础层。如客服人员结构深入介绍,客服人员结构构建在四个支柱上：发现、编排、治理和观察,每个功能都依赖于可靠的身份链来有效运作。

  • 发现:客服人员注册表对客服人员及其功能进行编目。包括身份验证要求的客服人员元数据使客服人员能够了解每个客服人员期望哪些身份模式。
  • 编排:客服人员经纪人协调多客服人员工作流。Flex Gateway 透明地处理每跳的身份转换，因此代理可以专注于任务分解和路由。
  • 治理:所有 A2A 和 MCP 流量都通过 Flex Gateway 路由，即使目标系统不安全，也能确保在每个端点上应用策略。出站身份验证策略是治理层的一部分。
  • 观察:客服人员可视化器通过客服人员交互的动态交互式地图提供实时观察性。通过在每跳中保留用户身份，跟踪和日志可在客服人员网络中提供用户可归因的审计跟踪。

如果没有可信身份传播，治理将不完整。您可以对客服人员进行编目和编排，但无法确保他们在用户授权的范围内操作。受信客服人员身份弥补了这一差距，确保安全和用户上下文仍然是客服人员工作流的核心。

要实施这些模式：

  1. 了解出站策略目录。查看适用于 Flex Gateway 的完整出站身份验证策略集。
  2. 从 OBO 开始。OAuth 2.0 令牌交换策略解决了最常见的身份传播需求：在客服人员跳转中保留用户上下文。
  3. 为跨域场景添加任务内:在客服人员网络跨越 Trust 边界时，A2A 任务内授权代码策略会提供质询-响应机制，以便从用户获取辅助凭据。
  4. 利用客服人员结构。使用指定每个路由的身份模型的策略配置，在客服人员网络 YAML 中定义客服人员网络。平台处理剩余部分。

有关详细的实施指南，请参考配套实施指南。

Nikhil Aggarwal 是 Salesforce 的杰出工程师，负责 MuleSoft 和 Salesforce Automation Cloud 的架构。Nikhil 拥有超过 18 年的大规模产品交付经验，并热衷于可扩展架构、直观的开发人员体验和构建高性能团队。在加入 Salesforce 之前，从概念到发布，他在 Microsoft Power Platform、Dataverse 和 Office 365 中领导了多项计划。他的工作继续塑造现代企业如何在 AI 优先时代连接系统、自动化工作流并释放业务价值。

Akash Trivedi 是 Salesforce 的工程主管，在构建可扩展、安全、高性能的企业系统方面拥有超过 18 年的经验。他在 AI、企业架构和流程智能的交叉领域工作，专注于云原生平台和大规模运行的可靠解决方案。在加入 Salesforce 之前，他曾在 Microsoft 担任工程角色，为 Co pilot、Dataverse 和 Power Platform 等产品做出贡献。