主體漂移：企業智慧體架構中的身份、許可權與問責危機

在過去一年中，我審閱了大約二十多家企業的智慧體架構，包括銀行、零售商、醫療系統以及幾家監管機構。這些架構圖無一例外地令人印象深刻：MCP閘道器、工具登錄檔、向量儲存、編排器、策略引擎、可觀測性堆疊等模組一應俱全，箭頭標識著智慧體如何相互發現、共享上下文以及跨網格呼叫工具。按照2026年的標準，這些圖景是任何嚴肅的智慧體部署所必備的。但所有這些圖都沒有顯示：這些智慧體是誰？它們代表誰的權威？當它們出錯時，誰負責？

這個缺失有一個值得命名的稱謂：主體漂移——在任何足夠大的智慧體系統中，人類權威與實際行動者之間逐漸脫鉤。在你部署第一個智慧體時看似合理的身份態勢，隨著智慧體的倍增、組合以及壽命超過原始初衷而悄然退化。主體漂移並非三個獨立的故障模式，而是一個級聯：身份首先崩塌；接著是許可權侵蝕，因為不再有穩定的主體來繫結策略；最後是問責消失，因為智慧體錯誤造成的成本落到了事故覆盤時談判地位最弱的團隊頭上。要阻止這個級聯，必須在第一環就進行干預，但目前幾乎沒有企業智慧體平臺能做到這一點。

要觀察這個級聯的執行，我們來看一個最普通的退款智慧體。一名客服代表在處理聊天時要求智慧體為一件損壞商品處理48美元的退款。智慧體檢查資格、執行退款併發布更新。審計日誌記錄了動作由類似"refund-agent-prod-03"的實體執行，該實體執行於客服平臺團隊擁有的服務主體下。這條記錄是真實的，但毫無用處。智慧體並非以"refund-agent-prod-03"的身份行動，而是以客服代表的身份，代表客戶，沿著一條無人記錄的委託鏈。在構造良好的系統中，客戶、客服代表、智慧體身份和服務主體應同時記錄，可作為鏈式查詢，且持久化於會話之外。但當今大多數生產系統並非如此。這是級聯的第一環：身份坍縮為泛化的服務主體，再也沒有可繫結的“誰”。

許可權侵蝕隨之而來。退款智慧體擁有一個理論上可退款任何訂單的"issue_refund"工具。其許可權本應更窄（退款不超過200美元、訂單不滿90天、信譽良好的客戶、超過50美元自動升級），但該許可權存在於提示詞、YAML檔案或團隊最近一次在策略變更後便未更新的Notion頁面中。執行時強制能力，但無人真正強制許可權。當中毒輸入或混淆的推理鏈導致智慧體向錯誤客戶退款1800美元時，事後問題“誰批准了此策略”得不到清晰答案，因為策略從未作為工件存在。在高風險場景下情況更糟：想象一個擁有保護分支合併許可權的編碼智慧體，被嵌入程式碼註釋的提示詞指示“記錄配置值用於除錯”，卻靜默地將秘密外洩到外部監控服務。

接著問責消失。構建智慧體的團隊聲稱其遵循策略；編寫策略的團隊聲稱未預料到該輸入；運營平臺的團隊表示智慧體以服務主體執行，其行為不由他們負責。審計日誌可能記錄了動作，但未記錄產生該動作的推理、塑造推理的檢索上下文，以及構建檢索的提示歷史。事後覆盤變成了考古學，成本最終由會議結束時談判地位最弱的團隊承擔。

這一切是新的嗎？我們有IAM、身份治理、策略即程式碼、審計追蹤、SIEM以及30年的合規實踐。為何這不只是IAM的適當實施？因為IAM圍繞智慧體會違反的假設而構建。IAM和IGA假設主體群體在人類時間尺度上變化：人員入職、離職，服務賬戶每季度輪換。智慧體按會話生成並組合成鏈，一個智慧體呼叫另一個，後者再呼叫第三個，透過委託令牌模擬使用者，而傳統IGA根本無法將之表示為鏈。策略引擎在動作發生時刻觸發，作用於API、資料庫和網路。智慧體在到達這些執行點之前就已做出最關鍵的決策——選擇呼叫哪個工具及引數。成熟的審計日誌假設重放輸入可重現輸出，但對於智慧體，重放提示和檢索可能產生不同動作，因為模型本身貢獻了日誌未捕獲的狀態。儀器觸發，儀表盤變綠，但靜默外洩秘密的智慧體依然在執行。審計日誌記錄動作由"agent-service-01"執行，這同樣既真實又無用。

