Agent 權限管理,跟一般軟體的權限設定有什麼不同?
一般軟體的權限設定通常是靜態的:安裝時決定這個 App 能不能存取相簿、能不能連網,設定完之後行為就固定了。Agent 的權限管理不一樣的地方在於,agent 是在執行過程中動態決定要呼叫哪個工具、要不要讀某個檔案、要不要執行某段指令——這代表權限系統管的不是「這個程式能做什麼」,而是「這個會自己做決定的東西,每一步決定能不能被執行」。
這也是為什麼 Claude Code 的權限系統要分成三層:規則決定「能不能用這個工具」,MCP 範圍控制決定「能不能連到這個外部系統」,沙盒則是在作業系統層級補上最後一道防線——就算前兩層的判斷邏輯出錯,超出邊界的操作依然會被攔下來。
為什麼不能只靠「權限規則」一層就好,一定要加沙盒?
權限規則的判斷邏輯,本質上是 Claude 自己在執行前先確認「這個動作有沒有被允許」——但這代表如果有攻擊手法能繞過 Claude 的判斷邏輯本身(例如透過提示詞注入,讓 Claude 誤判某個惡意指令是合法請求),權限規則這一層可能會被連帶繞過。
沙盒解決的正是這個問題:它不是靠 Claude 自己判斷,而是在作業系統層級直接限制 Bash 指令與其子行程能碰到的檔案系統與網路範圍,就算前面的判斷邏輯出錯,沙盒依然能物理性地擋下超出邊界的操作。這也是為什麼資安指引會強調「如果沙盒沒開,權限系統就是 Claude 跟你的檔案系統之間唯一的防線」——單一防線一旦被繞過,就沒有第二層可以補救。
實際設定的時候,允許清單(allowlist)該怎麼寫,才不會設得太寬鬆或太麻煩?
MCP 工具的命名慣例是 mcp__伺服器名稱__工具名稱,這讓你可以選擇兩種精細度。如果團隊已經確定信任某個 MCP 伺服器(例如公司內部固定拿來管理專案的服務),可以直接把整台伺服器加進允許清單,像是 mcp__linear__*,讓 Claude 對那台伺服器底下的所有工具都不需要每次詢問。
但如果是一個功能龐雜的 MCP 伺服器,裡面有二十種工具,而你的使用情境只需要用到搜尋功能,更保守的做法是只允許那一個工具,例如 mcp__bigserver__search,其餘工具維持在「詢問」狀態——這樣即使某次任務不小心誘導 Claude 想呼叫其他工具,系統還是會先停下來問你,而不是直接執行。實務上,「整台伺服器信任」跟「單一工具信任」是兩種都值得保留的模式,差別在於你對那台伺服器的信任程度有多高。
如果我只是個人使用者,不是企業管理員,這些權限設定跟我有什麼關係?
即使不是企業環境,只要你在用 Claude Code 連接 MCP 伺服器、讓它讀寫本機檔案或執行指令,權限設定就直接影響「一次判斷失誤,代價有多大」這件事。預設情況下任何人執行 Claude Code 都可以自行連接任何 MCP 伺服器,如果沒有刻意設定拒絕清單或啟用沙盒,一個來源不明或設計不良的 MCP 伺服器,理論上就有機會存取超出你預期範圍的資料。
對個人使用者來說,最實際的起手式是:先確認自己專案裡實際用到哪些 MCP 伺服器與工具,只針對真正需要的部分開放允許清單,其餘維持詢問;接著用 /sandbox 指令啟用沙盒,讓檔案系統跟網路存取都被限制在明確範圍內。這兩件事都不需要複雜的企業級設定,是個人使用者也能立刻做的最小防護。
把一個能讀檔案、寫檔案、執行指令、還能連上外部服務的 agent 放進工作流程裡,好處很明顯,但風險也很具體:如果沒有明確的權限邊界,agent 能做的事,基本上等同於「拿到你電腦的人能做的事」。權限設定不是可有可無的細節,而是決定 agent 能不能安全落地的核心機制。
Claude Code 的安全機制建立在三層之上,各自處理不同的失效模式:第一層是權限規則,決定 Claude 可以使用哪些工具、執行哪些指令;第二層是 MCP 存取範圍控制,限制 Claude 能連到哪些外部系統;第三層是沙盒化,在作業系統層級強制執行檔案系統與網路的邊界。三層各自獨立運作,某一層失效時,其他層仍然能提供保護——這也是為什麼只設定其中一層,例如只做權限規則但沒開沙盒,防護力會明顯不足。
權限規則本身由三個元素組成:允許(allow)、拒絕(deny)、詢問(ask)清單,寫成工具比對規則;權限模式(default / accept-edits / plan / bypass)決定整個 session 的運作基調;以及對危險操作(例如強制刪除、強制推送、發布動作)的明確攔截。多數實際場景的配置會落在「每個動作都要詢問」跟「完全信任、全部自動執行」這兩個極端中間,依專案風險程度往其中一邊傾斜。
MCP 工具遵循固定命名慣例 mcp__<伺服器名稱>__<工具名稱>,這讓權限規則可以做到「整台伺服器信任」或「單一工具信任」兩種精細度。如果團隊的專案管理都靠某個 MCP 伺服器完成,直接把整台伺服器加入允許清單是合理的;但如果一個 MCP 伺服器提供二十種工具,而你只需要用到其中的搜尋功能,精確只允許那一個工具、其餘維持詢問狀態,是更保守也更容易稽核的做法。
對組織管理者而言,還有另一層控制:透過 managed-mcp.json 部署固定的核可伺服器清單,搭配 allowedMcpServers 這類設定,限制開發者可以連接哪些 MCP 伺服器——例如只允許 company-* 這種內部維護的伺服器命名模式。要注意的是,允許清單與拒絕清單本身不是「登記系統」,伺服器必須先被使用者、外掛或設定檔加入,清單規則才會真正生效。
權限規則決定 Claude 連嘗試都不能嘗試某個受限資源;沙盒則是就算某個提示詞注入攻擊繞過了 Claude 的判斷邏輯,依然能在作業系統層級擋下超出邊界的操作。這兩層是互補而非替代關係——沙盒只作用在 Bash 指令與其子行程上,檔案系統的限制實際上是透過 Read/Edit 的拒絕規則實現,網路限制則要搭配沙盒的允許網域清單與 WebFetch 權限規則一起使用。單靠權限規則,理論上仍有被繞過的可能性;單靠沙盒,則管不到工具選擇本身的決策層面。兩者疊加使用,才是目前建議的最小可行安全配置。