最小權限原則套用在 agent 身上,具體是什麼意思?
最小權限原則本身不是 AI 特有的概念,在傳統資安領域早就存在——核心邏輯是「一個帳號或程式只應該擁有完成工作所必需的最少權限」。套用在 agent 身上,意思是每次讓 agent 執行任務時,只開放它這次任務真正需要用到的工具與資料存取範圍,而不是預先給它一整套廣泛權限,期待它自己「知道分寸」不去動用不必要的部分。
跟傳統軟體套用最小權限原則的差別在於,agent 是動態決策的——它不是照著固定流程跑,而是在執行過程中自己判斷下一步要用哪個工具。這代表最小權限原則在 agent 情境下,管的不只是「這個程式安裝時能存取什麼」,還包括「這個會自己做決定的東西,每一步能不能被允許執行到某個工具」。
為什麼 agent 特別需要強調最小權限,而不是像過去對 App 那樣「先全開再說」?
傳統軟體的行為路徑是固定的,開發者寫好程式邏輯,使用者知道這個程式「大概會做什麼」,就算給了較寬的權限,實際能造成的意外損害範圍也相對可預期。Agent 不一樣的地方在於,它的行為路徑是由當下的提示詞、外部資料、甚至攻擊者刻意植入的內容動態決定的——如果 agent 被給予了不必要的廣泛權限,一旦它的判斷邏輯被誤導(例如遭遇提示詞注入攻擊),能造成的損害範圍就等同於它「原本被允許但用不到」的那些權限。
換句話說,最小權限原則對 agent 而言不只是資安最佳實務,更是一種「限制潛在傷害上限」的機制——就算 agent 的判斷完全出錯,只要權限範圍夠窄,能造成的實際傷害也會被限制在很小的範圍內。
實務上要怎麼幫 agent 設定最小權限,有哪些具體做法?
最基本的做法是把權限拆成允許(allow)、拒絕(deny)、詢問(ask)三個清單,對於明確安全、會重複執行的操作放進允許清單,對於危險或不可逆的操作(例如強制刪除、強制推送)放進拒絕清單,其餘不確定的動作維持詢問狀態,由使用者當下決定。
對於外部工具(例如 MCP 伺服器)的存取,可以做到更精細的顆粒度——不是整台伺服器一次性信任或拒絕,而是針對伺服器底下的個別工具個別設定。例如一個 MCP 伺服器提供二十種功能,但當前任務只需要用到搜尋,只允許那一個工具,其餘維持詢問狀態,即使 agent 在執行過程中想呼叫其他工具,也會先被攔下來確認,而不是直接執行。
另一個常見做法是搭配沙盒化,在權限規則之外,於作業系統層級再加一層限制,讓 agent 能實際碰到的檔案系統與網路範圍,physically 被限制在允許範圍內——這樣即使判斷邏輯層面被繞過,實際能造成的損害依然有硬性上限。
如果我是個人使用者,幫 agent 設最小權限,平常該注意什麼?
最實際的起手式,是先盤點自己實際會用到的工具與外部連接,只針對真正需要的部分開放允許清單,而不是圖方便一次全開。這件事不需要企業級的管理工具就能做到,個人層級透過權限清單設定就能完成。
更容易被忽略的是「權限清單需要定期回頭檢查」——半年前為了某個專案信任的權限,如果專案結束後沒有跟著收回,那個信任範圍就會一直留在那裡,變成一個你可能已經忘記為什麼存在的破口。最小權限原則不是「設定一次就結束」的動作,而是隨著任務改變,持續調整權限範圍的過程。
Claude Code 資安指引裡提到,如果一個 MCP 伺服器提供二十種工具,而使用情境只需要用到搜尋功能,建議只允許 mcp__bigserver__search 這一個工具,其餘工具維持在詢問狀態,而不是用 mcp__bigserver__* 一次信任整台伺服器——這是最小權限原則在 MCP 工具設定上的具體實踐。
優點是能把 agent 判斷失誤時的潛在傷害範圍限制在最小,即使遭遇提示詞注入等攻擊,實際能造成的損害也有上限;缺點是設定與維護成本較高,需要持續盤點任務實際需要的權限範圍,而且顆粒度設得越細,遇到合法但未預期的需求時,越容易被「詢問」清單打斷工作流程。