AI智能體的治理：身份、委託與權限實踐

AI智能體在現代系統中執行任務時，其身份和權限管理成為關鍵挑戰。許多團隊為了快速部署，往往讓智能體共享API密鑰或直接使用開發者的憑證，這導致了嚴重的治理漏洞。本文提出了一種基於委託的治理模型，確保每個智能體都有明確的身份、有限的權限，並且每項操作都能追溯到授權源頭。

**錯誤的做法**

第一種錯誤做法是“模擬用户”。智能體繼承人類用户的所有權限，導致權限過度膨脹。例如，一個客服代表觸發智能體查詢訂單，智能體卻可能接觸到財務報表、HR記錄等完全無關的數據。一旦遭遇提示注入攻擊，攻擊者就能獲取用户的所有API權限。審計日誌也無法區分是人類操作還是智能體行為。

第二種錯誤做法是使用服務賬户。雖然智能體有了獨立身份，但問責困難：服務賬户無法被解僱、無法在事件覆盤中被質詢。當設置它的工程師離職後，權限可能長期未被審查，形成安全隱患。NIST SP 800-207將其稱為“僅基於所有權的隱式信任”，違背了零信任原則。

**委託模型：正確的路徑**

正確的模型是：智能體擁有自己的身份，但代表人類行動。兩個身份都被保留，權限是智能體角色與委託者權限的交集。用公式表示：有效權限 = 智能體角色 ∩ 委託者權限。實習生觸發管理級智能體？只有實習生級別的結果。管理員觸發受限智能體？智能體只能執行其角色範圍的操作。雙方不會互相升級權限。

Red Hat將此稱為“驗證並永不信任”，NIST SP 800-207則強調在建立會話之前分別進行身份驗證和授權。這一原則同樣適用於AI智能體。

**身份是錨點**

智能體需要一個永久的、穩定的標識符，與人類使用相同的身份系統、目錄、生命週期和吊銷路徑。沒有獨立身份，智能體就是系統中的“幽靈”，無法被命名、吊銷或調查。

**天花板與地板**

每次操作強制執行兩重邊界：天花板（智能體的角色上限，由管理員設定）和地板（委託者的權限下限）。有效權限總是取兩者中較窄的。例如，一個僅具有發票讀取和創建權限的智能體永遠無法接觸薪資數據，因為平台層阻止了該調用，而非依賴LLM的誠實。

當智能體被提示注入攻擊時，其操作範圍仍被交集限制，爆炸半徑由數學保證，而非靠希望。

**智能體不感知權限**

關鍵設計：智能體不攜帶任何令牌，不檢查權限，也不知道委託用户的信息。所有授權都在平台層完成，位於智能體進程、提示詞和攻擊者可達範圍之外。這樣，相同的智能體代碼可以因委託者不同而擁有不同的有效範圍，無需代碼變更，僅需配置。

**自主觸發器與失效授權**

對於定時任務、webhooks等自主觸發場景，沒有人類在場參與委託。規則不變：無委託上下文即拒絕。每個自主觸發器由人類創建，系統在創建時記錄委託者，並在每次分派時重新驗證：委託是否存在？是否有效？委託者是否仍有權限？任何檢查失敗，智能體不執行。

如果離職工程師設置的同步任務未受此約束，它可能長期運行已失效的授權；而此機制能讓離線委託者自動失效，無需手動清理。

**每個動作兩個名字**

每次操作記錄兩個身份：執行者（如invoice-agent）和授權者（如[email protected]），以及觸發方式。審計在數據庫觸發器層面捕獲，與數據修改在同一事務中，智能體無法繞過或篡改。

**令牌契約**

內部委託令牌遵循RFC 8693（令牌交換）：僅包含身份，權限每次從數據庫按需解析；短生命週期（120秒）；限定接收服務。令牌只説明“此智能體代表此人類”，平台在每次請求時決定組合的權限。

**RootCX中的實踐**

每次在RootCX Core上部署的智能體自動獲得治理身份，無需配置。確定性身份、與人類相同的RBAC、每次工具調用的交集計算、自主觸發的常設委託驗證、智能體外的平台級授權、雙重身份審計、短生命週期令牌。構建者無需考慮治理，平台像Okta處理人類認證一樣透明地處理。

**8點檢查清單**

1. 每個智能體是否有獨立身份？
2. 是否有按智能體設置的能力上限？
3. 有效權限是否是交集？
4. 無委託者是否等於拒絕？
5. 智能體是否不感知權限？
6. 自主觸發是否有常設委託？
7. 令牌是否短生命週期且限定受眾？
8. 審計追蹤是否包含兩個身份？

8/8意味着受治理的智能體，否則只是披着風衣的腳本與API密鑰。