Claude Code Auto Mode 8 月 14 日成預設：89% 攔截率，夠安全嗎？（2026）

2026 年 8 月 7 日，Anthropic 在官網發布〈Auto mode is now the default in Claude Code for Pro, Max, and Team plans〉，宣布 Claude Code Auto Mode 將自 8 月 14 日起，成為 Pro、Max 與 Team 新 session 的預設權限模式。這不是 Claude 模型能力升級，而是把原本交給使用者逐次核准的部分安全判斷，改由背景分類器承接。

這個變化顯然戳中使用者的痛點。截至 2026 年 8 月 9 日 20:19（台北時間），ClaudeDevs 官方 X 公告已累積 2,229,197 次瀏覽、14,293 個讚與 701 次轉發。大家期待的是一個能長時間工作、又不必把所有權限完全放開的 Agent；真正需要問的，則是這層「自動審查」到底能擋住什麼。

下面先忠實整理公告，再把關鍵數字逐一對回測試設計，最後判斷哪些工作適合 Auto、哪些動作仍應交給人工與硬性環境邊界。

Claude Code Auto Mode 到底改了什麼？

8 月 14 日之後，第一波只改變 Pro、Max、Team 的新 session。如果你沒有自行設定預設權限模式，新 session 會從 Auto 開始；已設定其他預設者，可能收到一次性的切換詢問；使用者或 Team 管理員已固定的預設不會被直接覆蓋。Enterprise、Claude API 與外部雲端平台目前仍採 opt-in，Anthropic 只表示計畫在接下來一個月擴大預設範圍。

模式	誰做安全判斷	最適合的工作
Manual default	唯讀以外的動作多由使用者逐次核准，仍受 allow／ask／deny 與 sandbox 規則約束	敏感變更、需要逐步看過的工作
Auto auto	權限規則先處理，其他跨邊界或高風險動作交給背景分類器	長時間 coding、測試、分支內迭代
Bypass permissions bypassPermissions	跳過一般 permission prompts 與 Auto 分類器；顯式 ask／deny、connector consent 與少數刪除 circuit breaker 仍有效	已隔離、可拋棄的 container／VM

公告為了易懂，把 Auto 描述成「每個 tool call 都交給 classifier」。不過目前技術文件列出的實際順序更精確：allow／ask／deny 規則先決定；唯讀操作與工作目錄內的一般編輯直接放行；其餘動作才送進分類器。狹義 Bash allow rule 也可能先放行，若要讓每個 shell command 都經過分類器，還要另外開啟 autoMode.classifyAllShell。

分類器拒絕後，Claude 會先嘗試較安全的替代路徑。若連續被擋 3 次，或整個 session 累積 20 次，系統才暫停 Auto、回到人工 approval。這讓它比「每一步都問」更流暢，也和完全放開權限有了實質差別。

Anthropic 為什麼敢把 Auto Mode 設為預設？

Anthropic 的核心論點不是「分類器永遠不會錯」，而是97% 的高核准率顯示，許多使用者可能已不再仔細看每個 permission prompt。截至 2026 年 6 月，公告另稱 49.5% 的活躍 CLI 使用者建立過 Bash allow rule，25% 的互動 session 更直接從 bypass permissions 開始。

這個機制方向有外部研究支持。2016 年一項結合眼動追蹤與實驗的同儕審查研究發現，使用者只需重複看到幾次安全警告，就會快速降低注意力。它不能替 Anthropic 的產品數字背書，但能解釋為何「每次都問」不等於「每次都有人認真審」。

“Auto mode blocked 89% of the same commands.”

中文：Auto Mode 對同一批命令攔下 89%。

Anthropic，〈Auto mode is now the default in Claude Code for Pro, Max, and Team plans〉

這項控制實驗招募 1,053 名付費測試者。每個 session 進行到一半時，研究者把一個 permission prompt 的文字換成明顯危險命令；人類攔下 143 次，Auto Mode 對同一批 prompts 攔下 937 次。反過來算，分類器仍放行了 116 次，也就是 11.016%。

這個 11% 很重要，但邊界也要說清楚：危險命令並未真的執行，測的是看到 prompt 後會不會放行；公告也沒有公開命令清單、獨立重現資料、受試者分層或 Auto classifier 的精確版本。因此它證明的是「在這批 prompt-swap 測試裡，Auto 明顯勝過疲勞的人類」，不是「真實世界固定有 11% 攻擊會成功」。

