誰授權了？多智慧體AI中的委託問題

你的AI智慧體預訂了會議、總結了財務報告，並將要點透過電子郵件傳送給了三位利益相關者。為此，它呼叫了日曆智慧體、文件分析智慧體和郵件智慧體。每個智慧體都訪問了內部系統，做出了關於包含哪些內容的決策，並代表你採取了行動。

你的安全團隊無法回答的問題是：誰授權郵件智慧體讀取那份財務報告？在大多數當前架構中，誠實回答是：沒有人明確授權。日誌可能顯示某個服務呼叫了另一個服務，但無法證明委託本身是被授權的。授權並沒有響亮地失敗，而是悄然透過鏈洩露。

這就是多智慧體AI中的委託問題。隨著企業透過MCP和A2A等協議連線智慧體，它們解決連線問題的速度遠快於解決許可權問題的速度。結果是一個新的安全邊界，大多數企業架構尚未建模，因為大多陣列織仍然將其視為編排而非授權。

智慧體的連線速度超過了授權的適應速度

過去兩年，智慧體生態系統發展迅速。Anthropic的MCP為模型驅動的應用程式提供了連線工具、資料來源和服務的標準方式。谷歌的A2A協議為智慧體提供了跨系統通訊和協調的標準方式。LangChain、CrewAI和谷歌的ADK等框架和SDK使構建一個智慧體編排多個其他智慧體的多智慧體工作流變得更加容易。

這些協議尚未提供（至少作為一個成熟的通用層）的是一個委託感知的授權模型。

MCP將受保護的伺服器描述為OAuth 2.0資源伺服器，MCP客戶端作為代表資源所有者發出請求的OAuth客戶端。這是一個熟悉且易於理解的模式，但它是為人類點選“允許”且單個客戶端獲得作用域令牌的世界設計的。它沒有解決當智慧體A收到該令牌、將子任務委託給智慧體B、然後智慧體B產生智慧體C處理部分任務時會發生什麼。鏈中的每一跳要麼重用原始令牌（許可權過大），要麼根本沒有令牌（無法追蹤）。

A2A是為了互操作性而構建的：獨立的、可能不透明的智慧體系統在企業平臺上通訊和協調行動。這是正確的問題。但通訊和委託治理是不同的層次。A2A幫助智慧體發現、描述和相互通訊。這是必要的基礎設施，但不等同於委託許可權。它無法告訴你某個特定下游操作是否合法地源自上游指令。

靜態API金鑰對於這個問題甚至更弱。金鑰授予對服務的訪問許可權，但沒有說明誰在使用它、用於什麼目的，或者出示金鑰的實體是否與頒發給它的實體相同。服務賬戶標識一個工作負載，而不是一個意圖。當三個智慧體共享一個服務賬戶時，每個操作在你的日誌中看起來都一樣。

這些工具都沒有壞。它們解決不同的問題。差距是結構性的。身份驗證回答是哪個智慧體在呼叫。授權定義該智慧體可以訪問什麼。更難的問題（也是大多數企業架構尚未設計來回答的）是：某個特定下游操作是否合法地源自上游指令，在縮小的約束下，具有可驗證的鏈回溯到人類決策。這就是委託問題，它位於當今堆疊中尚未存在的層次。

在這種情況的乾淨版本中，許可權應該只屬於與外部世界接觸的智慧體。如果付款人（A）要求簿記員智慧體（B）進行支付，而簿記員要求銀行智慧體（C）執行轉賬，那麼只有銀行智慧體需要銀行許可權。簿記員不需要移動資金。它只需要知道請求來自授權的付款人。銀行智慧體只需要知道請求來自授權的簿記員。這是最小許可權原則（安全社群已經實踐了幾十年）應用於委託鏈。困難在於，當今的智慧體堆疊使得強制執行變得困難。

鏈中出了什麼問題

考慮一個受監管銀行中的財務報告工作流。一個規劃智慧體被允許讀取流動性預測併為高階財務使用者生成每日摘要。為了完成任務，它將圖表生成委託給視覺化智慧體，將敘述審查委託給通訊智慧體。視覺化智慧體不需要訪問原始賬戶級資料。通訊智慧體不需要訪問底層流動性模型。然而，除非委託層衰減許可權，否則兩者都可能接收到比任務所需更多的上下文。結果不是戲劇性的洩露，而是訪問的悄然擴充套件，訪問控制模型從未明確批准過。

風險不僅限於面向網際網路的智慧體。許多委託失敗完全發生在企業邊界內部。一個內部智慧體可能呼叫另一個內部智慧體，後者呼叫一個內部工具，該工具將資料傳送到批准的SaaS服務。每個單獨的步驟看起來都可以接受。風險出現在組合中：最終的資料移動或操作可能超出原始授權的意圖。

這種模式產生了三類可能迫使企業向監管機構、審計師或客戶解釋的失敗。

幽靈許可權。一個財務分析師助手被授予訪問客戶交易資料庫的許可權以支援季度報告。它呼叫一個摘要智慧體：“總結這些賬戶的近期交易。”摘要智慧體現在對客戶記錄進行操作，儘管沒有策略引擎授予它該訪問許可權。分析師助手的許可權有效地隨請求傳播。許可權是幽靈——在實踐中存在，但在任何授權系統中都不存在。

