Least Privilege 是傳統資安領域早就存在的概念，套用到 AI Agent 上有什麼是傳統系統設計不需要特別考慮的？
最大的差異來自「誰在決定要不要使用這個權限」。傳統系統的最小權限設計裡，權限的使用時機是由確定性的程式邏輯決定的——例如一個後端服務只有收到符合特定格式的請求才會執行資料庫寫入，這個判斷邏輯是工程師寫死的，不會因為輸入內容不同而「被說服」去做原本不該做的事。
AI Agent 完全不是這樣。Agent 什麼時候使用被授予的權限，是由 LLM 的推理過程決定的，而推理過程會受到輸入內容（用戶指令、工具回傳的資料、甚至是網頁上的文字）影響。這代表即使 Agent 的權限設計完全正確（只給了完成任務必需的最小範圍），如果推理過程被 Prompt Injection 操縱，Agent 仍然可能「被說服」在不該使用權限的情境下使用它——例如一個只被授權在特定 DeFi 協議進行小額交易的 Agent，如果讀取到的頁面內容裡藏了惡意指令，可能被誘導把授權範圍內的資金,轉去一個惡意地址,而不是原本該去的協議地址。
這代表 Agent 場景的 Least Privilege 設計，除了傳統的「權限範圍要小」之外，還必須疊加「就算權限被誤用,造成的傷害也要有上限」這一層防禦——也就是說,權限範圍的設計不能只考慮「正常情況下夠用就好」,還要考慮「萬一這個權限被 Prompt Injection 誘導誤用,最壞情況下能造成多大傷害」,兩者是不同層次的問題,傳統系統設計通常不需要特別考慮後者,因為傳統系統的執行邏輯不會被輸入內容「說服」去做壞事。
設計 Agent 的最小權限時，「查詢型」和「執行型」權限分離具體怎麼實作？光是分開兩個 API Key 就夠了嗎？
分開 API Key 是必要的第一步，但不是充分的實作——單純分開 Key，如果兩把 Key 對應的底層帳戶權限沒有真正被限制，仍然可能出問題。完整的實作需要三層：
第一層：帳戶層級的權限隔離。查詢用的憑證應該對應一個「唯讀」帳戶或 API 金鑰,在服務端(例如交易所或錢包服務商)就已經被設定為不具備簽署交易的能力,而不是只在應用層邏輯裡「假設」這把 Key 只會被用來查詢。這一點很關鍵——如果查詢用的 Key 技術上其實有能力簽署交易,只是應用邏輯「不會」呼叫簽署功能,一旦應用層邏輯有漏洞(例如被 Prompt Injection 誘導呼叫了不該呼叫的功能),這把 Key 依然能造成傷害。真正的最小權限,權限限制必須落實在憑證本身的能力範圍,而不是依賴應用層的「不會這樣用」。
第二層：執行型權限的細粒度控制。就算是執行型的憑證,也不該是「什麼都能做」的萬用權限,而應該根據任務類型進一步切分——例如「只能在協議 A 進行交易」的憑證,和「可以跨多個協議操作」的憑證,是不同等級的權限,不該用同一把 Key 涵蓋所有執行場景。
第三層：時效性限制。執行型憑證應該有明確的有效期限,任務完成後立即失效或被撤銷,而不是長期有效、只靠應用邏輯決定「這次不呼叫它」。這樣即使憑證本身外洩,能被濫用的時間窗口也被限制在很短的範圍內。
光分開兩個 Key 但底層權限範圍沒有實際限制,是「形式上做了最小權限,但實質上沒有」的常見陷阱。
如果一個 Agent 任務本身就需要比較大的權限範圍（例如一個資產管理 Agent，任務就是要能自由調度用戶的資金），這種情況下最小權限原則還適用嗎？
適用，而且這正是最小權限原則最能發揮價值的情境——「任務需要大權限」和「應該無限制地授予大權限」是兩件不同的事,最小權限原則不是說「不能給大權限」,而是說「權限範圍要精確對應任務範圍,不多不少」,即使這個任務本身範圍就很大。
具體做法有三個方向:
把「大權限」拆解成可組合的小顆粒權限,而不是一個籠統的「完全控制」權限。一個資產管理 Agent 需要的可能是「在預先核准的協議清單內操作」「單筆交易不超過用戶設定的上限」「日累計交易額不超過某個門檻」這幾個具體、可驗證的子權限組合,而不是一個「可以對這個錢包做任何事」的萬用權限。即使加總起來這些子權限確實涵蓋了很大的操作範圍,拆解成可獨立驗證、可個別撤銷的顆粒,仍然比一個籠統的大權限安全得多——因為任何一個子權限出問題,傷害範圍被限制在那個子權限本身,不會波及其他權限。
引入分層授權而非一次性全授權。日常小額操作用 Agent 自主權限完成,超過某個門檻的操作觸發人工確認(例如推送通知給用戶,需要用戶手動批准才會執行)。這讓「任務需要大範圍操作能力」和「每一次操作都不需要人工介入」這兩件事分開處理——大範圍的能力可以存在,但高風險的單次操作仍然保留人工把關這道防線。
動態調整權限範圍而非固定授權。根據 Agent 過去的行為記錄動態調整信任等級——例如一個 Agent 過去 30 天內的操作都符合預期、沒有觸發任何異常告警,可以適度放寬單筆交易上限;一旦偵測到異常行為模式(例如短時間內大量小額測試性交易,這是攻擊者常見的探測手法),立即收緊權限範圍甚至暫停執行能力,等人工審查後才恢復。
核心原則不變:即使任務範圍大,權限範圍也應該被拆解到「每個顆粒都對應一個明確、可驗證的必要性」,而不是因為任務範圍大就放棄精細設計,直接給一個籠統的高權限了事。
在多 Agent 系統裡，Orchestrator 通常需要協調多個 Sub-agent 完成任務，Orchestrator 本身該擁有所有 Sub-agent 權限的聯集嗎？
不應該，這是多 Agent 系統設計裡一個容易被忽略、但影響很大的最小權限違反案例。
直覺上似乎合理:Orchestrator 要「指揮」所有 Sub-agent,所以應該擁有能涵蓋所有 Sub-agent 工作範圍的權限,這樣才「方便管理」。但這個直覺是錯的,原因在於它把「協調」和「執行」這兩種完全不同的角色混為一談。
正確的權限設計應該是:Orchestrator 本身不直接持有任何執行型權限(例如簽署交易的能力、寫入資料庫的能力),它的角色純粹是「決定要呼叫哪個 Sub-agent、傳什麼參數」。真正的執行型權限,應該分散持有在各個 Sub-agent 手上,且每個 Sub-agent 只持有自己任務範圍所需的最小權限——例如負責鏈上交易執行的 Sub-agent,才持有簽署交易的憑證;負責讀取資料庫的 Sub-agent,才持有資料庫存取憑證。Orchestrator 完全不持有這些憑證,它只是決定「現在該呼叫哪個 Sub-agent」。
這樣設計的安全價值:如果 Orchestrator 本身被攻破(例如 Orchestrator 使用的 LLM 被 Prompt Injection 操縱),攻擊者能做的最壞情況,是誘導 Orchestrator 去呼叫某個 Sub-agent 執行一個「該 Sub-agent 權限範圍內」的操作——但如果 Sub-agent 本身的權限已經被限制到最小,這個操作能造成的傷害仍然有上限。相對地,如果 Orchestrator 本身握有所有 Sub-agent 權限的聯集,一旦 Orchestrator 被攻破,攻擊者能直接動用系統裡所有的權限,傷害範圍不再有任何上限。
這個設計原則常被稱為「權限應該跟著執行者走,而不是跟著協調者走」——協調者只需要知道「該找誰做這件事」的資訊,不需要自己有能力做這件事。
一個鏈上收益優化 Agent 的最小權限實作案例
某個自動在多個 DeFi 協議間移動資金找最優利率的 Agent，權限設計如下：
分離的憑證架構：Agent 持有兩把完全獨立的憑證——「查詢憑證」對應一個唯讀的 RPC 節點存取金鑰，可以查詢任何協議的利率、TVL、historical數據，但這把金鑰在服務端就沒有簽署能力，就算 Agent 的推理邏輯被誘導去嘗試用它簽交易，服務端會直接拒絕（不是靠應用邏輯判斷不呼叫，而是金鑰本身沒有這個能力）；「執行憑證」對應一個真正能簽署交易的錢包私鑰，但這把私鑰是透過一個智能合約錢包（而非直接的 EOA 私鑰）持有，合約層面設定了「單筆轉帳不超過用戶資金的 10%」「只能與白名單內的 5 個協議地址互動」兩條硬性規則，這兩條規則寫在合約邏輯裡，不是應用層的軟性限制,即使 Agent 的推理被完全操縱,也無法讓合約執行超出這兩條規則的操作。
任務範圍動態調整權限：如果用戶把某個協議從白名單移除,Agent 的執行憑證在合約層面立即失去對該協議的操作能力,不需要等應用程式重新部署或更新邏輯——權限收緊直接發生在憑證能力本身,而非依賴應用邏輯及時更新。
分層授權應對高額操作：單筆金額在 10% 上限內的操作,Agent 自主執行;如果套利機會需要移動超過這個比例的資金(例如發現一個利率差距特別大的機會),系統會推送通知給用戶,需要用戶手動簽署一筆額外的「臨時提高上限」交易,Agent 才能執行——高額操作的最終決策權始終保留在人類手上。
這個案例展示的關鍵原則:權限限制沒有依賴「Agent 的推理邏輯足夠可靠、不會做壞事」這個假設,而是把限制刻在智能合約和金鑰能力本身的層次——就算最上層的 LLM 推理被完全操縱,能造成的傷害也被合約規則鎖死在一個明確的上限內,這正是「假設 Agent 隨時可能被誘導,但傷害範圍依然可控」的最小權限設計思路。
Least Privilege 的核心取捨是「安全邊界的細緻度 vs 開發與維護的複雜度」。權限拆解得越細（每個子任務都有獨立的、範圍精確的憑證），安全邊界越紮實，單一環節出問題的影響範圍越小；但每多拆一層權限，就多一層需要開發、測試、維護、監控的憑證管理邏輯，對小型團隊而言可能超出實際的工程負荷。另一個取捨是「靜態權限 vs 動態調整權限」：動態根據 Agent 行為歷史調整信任等級（表現良好放寬、異常收緊）能讓系統在保持安全的同時提升效率，但動態調整機制本身的判斷邏輯如果設計不當（例如異常偵測的閾值設得太寬鬆），反而可能被攻擊者利用「先建立良好行為記錄再發動攻擊」的策略繞過。建議：核心資金操作相關的權限一律採用最嚴格的靜態拆解（不因為信任提升就放寬資金上限這類高風險權限），信任動態調整機制留給低風險的操作範圍（例如查詢頻率限制、非資金類功能的存取範圍），避免把安全性最關鍵的防線,建立在「行為良好=值得信任」這種可能被長期潛伏攻擊繞過的動態假設上。