工作人員企業的信任工作人員身分

隨著企業採用工作人員範例,隨即出現新的安全性挑戰:**一般使用者身分如何在自主 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 公開三個核心功能,每個功能都有不同的身分需求:

**“顯示我的產品組合。」:**使用者要求其個人資產與交易歷程記錄。由於此資料是使用者特有的,因此下游 Portfolio 服務代理程式和 Portfolio MCP Server 必須知道要傳回的使用者資料是_哪_個使用者,且必須驗證使用者已獲得存取權限。使用者身分必須在每次跳轉中移入。
「目前的市場趨勢為何?」:使用者要求公用市場資料和資產價格。由於資料為公用,且不因使用者而有所不同,因此下游市場資料工作人員和資產市場 MCP 伺服器不需要或預期需要使用者範圍的權杖。經紀人的專屬服務認證足夠。
“將 $5,000 轉移至我的外部儲蓄帳戶。“:使用者會起始基金轉移至使用不同 IdP 的銀行 (例如,Auth0 而非 Okta)。對於銀行系統而言,使用者的 Finport 權杖沒有意義。使用者必須先直接向銀行進行驗證 (對話內嵌),才能繼續轉移。

每個功能都會對應至不同的身分傳播模式。下列情況會逐步從標準基準 (不含工作人員) 建立到各個不同的模式,說明 Flex Gateway 中的輸出原則如何滿足每個需求,而不修改工作人員或後端服務。

在介紹工作人員之前,建立基準十分重要:使用用戶端應用程式進行驗證並存取後端服務的使用者。

流程:

使用者開啟 Finport,並重新導向至 IdP 的登入頁面 (例如 Okta) 。
使用者驗證 (使用者名稱、密碼、SSO、多因素驗證 (MFA) 和任何其他需求)。
IdP 會核發已簽署的 JWT 存取權杖給 Finport 應用程式。
Finport 現在擁有代表使用者身分的使用者權杖:使用者身分、獲授與的範圍,以及權杖到期時間。它可以代表此使用者向任何下游服務呈現。

這會建立什麼:此流程遵循標準 OAuth 2.0 結構模式。由信任的 IdP 驗證的初始使用者權杖會作為所有後續作業的基本基礎。每個後續的情況都會建立在此權杖上。

詢問:驗證後,使用者會起始如基金轉移、市場分析或產品組合檢閱等動作。這些要求會透過「工作人員經紀人」處理,且可能涉及多個下游工作人員或 MCP 伺服器。這會產生重要問題:如何在這些散佈的要求之間維護使用者的身分?下游服務使用完全不同的 IdP 時會發生什麼事?

使用者要求 Finport 工作人員 _「顯示我的產品組合」。_此互動會從使用 MuleSoft Agent Broker 建立的 Finport Agent Broker 開始觸發後端鏈。經紀人會將工作交付給 Portfolio 服務代理程式,該代理程式接著會查詢 Portfolio MCP 伺服器。使用者的初始驗證權杖現在必須經過多個跳轉,才能存取要求的產品組合記錄。

傳遞原始權杖會違反最低權限原則,而使用服務帳戶會失去使用者的身分。

Finport Agent 會接收使用者的權杖,但無法簡單地將相同權杖轉送至 Portfolio 服務代理,因為這會違反最低權限原則,且不會適當範圍要求下游服務。相反地,使用服務帳戶會導致總共遺失使用者身分。「產品組合服務工作人員」與「產品組合 MCP 伺服器」將無法知道要傳回的使用者產品組合,而稽核追蹤會將每個動作歸屬於經紀人的服務身分,而非一般使用者。__

Flex Gateway 透過其 Outbound OAuth 2.0 權杖交換原則,以透明方式解決這些身分傳播複雜問題。此解決方案會在通話鏈中每次跳轉時攔截輸出要求,將傳入使用者權杖與 IdP 交換,以取得特別針對下游服務範圍的新認證。「代表 (OBO)」原則支援 OAuth 2.0 權杖交換 (RFC 8693) 和 Microsoft Entra ID 代表通訊協定。

重要結構優點:此整個流程由 Flex Gateway 輸出原則處理。經紀人與工作人員包含零驗證邏輯。相反地,它們只會專注於業務邏輯,而門層會強制執行身分移入。

流程:

使用者使用 Okta 進行驗證,且 Finport 應用程式透過 Flex Gateway 傳送要求。
經紀人會收到已驗證的使用者權杖,並判定需要「產品組合服務代理程式」。
Flex Gateway 的輸出 OBO 原則會將使用者權杖與 IdP 交換,以取得範圍為 Portfolio 服務代理的權杖。
Portfolio 服務代理程式接收適當範圍的權杖,並呼叫 Portfolio MCP Server。
Flex Gateway 會再次交換權杖,這次範圍為 MCP 伺服器。
Portfolio MCP 伺服器會傳回使用者的特定產品組合資料。
已存在完整稽核追蹤。每個跳轉都歸屬於原始使用者。