作用域漂移。即使智慧體開始時具有狹窄的許可權，委託也傾向於擴大而非縮小範圍。一個被授權讀取第一季度收入資料的智慧體委託給一個圖表智慧體，圖表智慧體呼叫一個外部渲染API，該API現在擁有收入資料。資料透過三跳隱式信任離開了組織。每個智慧體都在其理解的作用域內行動。彙總結果超出了任何人類會批准的範圍。

破碎的審計追蹤。受監管行業需要能夠回答“誰做了什麼以及為什麼”對於任何重要行動。在單智慧體系統中，這是可管理的。在多智慧體鏈中，審計追蹤碎片化地分佈在智慧體、協議和服務之間。當合規團隊詢問為什麼傳送了某個特定客戶通訊時，答案可能涉及兩個協議中的四個智慧體，沒有一個記錄了委託鏈。行動可追溯到系統，但不可追溯到決策。

這些不是邊緣情況。它們是當委託沒有被顯式建模時的常見結果。委託問題不是任何特定框架中的錯誤。它是它們之間層中的空白。

委託感知模型需要什麼

一個委託感知的授權模型必須同時解決四個問題，這也是為什麼沒有現有層能幹淨地覆蓋它的部分原因。

第一個是身份。下游智慧體需要一個接收系統可以獨立驗證的加密憑據，而不僅僅是主機名或API金鑰。主機名可能說謊。API金鑰會傳播。真實身份是呼叫系統無法偽造的。

第二個是衰減。當一個智慧體委託任務時，子智慧體應獲得嚴格少於父智慧體的許可權——絕不能相同，當然也不能更多。這是應用於委託鏈的最小許可權原則，幾乎沒有任何現有工具預設強制執行。

第三個是目的。“讀取這份報告以總結流動性風險給CFO”與“讀取這份報告並將選定資料傳送給外部圖表服務”是不同的授權。可能是相同的資料和相同的智慧體，但它們是兩個截然不同的風險概況。沒有目的繫結，授權層無法區分它們。

第四個是審計。組織應該能夠在事後重建誰委託了什麼、在哪些約束下、每個智慧體在完成時產生了什麼證據。不僅呼叫了哪些系統，而且做出了哪些決定以及基於誰的權威。

智慧體即使沒有可問責的權威也可以成功認證。它們可以證明自己是誰，但仍然執行從未經人類授權的操作。

新興方法

有幾項努力解決了這個問題的部分：工作負載身份標準、令牌中的智慧體後設資料、基於OAuth的MCP授權、A2A認證模式以及智慧體身份框架。這些都是有用的構建塊，但身份不等於委託許可權。簽名的智慧體卡片可以幫助建立智慧體的宣告身份和能力。OAuth令牌可以告訴你客戶端可以訪問什麼。兩者本身都不能證明特定下游操作是由特定上游決策在縮小的約束下授權的。

一種新興模式是委託繫結能力令牌：短期憑據，將呼叫繫結到智慧體身份、受約束的許可權集和來源記錄。一個例子是Agent Identity Protocol（AIP），我一直在網際網路草案和開源實現中工作。AIP仍然早期，但它說明了可能答案的形狀：呼叫繫結的令牌，攜帶身份、衰減的許可權和透過委託鏈的來源。令牌鏈本身成為審計證據的一部分，而不是事後從碎片化日誌中重建。

補充方法也在出現。行為憑據——智慧體應根據執行時行為而不是僅初始許可權不斷被重新授權的想法——解決了一個相關但不同的問題。委託令牌告訴你誰授權了什麼。行為監控告訴你智慧體是否仍在行動在其授權的配置檔案內。完整的解決方案可能兩者都需要。

這些方法都沒有達到主流採用。但它們同時從行業不同角落出現的事實表明，委託差距是真實且被認識的。

企業團隊現在應該做什麼

你不需要等待標準成熟再解決委託問題。安全、平臺和架構團隊今天可以採取具體步驟。

繪製你的委託鏈。大多數部署多智慧體工作流的團隊沒有記錄哪些智慧體呼叫哪些其他智慧體、具有哪些許可權、透過哪些協議。從那裡開始。如果你不能畫出圖，就無法保護它。

審計隱式許可權。對於每個智慧體到智慧體的互動，問：這個訪問是明確授予的，還是下游智慧體透過鄰近性繼承許可權？如果答案是繼承，你就有一個幽靈許可權，需要策略決策。

要求作用域衰減。建立一個架構規則：當一個智慧體委託任務時，子智慧體必須獲得少於父智慧體的許可權，絕不更多。當前工具不會自動強制執行這一點，但可以在你的編排層中強制執行。

在審計師詢問之前建立審計追蹤。如果你的組織在受監管行業，問題“誰授權了這個智慧體行動？”最終會被問到。在問題到來之前就裝備委託日誌記錄，而不是之後。記錄完整鏈：哪個智慧體發起了任務，每個步驟中的許可權是什麼，以及人類最終如何負責。