誰授權了？多智能體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仍然早期，但它説明了可能答案的形狀：調用綁定的令牌，攜帶身份、衰減的權限和通過委託鏈的來源。令牌鏈本身成為審計證據的一部分，而不是事後從碎片化日誌中重建。

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

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

企業團隊現在應該做什麼

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

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

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

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

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