三組安全數據，不能混成一個漂亮的成功率

1. 受控實驗測的是：人會不會習慣性按下核准

1,053 人實驗的比較基準，是「一般使用者面對單一危險 prompt 時的反應」。它很適合回答 approval fatigue，卻沒有測量一個完整 Agent 在真實 repo、真實權限與真實攻擊鏈中造成多少損害。把 89% 寫成 Auto Mode 的通用安全率，等於把測試題目的分母換掉了。

2. 生產資料測的是：已被安全管線標記的 session

Anthropic 另分析 2026 年 5 至 6 月、使用者同意用於訓練與分析、且先被安全管線標記的 session，再用模型重評傷害程度。公告稱，在嚴重度 7 以上、又不是使用者明確要求的動作中，Manual session 有 6.3% 出現傷害，Auto session 是 2.4%。這是方向性的觀察證據，但沒有所有 session 的分母，也無法排除使用 Auto 與 Manual 的工作本來就不同。

3. 對抗測試測的是：攻擊者專門找分類器盲點時會怎樣

Apollo Research 用三組合成攻擊做紅隊測試。Anthropic 稱 hardening 後，分類器的 miss rate 從 12% 降至 7%；公告自己也強調，這批攻擊刻意比正常 Claude 行為更惡意，7% 不能當成真實流量的漏放率。這反而提醒我們：即使反覆加固，語意分類仍會有 false negative。

第三組 Prompt Injection 圖表同樣需要讀測試條件。Trajectory Labs 讓 72 個情境各跑 10 次；公告稱 Sonnet 5、Fable 5、Opus 5 搭配 Auto 時沒有一次攻擊成功，GPT‑5.6 Sol 在 Codex Auto-review 為 5.83%、Full Access 為 19.03%。但攻擊是針對未列入圖表的 Opus 4.7 最佳化，兩邊都使用第三方共同 browser wrapper，沒有測 Anthropic 或 OpenAI 第一方瀏覽器整套防護，而且 OpenAI 在測試截止後已更新 Auto-review。這張圖能支持「額外防線有價值」，不能支持「某個產品在所有 Agent 任務都絕對更安全」。

Auto Mode 不是 sandbox，也不是模型能力升級

分類器做的是語意判斷，sandbox 做的是能力邊界。 前者閱讀使用者意圖、tool call 與規則，決定動作看起來是否越界；後者透過作業系統機制限制檔案與網路，即使 Agent 或分類器判斷錯，被隔離的命令仍碰不到邊界外資源。不過 Claude Code 內建 sandbox 主要隔離 Bash 與其子程序；Read／Edit／Write 仍走 permission system，computer use 若在真實桌面上執行，也不會因此自動進入同一層 OS 隔離。官方sandbox 文件因此把它與權限控制列為互補層，而不是替代品。名稱相近的 autoMode.hard_deny 仍是交由分類器解讀的自然語言政策；若某類 tool pattern 必須在分類器前就被擋下，應使用 managed permissions.deny，並把真正不可觸及的資源留在 OS 隔離邊界之外。

安全層	它回答的問題	主要失敗方式
Permission rules	這類工具或路徑一律 allow、ask 還是 deny？	規則太寬、例外配置錯誤
Auto classifier	這個動作是否符合眼前的使用者意圖與信任邊界？	語意誤判、上下文不足、對抗繞過
Sandbox／隔離帳號	即使 Bash 或子程序被放行，實際能碰到哪些檔案、網路與雲端資源？	邊界配置過寬、隔離啟動失敗、其他工具不在同一隔離範圍
PR／人工覆核	最終輸出是否真的正確、值得進 production？	審查不足、把產出量當品質

同樣地，Claude Code Auto Mode 沒有讓主模型突然更會寫程式。它新增的是權限決策層，並減少等待人類點擊的時間。公告提到 Team 與 Enterprise 採用者約多產出 25% PR，這是 Anthropic 的使用資料；它可能代表流程不再卡住，卻沒有證明 PR 品質、合併率或商業價值同步增加。

AlphaLab 的判讀：這個預設合理，但責任不能一起外包

