研究分析 發布於 AIA: 2026年4月16日

Claude Code 的受保護路徑與自動模式：被繞過的控制邊界

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

Permission BypassTool AuthorizationAgentic AIAI Coding Agent
9 項對應的 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）就不再代表同一條控制邊界。
  • 自動模式減少了開發流程的阻力，但也拉高了驗證門檻。 用分類器做的核准機制，或許比全面繞過更合理，但防禦方現在必須拿出證據，證明它在自己實際的工作流程下真的安全。

適用的 9 項 AIDEFEND 防禦手法

AID-M-009.002
Authority Envelope & Action Risk Classification
極高
把寫入 .git/、.claude/、skill 資料夾、CI 定義和政策檔案的動作，歸類為一般程式撰寫範圍外的控制面操作。這裡產出的是機器可檢查的風險事實；真正的嚴格處置由受保護路徑與 runtime 控制執行。
AID-H-021.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.006
Capability-Tier Control-Profile Binding & Assurance Gate
高
把 coding agent 提升到 auto 或無人值守模式，本質上是提高能力層級。這項控制要求升級前先有保證證據，例如 protected path 已落實、核准規則仍有效、policy 檔不可被 agent 任意改寫、記錄可用，而且有 rollback 或降權路徑。
AID-H-021.004
Control-Plane & Oversight-Surface Isolation
高
.claude policy、skill registry 和 agent 設定這類 protected path，是監督面與控制面的一部分。正在執行的 agent 不應該能讀取、修改、停用或繞過那些決定它能做什麼的 policy 與監督資源。
AID-M-009.004
Runtime Trust-State Demotion & Autonomy Narrowing
高
如果 agent 從一般程式碼修改轉向受保護路徑寫入，或重複觸發需要核准的動作，就為這個 agent 與證據集合發布有簽章、有時效的 Restricted trust state。外部控制迴圈再消費這個狀態，真正執行暫停或切到唯讀模式。
AID-H-018.007
Skill-Level Permission Manifest Validation & Runtime Enforcement
高
要求 skill 和本地自動化明確宣告自己能不能碰受保護的狀態，並在執行期擋掉所有沒宣告過的寫入，包括 agent 設定、skill 登錄檔、或持久身分檔案。
AID-H-017.001
Interruptible Agent Control Loops & Structured State Auditability
高
把 coding loop 放在外部 orchestrator 控制下，對外呈現結構化狀態轉換，並在受保護路徑的變更送出前暫停、要求核准、降級或終止執行。這是 unattended mode 的直接執行期控制，不需要記錄模型隱藏的 chain-of-thought。
AID-D-015
High-Risk Approval Bypass & HITL Activity 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 的團隊，可以在這個基礎上再加一層跨介面的權限驗證。