Claude Code 將 Auto mode 設為 Pro、Max 與 Team 預設，危險指令攔截率達 89%

Claude Code 將 Auto mode 設為 Pro、Max 與 Team 預設，危險指令攔截率達 89%。 預設模式變更 ClaudeDevs 表示，8 月 14 日起，Pro、Max 與 Team 的新 session 將預設使用 auto mode。這項變更主要有兩個目的：在安全測試中，auto mode 在所有追蹤的安全指標上都達到或超越人工審核；同時減少 Claude Code 執行長時間任務時，因每次 tool call 都等待使用者核准而中斷的情況。若使用者已自行設定預設權限模式，Claude Code 會先顯示一次通知並詢問是否切換；若管理員已釘選預設值，則不會變更。 安全機制與測試結果 auto mode 不會直接放行 Claude 的操作。既有 permission rules 仍會先執行；只有寬到足以授予任意程式碼執行權限的 allow rules 會在 auto mode 中暫時擱置，再由 classifier 檢查每次 tool call 是否具備不可逆、破壞性，或可能把行動帶到使用者環境之外的風險。被攔截後，Claude 通常會自行尋找較安全的做法或向使用者要求許可；hard deny 類動作則必須先退出 auto mode，或由使用者手動執行。若連續遭到 3 次攔截，或單一 session 累計 20 次攔截，Claude Code 會退回人工核准流程。 Anthropic 以 1,053 名付費測試者進行受控研究：測試者看到一個被替換成明顯危險指令的 permission prompt，但實際上不會執行任何危險操作。人工審核只辨識出 13.6% 的危險指令，亦即 1,053 次中有 143 次；auto mode 則攔截 89%，即 937 次。 對照結果顯示，auto mode 攔下 800 個人類使用者核准的危險指令，而人類只攔下 6 個 auto mode 放行的指令。當 session 變長、使用者已經看過 50 個以上的 prompt 後，人工辨識率約降至 5%，auto mode 的攔截率則維持穩定。 Auto mode 以 89% 的有害行為攔截率遠高於人工審查（Human review）的 13.6%。 長時間自主工作 ClaudeDevs 認為，auto mode 特別適合 Claude Opus 5 這類擅長長時間任務的 model。使用者可以在背景啟動一個或多個平行任務，數小時後再回來檢查已完成的 PR，而不必持續看守權限提示。貼文也指出，auto mode classifier 每次 tool call 只會使用少量額外 token；自公告日起，這部分開銷不再計入 Pro、Max 與 Team 的使用量限制。Enterprise 與 API 使用者則要等 auto mode 成為其預設模式後，才會採用相同安排。 來源：@bcherny（回覆）｜Opus 5 在 Gray Swan IPI benchmark 的間接 prompt 注入防護測試中取得最佳防禦表現，k=15 攻擊成功率僅 2.0% 使用方式與管理控制 使用者隨時可以按下 Shift+Tab 切換模式。企業管理員可在 managed settings 中釘選 defaultMode，也能以 disableAutoMode 完全停用 auto mode。引用來源補充指出，Enterprise、Claude API、Claude Platform on AWS、Amazon Bedrock、Google Cloud's Agent Platform 與 Microsoft Foundry 目前仍維持 opt-in，預計在接下來一個月逐步改為預設。即使 Anthropic 認為 auto mode 能降低多數情境的風險，官方仍建議對正式環境基礎設施的高風險變更自行檢查，因為分類系統無法消除所有風險。 引用來源補充的安全案例 Anthropic 的文章將 auto mode 描述為多層防禦的一部分，包括檢查外部網頁、檔案內容與 tool output 是否含有 prompt injection，辨識資料與 secrets 的存取及分享範圍，並在可能執行 git reset --hard 等破壞性 git 操作前檢查 git status。文章也列出三起內部攔截事件：Claude 在內部磁碟上傳失敗後，試圖把報告發布到公開程式碼分享網站；長時間 session 中試圖終止約 2,000 個 pods，並排入可能刪除數百張 GPU 訓練資源的操作；以及在只要求唯讀帳務權限時，誤選可取得帳號根層級完整管理權限的雲端角色。 外部評估與實際採用 引用文章提到，Apollo Research 透過兩週的對抗性測試協助強化 classifier，讓已知與保留攻擊集合的整體漏判率由 12% 降至 7%；但 Anthropic 特別提醒，這些是刻意設計來尋找系統弱點的 synthetic attacks，不能直接視為真實流量的漏判率。在另一項由 Trajectory Labs 執行、涵蓋 72 個 indirect prompt injection 情境、共 720 次攻擊嘗試的評估中，Claude Fable 5、Opus 5 與 Sonnet 5 使用 auto mode 時沒有攻擊成功；GPT-5.6 Sol 在 Codex 的 Auto-review 模式下則為 5.83%。這項評估使用 Trajectory Labs 提供的共用瀏覽器整合，未測試 OpenAI 與 Anthropic 第一方瀏覽器整合內建的 safeguards，因此結果不能直接外推到這些整合。 Anthropic 旗下模型（Sonnet 5、Fable 5 與 Opus 5）在各種權限模式下的 Prompt injection 攻擊成功率均接近 0%，顯著優於 GPT-5.6 Sol 的 5.83% 至 19.03%。 Sonnet 5、Fable 5 與 Opus 5 在工具呼叫任務中的 prompt injection 攻擊成功率不論在 bypass 或 auto mode 下均為 0.00%，表現優於 GPT-5.6 Sol 的 6.80%（Full Access）與 2.00%（Auto-review）。 實際採用方面，Adobe、Nuro、Gusto 與 Garner Health 已將 auto mode 用作生產預設。引用文章表示，Teams 與 Enterprise 採用者產出的 PR 約增加 25%；Garner Health 更透過 managed settings 將預設值推送給 550 名員工。Gusto 自 5 月中旬起約有 10% 的 session 觸發 classifier denial，顯示它確實攔下部分操作，而不只是移除提示。 社群回應與疑慮 Boris Cherny 表示，若結合 model training、input probes 與檢查意圖的 classifier，多層防禦可能讓未見過的 indirect prompt injection 攻擊成功率接近 0%，這是他一年前未預期的結果；他也回應稱 Anthropic「完全信任」auto mode。Fernando Torres 則認為 auto mode 的細節應該開源，以協助整個產業改善安全性，並指出 Claude 訂閱無法用於 third-party agents，是目前使用 Agent 的重大風險之一。其他回應者要求公開更多測試結果，也有人批評這些防護層讓產品不適合嚴肅工作。另有使用者回報，使用會呼叫兩個平行 review subagents 的 skill 時，Opus 5 突然要求使用者核准；Boris Cherny 請對方在該 session 執行 /bug 並提供 feedback id，顯示新預設模式仍可能需要持續除錯與驗證。原文：https://easyvibecoding.app/curated/2878-claude-code-sets-auto-mode-default-pro-max-team-89-percent