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金鑰。