文章 發布於 AIA: 2026年4月16日

Claude Code 的 Protected Paths 與 Auto Mode：被繞過的控制邊界

2026 年 3 月 31 日的這篇文章指出，Claude Code 2.1.78 之後加入了受保護路徑（Protected Paths）的覆寫機制，後續又推出用分類器（classifier）判斷的自動模式（Auto Mode），權限處理不再是「找漏洞、鑽漏洞」的老問題，而是「agent 行為要怎麼管」的新問題。實務上的重點，是把 Git 狀態、agent 設定、還有不同介面的核准行為，都當成受保護的控制面資產來管。

Agentic AIInfrastructureDefense
7 項對應的 AIDEFEND 防禦手法
來源: Claude Code Just Broke Bypass Permissions. Here Is the Fix. 
作者 Noah Albert · 原文發布: 2026年3月31日

威脅分析

  • 重點不只是功能壞掉。 真正的風險不是傳統的繞過型漏洞利用，而是 coding agent 的實際權限已經改變，但使用者卻還以為它能穩穩地無人值守跑下去。
  • 受保護路徑其實就是真正的控制面。 像 .git/、.claude/、.claude/skills/ 這些位置應該當成高機敏資產，因為改到它們就可能重寫歷史、改變政策，或讓 agent 在之後的執行中自我修改。
  • 介面差異本身就是資安問題。 即使是同一個 AI 工具（像 Claude Code），如果 CLI、VS Code、桌面版和未來其他封裝層的權限的執行方式不一致，那同一個模式名稱（像 Bypass Permissions、Auto Mode）就不再代表同一條控制邊界。
  • 自動模式減少了開發流程的阻力，但也拉高了驗證門檻。 用分類器做的核准機制，或許比全面繞過更合理，但防禦方現在必須拿出證據，證明它在自己實際的工作流程下真的安全。

適用的 7 項 AIDEFEND 防禦手法

AID-M-009.002
Authority Envelope & Action Risk Classification
極高
把寫入 .git/、.claude/、skill 資料夾、CI 定義和政策檔案的動作，歸類為控制面操作，明確劃出這些動作不在一般程式撰寫的範圍內，每次都要走更嚴格的流程。
AID-H-022.001
Client-Side Configuration Enforcement
極高
在用戶端或 pre-commit 層先擋掉不安全的權限設定、有風險的封裝層設定、還有政策偏移，避免開發者在權限過度寬鬆的狀態下就把 agent 跑起來。
AID-I-004.006
Agent Identity & Persistent State File Write Protection
極高
對高機敏的設定檔和持久狀態檔案（像 agent 記憶檔、身分憑證、skill 登錄檔）加上寫入保護，避免 agent 偷偷動到會影響未來權限、記憶、或身分的檔案。
AID-M-009.004
Runtime Trust-State Demotion & Autonomy Narrowing
高
如果 agent 從一般的程式碼修改，轉向受保護路徑的寫入、或重複觸發需要核准的動作，就要立刻把它降級到受限或唯讀模式，而不是讓流程繼續全權跑下去。
AID-H-019.007
Skill-Level Permission Manifest Validation & Runtime Enforcement
高
要求 skill 和本地自動化明確宣告自己能不能碰受保護的狀態，並在執行期擋掉所有沒宣告過的寫入，包括 agent 設定、skill 登錄檔、或持久身分檔案。
AID-D-004.003
Runtime Configuration & Policy Drift Detection and Monitoring
中
持續監控 CLI、IDE、桌面版或執行器的行為，看看還符不符合當初核准過的權限基準，讓團隊早一步抓到特定介面的執行偏移，避免無人值守的工作出錯或越權。
AID-D-015.002
High-Risk Action Confirmation Telemetry & Bypass Detection
中
受保護路徑寫入與自動模式核准都需要留下可稽核證據。把確認提示、使用者核准、分類器判斷和實際檔案修改串起來，才能發現某個受保護動作沒有經過預期的額外核准，或某個介面繞過確認流程。

身為資安防禦者，我們應該這麼做

  • 把 .git/、.claude/、skill 資料夾、CI 定義和本地 agent 政策檔案都當成受保護的控制面資產，不要當成一般專案檔案看待。
  • 權限核准不能一視同仁：一般程式碼修改可以低阻力地跑，但受保護路徑寫入、設定變更、分支或歷史異動、skill 安裝，都要重新走一次明確核准。
  • 每次用戶端或版本變動，就回歸測試一次 CLI、VS Code、桌面版、還有 CI 執行器的權限行為，不要只相信模式名稱。
  • 對 agent 設定、Git 中繼資料、和持久狀態檔案（像 agent 記憶、身分憑證、skill 登錄檔）加上寫入保護和偏移警示，讓 agent 想偷偷改自己（權限、記憶、身分）的嘗試能馬上浮出來。
  • 如果你要用自動模式或分類器做的核准機制，先用實際工作流程測出偽陰性和中斷狀況，確認沒問題後，再把它當成安全的無人值守機制來用。

1 個額外的防禦考量

跨介面權限控制的一致性驗證

除了上面對應的防禦技術，在多種用戶端上使用 Claude Code 的團隊還可以再加一層跨介面一致性驗證：在啟動任何無人值守流程之前，先確認 CLI、IDE 擴充功能、桌面版、還有遠端執行器，跑的都是同一套受保護路徑和核准規則。
建議做法: 補上一套跨介面一致性迴歸測試：對每個支援的用戶端，都實際測試代表性的檔案寫入、shell 呼叫、受保護路徑異動，再決定要不要放行自動模式或其他阻力較小的執行路徑。

結論

這個案例再次提醒我們：agent 權限是安全控制面的一部分，不只是 UX 設定。AIDEFEND  在權限範圍劃分、執行期降級、設定的落實、還有持久狀態保護這幾塊，都已經給出實用的對應；大規模採用 Claude Code 的團隊，可以在這個基礎上再加一層跨介面的權限驗證。