為什麼這很重要:若沒有 OBO 權杖交換,企業必須在傳送原始權杖 (違反最低權限) 或使用服務帳戶 (可能遺失使用者身分) 之間選擇。OBO 模式會去除此權衡,因為使用者的身分會在每次跳轉時予以保留,每個權杖都會縮小其目標的範圍,而工作人員本身仍會完全不知道身分機制。

並非每個下游服務都需要使用者內容。使用者詢問 Finport 工作人員,_「目前的市場趨勢為何?」_不同於「案例 1」中的產品組合要求,當市場趨勢資料不因使用者而改變時,其為公用。下游 Market Data Agent 和 Asset Market MCP Server 不需要或預期不需要使用者範圍權杖。

在不需要使用者權杖的地方傳播使用者權杖會擴大攻擊的面積。

如果 Finport Agent Broker 使用「情節 1」中的 OBO 模式將使用者權杖移入至 Market Data Agent,則會運作,但不需要。將使用者權杖移入不需要的位置會擴大攻擊面積、在權杖交換的 IdP 上建立不必要的相依性,並違反最低權限原則。市場資料工作人員只需要知道要求來自授權服務,而不是詢問的_使用者_。

Flex Gateway 的「輸出 OAuth 2.0 用戶端認證」原則會以透明的方式處理此問題。原則不會交換使用者的權杖,而是會透過用戶端認證授與將經紀人的專屬服務認證注入傳出要求。下游市場資料工作人員會收到正確驗證的服務層級權杖,因為不需要使用者身分,因此不會移入該權杖。

重要結構優點:身分傳播策略並非一體適合,而是根據資料的性質和目標服務的需求,由每個下游路線決定。Flex Gateway 的輸出原則可讓您依路線設定此項目。相同的 Finport Agent 經紀人可以參與 OBO 流程 (在「情節 1」中) 和 S2S 流程,而不會變更任何程式碼。輸出門道上的原則組態會決定要套用至下游呼叫的模式。

流程:

使用者詢問 Finport 工作人員,「目前的市場趨勢為何?」
經紀人判定需要 Market Data Agent 才能滿足要求。
Flex Gateway 的輸出用戶端認證原則會使用經紀人的專屬認證取得服務層級權杖 (不會交換或移入使用者權杖)。
Market Data Agent 會收到正確驗證的服務要求,並呼叫資產市場 MCP 伺服器。
「資產市場 MCP 伺服器」會傳回公用市場資料。
依設計,鏈結中沒有使用者身分,因為此類型的資料不需要任何身分。

為什麼這很重要:Flex Gateway 的原則驅動架構可讓結構設計師為每個互動選取最佳身分模型,解決通用使用者權杖傳播 (這會增加額外費用和安全性風險) 與全域服務帳戶用量 (這會犧牲使用者內容和合規性) 之間的困難選擇。

當工作人員需要與由完全不同的 IdP 管理的系統互動時,會發生最複雜的身分識別情況,也就是無法辨識現有使用者權杖的系統。

情況:Finport 使用者要求 Finport 工作人員 _「將 $5,000 轉移至我的外部儲蓄帳戶」。_此要求涉及兩個不同的下游路徑:

驗證使用者資產的 Portfolio 服務代理程式 (OBO) 路徑
執行實際轉移的 交易工作人員 → 交易 MCP 伺服器 → 使用者的銀行路徑

「交易工作人員」需要與使用者的銀行互動,該銀行使用自己的 IdP。使用者的 Finport Okta 權杖對於銀行系統而言沒有意義,因為銀行與 Finport 的 IdP 沒有 Trust 關係。OBO 模式 (來自「情節」1) 或 S2S 模式 (來自「情節」2) 都無法解決此問題。OBO 會在相同的 IdP 內交換權杖,而 S2S 會使用完全無使用者身分的服務認證。銀行要求使用者直接使用自己的銀行認證進行驗證,可能包含 MFA。

Flex Gateway 上的「輸出 A2A 工作中授權代碼」原則使用工作人員對話內的挑戰回應機制。如果連絡銀行時缺少次要權杖,則原則會傳回需要驗證的要求。此挑戰包含用戶端透過銀行提供者起始 OAuth 2.0 流程所需的所有詳細資料,例如端點、範圍和 PKCE 參數。

Finport 應用程式接著會顯示銀行的內嵌登入,以供直接使用者驗證。完成後,用戶端會在 A2A 要求中傳回權杖。原則會針對銀行的系統提取此權杖,並將其從訊息內文中清除,以確保安全性。

重要結構優點:管道原則層會協調整個跨網域驗證流程,確保經紀人或工作人員都不會與原始認證互動或需要銀行的 IdP Knowledge。透過使用此挑戰回應架構,使用者可維持完全控制:這些權杖會提供明確同意,以透過外部系統進行驗證,而產生的權杖會透過原則層安全地傳輸。

流程:

使用者要求 Finport 起始轉移。要求會透過經紀人流動。
經紀人會使用「組合」(OBO) 驗證資產,並使用「交易」(在職) 執行轉移。
「交易」路徑會從「Flex Gateway」上的「工作中」原則觸發需要驗證的挑戰。
此挑戰會移回 Finport 應用程式,其會將銀行的登入流程內嵌呈現給使用者。
使用者向其銀行進行驗證,包括必要時使用 MFA。
銀行權杖會包含在後續的 A2A 要求中。原則會將它解壓縮,並在「授權」標題中設定,然後轉送要求。
「交易 MCP 伺服器」會接收具有銀行權杖的要求,並執行轉移。

**為什麼這很重要:**跨網域身分是工作人員結構中的一個重大挑戰。若沒有工作中驗證,企業必須在網路的每個 IdP 之間預先建立複雜的 Trust 關係,或要求使用者將銀行認證提供給工作人員。「工作中」模式允許透過外部提供者的直接使用者驗證來解決此問題;此原則會管理權杖機制,同時將工作人員與外部身分網域分離。

在所有三種情況之間,單一結構原則會保留:身分移入會強制執行在門層,而非在工作人員或服務中。工作人員與 MCP 伺服器包含零驗證邏輯。其角色僅限於處理已驗證的要求和傳回結果,而「Flex Gateway 輸出原則」層級管理所有與身分相關的作業。

這是因為 Flex Gateway 的輸出驗證原則會在正確的位置攔截流量:在工作人員做出路由決策後,但在要求到達下游服務之前。原則會轉換權杖 (無論是 OBO 交換、用戶端認證插入或工作中挑戰回應),並轉送正確驗證的要求。下游服務永遠不會知道差異,因此工作人員永遠不必擔心。驗證邏輯會集中在管道,而非跨服務散佈。後端服務不需要程式碼變更,且可在多個路線之間重複使用相同的原則組態。

此方法也是通訊協定的原則。由於原則會在 HTTP 圖層中作業,因此無論工作人員透過 REST、MCP、A2A 或 Webhooks 通訊,都會一致套用原則。如同 Agent Fabric Deep Dive 所記錄,所有 A2A 和 MCP 流量都會透過 Flex Gateway 路由,以確保原則會套用至每個端點,這表示無論通訊通訊協定為何,都會統一強制執行身分傳播。

三個可編輯模式涵蓋工作人員結構中身分需求的完整範圍:

模式	原則	使用者身分	使用者互動	使用個案
代表 (OBO)	OAuth 2.0 OBO 認證插入原則	已保留	無 (透明)	相同 Trust 網域內的使用者特定資料
伺服器對伺服器 (S2S)	輸出 OAuth 2.0 用戶端認證	未移入	無	公用資料、系統層級作業
工作中授權代碼	輸出 A2A 工作中授權代碼	主要 + 次要	必要 (內嵌驗證)	跨網域、多個身分提供者、高度風險營運

這些模式並非互斥。如 Finport 案例所示,單一「工作人員經紀人」可針對一個下游通話使用 OBO、針對另一個通話使用 S2S,並針對第三次通話使用「工作中」。每個輸出路線上的原則組態會決定要套用的模式。沒有工作人員代碼變更,也沒有服務修改,只有原則。

以上所述的門戶強制模式可保護個別互動的安全性,但身分移入並非獨立的考量。這是更廣泛 MuleSoft Agent Fabric 管理模型的基礎層。如同在「工作人員紡織深度探索」中所述,「工作人員紡織」以四個支柱為基礎:探索、協調、管理和觀察,每個項目都取決於可靠的身分鏈以有效運作。

探索:工作人員註冊處會編目工作人員及其功能。包含驗證需求的工作人員中繼資料可讓經紀人瞭解每個工作人員預期的身分模式。
協調流程:「工作人員經紀人」會協調多工作人員工作流程。Flex Gateway 會在每次跳轉時透明地處理身分轉換,因此經紀人可以專注於工作分解和路由。
控管:所有 A2A 和 MCP 流量都會透過「Flex Gateway」進行路由,即使目標系統未受到保護,以確保原則會套用至每個端點。輸出驗證原則是監管層的一部分。
觀察:「工作人員視覺化工具」透過動態互動式工作人員互動地圖提供即時可觀察性。透過在每次跳轉時保留使用者身分,追蹤和記錄可在工作人員網路中提供使用者可歸屬的稽核追蹤。

若沒有信任的身分傳播,則監管無法完成。您可以將工作人員分類和協調,但無法確保其在使用者授權的限制內執行動作。Trusted Agent Identity 可填補此間缺口,確保安全性與使用者內容在工作人員工作流程中保持重要。

實作這些模式:

瞭解輸出原則目錄。檢閱可供 Flex Gateway 使用的完整一組輸出驗證原則。
以 OBO 開始。OAuth 2.0 權杖交換原則可滿足最常見的身分移入需求:在工作人員跳轉之間保留使用者內容。
新增跨網域案例的工作中:當您的工作人員網路跨越 Trust 邊界時,A2A 工作中授權代碼原則會提供挑戰回應機制,以便從使用者取得次要認證。
** Leverage Agent Fabric**。使用指定每個路線身分模型的原則組態,在工作人員網路 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 擔任工程職位,在其中貢獻至產品,包括 Copilot、Dataverse 和 Power Platform。