這也正是銷售統一堆疊的供應商希望你跳過的地方。微軟的Entra Agent ID（當前處於公開預覽階段）是迄今為止最成熟的方案，將為人類和工作負載使用的條件訪問、身份治理和身份保護擴充套件至AI智慧體這一新身份型別。谷歌和Salesforce也在構建這一層。營銷話術是智慧體將獲得與勞動力其他成員相同的身份驅動保護。這在解決級聯第一環上邁出了實際的一步，但它並非治理——它是一個控制平面，卻有著治理平面的營銷。條件訪問能告知你智慧體的訪問嘗試是否被允許，但它無法告知你智慧體在訪問嘗試之前所做的決策是否在其許可權內，為何做出該決策，或者哪個業務單元擁有該決策應遵循的策略。

真正的治理平面必須捕獲決策，而非僅捕獲動作。一個推理級的審計記錄是缺失層的承載基元，它大致如下：

{ "event_id": "refund-2026-05-17-08431", "triggered_by": { "human_principal": "rep:[email protected]", "delegated_via": "support-console-session-9c2a", "customer_principal": "cust:7741289" }, "agent": { "identity": "refund-agent", "version": "v4.7.2", "policy_ref": "refund-policy/v3.1 (signed: r.patel, 2026-04-22)" }, "task": "Process refund for order 88812204", "retrieved_context": [ {"doc": "order:88812204", "fetched": "2026-05-17T08:43:11Z"}, {"doc": "policy:refund-eligibility", "chunk": 4, "fetched": "2026-05-17T08:43:12Z"} ], "reasoning_trace": "...", "tool_calls": [ {"tool": "check_eligibility", "input": "...", "output": "eligible"}, {"tool": "issue_refund", "input": {"amount": 48.00}, "output": "ok"} ], "action": "refund:48.00", "principal_chain_hash": "0x9e7b3f..." }

並非所有智慧體都需要此記錄。一個安排會議時間的排程智慧體不需要。但移動資金、部署程式碼或做出監管者最終會過問的決策的智慧體則需要，這正是應設定的門檻，因為其關聯成本高。推理級審計更接近飛行記錄器而非系統日誌饋送。儲存和查詢這些資料成本高昂，且涉及真實隱私問題，因為這些日誌包含智慧體所見的一切，包括智慧體有權讀取但審計系統本不應保留的資料。可透過按比例保留來承擔成本：高爆炸半徑智慧體（面向監管、客戶資金、合同重大、修改生產）進行完整推理捕獲；內部輔助工具進行輕量捕獲。

這引出了架構圖中未提出的問題：誰構建並執行這些？安全團隊可強制策略但無法制定策略；瞭解退款智慧體應被允許做什麼的人擁有退款業務而非防火牆；IT可配置身份但無法起草“信譽良好”或編寫升級規則。MCP和A2A協議社群在傳輸級身份和委託方面做了實際工作：MCP提供工具呼叫溯源，是Entra Agent ID及大多數供應商框架構建的標準；A2A正在趨近跨智慧體委託原語。兩者都重要，但均不制定策略。聯結器由標準而非機構推動。

企業需要一個位於擁有策略的業務單元與執行時的平臺團隊之間的新職能：稱之為智慧體運營——一個通常4-8人的小組，嵌入而非集中，向CIO或CISO彙報（取決於內部政治），明確負責維護每臺生產智慧體的登錄檔、其命名的人類所有者、版本化的許可權規範、推理級審計的保留策略及其生命週期狀態。每個智慧體經過簽署策略的上線稽核，按實際節奏審查，並在其初始目標結束時真正退役，而非像當前這樣靜默地存活於其發起人之後。設計時需防範故障模式，如審查節奏僵化為形式、策略工件滯後於智慧體部署速度、或該職能成為智慧體被委員會否決而死亡的地方。該職能必須跟上平臺團隊的速度，否則一個季度內就會被繞過。

這項工作艱鉅且早該進行，而監管的時鐘正在滴答作響。歐盟AI法案高風險條款今年將進入執行階段，監管機構會要求可解釋性、可追溯性、生命週期記錄以及命名的人類問責——這正是智慧體運營職能產出的工件。Tyler Akidou在其四月的Radar文章中稱此為缺失的HR層；Artur Huk更近期的《從能力到責任》從執行時角度得出了相似結論。標籤不如工作重要。本文涉及組織內部的治理；更困難的是跨組織治理，即智慧體在不同信任體制下運作。這嚴格來說更糟，值得另文探討。

在你自己的四牆之內，診斷一下午即可完成：選取一個生產智慧體，嘗試用證據回答：它承載誰的權威——從動作回溯到命名的人類？它的許可權在哪裡說明，誰簽署了當前版本？明天它做錯事時，誰付出代價，如何決定，以及有什麼推理級記錄支援該決定？大多數誠實進行此練習的架構師都會得到三個空白和內心的不安。這就是主體漂移——被命名並可見的漂移。

你構建的網格是真實且必要的，但不夠充分。其餘的架構是其上的制度：登錄檔、簽署的策略、推理級審計、每條鏈條末端的命名人類。在大多數企業中，它尚不存在，並且不會透過購買另一個平臺而到來。你必須自己起草它。