正確比較對象，是疲勞的人類，不是理想的人類

如果一個開發者每天面對數十次幾乎相同的核准視窗，就很容易把「確認」變成肌肉記憶。Auto Mode 的合理性，來自它把大量低資訊決策交給一個不會呈現相同人類 prompt-count fatigue 曲線、但仍可能誤判的背景分類器，再把反覆受阻的情況升級給人。這比假設每次點擊都是深思熟慮，更接近真實工作。

一次漏放的代價，取決於 blast radius

同樣是一次漏放或誤放，發生在本機暫存工作可能只帶來一次重跑；若動作能觸及 production database、雲端 IAM 或可外洩的 secrets，一次就可能決定結果。風險不是由某一個測試集「平均擋住幾成」單獨決定，而是特定情境的漏放機率 × 單次 blast radius。這也是為什麼大型 Repo 安全改版要先縮小可寫範圍與回滾單位，而不是只把規則寫得更長。

預設值改變的，是整個組織的責任分配

過去的預設把責任丟給每個使用者逐次判斷；新的預設把第一線分流交給 Anthropic 的分類器。個人使用者因此更順，組織卻更需要 managed deny、可信基礎設施清單、隔離憑證與審計紀錄。AGENTS.md／CLAUDE.md 是地圖，不是門鎖：對話中的「不要部署」可能因 context compaction 消失，真正不能越過的邊界仍應寫進不可覆寫的 deny rule。

我同意什麼，我又存疑什麼

• 我同意：逐次 prompt 已產生明顯疲勞，Auto 在 Anthropic 公布的控制實驗中大幅勝過一般人工點擊；它確實填補 Manual 與 Bypass permissions 之間的空白。
• 我存疑：最關鍵數據仍由廠商公布，公告沒有附可重現資料；11%、7% 與 0/720 分別來自不同任務與版本，尚不能推導一個穩定的真實世界失誤率。
• 我的結論：把 Auto 設為一般 coding session 的預設是合理產品決策；把它當成 production 變更的唯一保護層，則是把分類問題誤當成隔離問題。

8 月 14 日前，你應該怎麼選？

工作情境	建議起點	還要加上的邊界
本機新功能、測試、分支內 refactor	Auto	Git 分支、測試、可回滾 commit
長時間 Agent、會讀外部網頁或文件	Auto＋sandbox	網路 allowlist、Prompt Injection 掃描、獨立憑證
部署、資料庫 migration、IAM、批量刪除	Manual＋精確範圍的 permissions.ask	永不開放的 target 用 managed permissions.deny；雙人覆核、最小權限帳號
可拋棄且真正隔離的 container／VM	Auto；必要時才考慮 Bypass	無 production credentials、可重建環境

1. 先確認自己的預設。CLI 可用 Shift＋Tab 切換，Desktop 用 mode dropdown；自行固定的 default 不會在 8 月 14 日無條件被改掉。
2. 先分清楚 deny 與 ask。永不允許的 production target、force push、secrets 外送或大規模刪除 pattern，用 managed permissions.deny 在分類器前擋下；工作本身可做、但每次都須人審時，才使用精確範圍的 permissions.ask。
3. 讓 Auto 在 sandbox 裡工作。限制檔案與網路，把 production credentials 從日常 coding session 拿走；需要 fail closed 的團隊先設 sandbox.enabled: true，再設 sandbox.failIfUnavailable: true 與 sandbox.allowUnsandboxedCommands: false，避免 sandbox 無法啟動或命令失敗時退回非隔離執行。明列在 excludedCommands 的命令仍不受 sandbox 保護，清單應保持最窄。AI Agent 密鑰安全可以接著做憑證與 session log 的隔離。
4. 保留結果層覆核。要求 plan、diff、tests 與 PR，再由人決定是否進 production；若 Agent 會讀文件或網頁，搭配間接 Prompt Injection 防禦，不要把內容掃描和權限分類視為同一層。

從更大的系統角度看，Auto Mode 只是 Agent Harness 的其中一層：它管理「這一步能不能做」，Loop 負責反覆做到合格，Graph 決定下一步走向。若你正在設計長時間工作流，可再看AI Agent Harness、Loop 與 Graph Engineering 的差異，把權限、安全與任務控制分開設計。