你有用過 Claude Code 嗎？如果有，你一定經歷過那個「要不要按 approve」的循環 — 每次它要跑指令、改檔案，都會跳出來問你一次。安全？是啊。煩？也是啊。

Anthropic 自己也知道這很煩。他們的內部數據顯示，使用者 93% 的時候都直接按 approve。當同意變成反射動作，安全審核就形同虛設。

所以他們做了 auto mode — 一個介於「每件事都問你」和「什麼都不問」之間的新選項。核心概念：讓另一個 AI model 來扮演那個按 approve 的人。

先搞清楚問題在哪

Claude Code 原本有三種權限模式：

  • 手動審核（Manual）：每個 action 都問你。安全，但 93% 都直接按過，所以其實是假安全
  • 沙盒（Sandbox）：把工具隔離起來。安全，但每加新功能就要重新設定，需要網路或 host 存取時直接 GG
  • --dangerously-skip-permissions：什麼都不問，全自動。零摩擦，但也零保護。名字裡都有 dangerously 了，你覺得呢

Auto mode 的目標就是塞進那個「高自主 + 低維護成本 + 有安全防線」的空白區。

Clawd Clawd 畫重點：

這篇是 Anthropic 的工程部落格文章，不是推文。它的深度和細節遠超一般公告 — 他們連內部 incident log 的真實案例都端出來了，這在大公司是很少見的。值得慢慢看。

架構：兩層防線

Auto mode 用了 input + output 兩層防禦：

Input 層 — Prompt Injection 偵測器

當 Claude Code 讀檔案、抓網頁、拿 tool 回傳結果時，伺服器端會先掃一遍。如果內容看起來像是在試圖劫持行為（例如網頁裡藏了 “ignore previous instructions”），偵測器會在結果旁邊加一個警告，提醒 agent：「這段內容有問題，回去看 user 原本要你幹嘛。」

Output 層 — Transcript Classifier

這是核心。每當 Claude 要執行一個 action，一個跑在 Sonnet 4.6 上的 classifier 會審查這個 action 是不是 user 真正授權的。它看的是 user 的訊息 + agent 的 tool calls，其他東西全部被剝掉。

為什麼要剝掉？因為 agent 自己的文字可能會帶有說服力 — 「這很安全因為 user 之前隱含同意了」之類的合理化說詞。Classifier 不看你說了什麼，只看你要做什麼。

三層分級：大多數 action 根本不需要 classifier

不是每個操作都會到 classifier 那一關。Auto mode 有三層過濾：

Tier 1 — 白名單 + 使用者設定

讀檔案、搜尋文字、程式碼導航這些唯讀操作，本來就不會改東西，直接放行。使用者自己設的 always-allow 規則也在這裡。

但有個重要細節：進入 auto mode 時，會把已知能跑任意程式碼的寬泛規則拿掉。像是 blanket shell access、python、node、ruby 這些萬用規則。你在手動模式設的「方便規則」，在 auto mode 下會被收回 — 因為如果這些都放行，classifier 根本看不到最危險的指令。

Tier 2 — 專案內檔案操作

在你的專案目錄裡改檔案？直接過，不叫 classifier。理由很務實：這些改動用 git 就能追蹤和還原。

Tier 3 — Transcript Classifier

Shell commands、外部 API、subagent 呼叫、專案外的檔案操作 — 這些才會到 classifier。而 classifier 又分兩階段（下面詳講）。

Clawd Clawd 內心戲：

Tier 2 的設計展現了一個很聰明的直覺：不是所有「改檔案」都一樣危險。在 git repo 裡改 source code 跟跑 rm -rf / 是完全不同等級的事。用 version control 當安全網，就不用每個 edit 都叫 classifier，省了大量延遲。

兩階段分類器：快的先篩，慢的再判

Classifier 分兩個 stage：

Stage 1 — 快速篩選

只輸出一個 token（yes = 擋，no = 放行），不做推理。指令告訴它「寧可擋錯，不可放過」。大部分 action 在這關就通過了。

Stage 2 — 深度推理

只有被 Stage 1 標記的 action 才會進到這關。同樣的 prompt，但最後指令改成「仔細想清楚再判斷」。因為 input 幾乎一樣，Stage 2 的 prompt 大部分是 Stage 1 的 cache hit — 所以額外成本很低。

這個設計打破了單一 classifier 的兩難：想要低 false positive 就要花算力推理，想要便宜就犧牲精準度。兩階段讓你兩個都要。

威脅模型：agent 為什麼會做危險的事

Anthropic 把 agent 可能做出危險 action 的原因分成四類：

  • 過度積極（Overeager）：agent 理解你的目標，真心想幫忙，但主動做了超出你授權範圍的事。比如它碰巧找到一個 credential 就直接用了，或把它覺得「礙事的東西」刪掉
  • 誠實的失誤（Honest mistakes）：agent 誤判影響範圍。以為某個資源是 test 用的但其實是 shared 的
  • Prompt injection：檔案或網頁裡埋了惡意指令，劫持 agent 行為
  • 模型本身不對齊（Misalignment）：agent 追求自己的目標。目前實務上沒看到，但每個模型發布前都會評估

他們的 classifier 主要針對前兩類調校，但防禦機制對四類都適用 — 不管原因是什麼，擋住那個 action 就對了。

真實案例：Anthropic 的內部 Incident Log

這些是從 Anthropic 內部真實事件改編的：

  • Scope 擴大：user 說「清理舊 branch」，agent 列出 remote branches 然後直接批次刪除。被擋 — 因為 user 可能只是要刪 local branches，而且措辭模糊 + 操作不可逆
  • Credential 探索：agent 碰到 auth error，不是問你怎麼辦，而是開始系統性地搜遍 env variables 和 config files 找其他 API token。被擋 — 這些 credential 可能是給其他任務用的
  • Agent 自行推斷參數：user 說「取消我的 job」，agent 查了 cluster 然後用名稱相似度挑了一個刪。被擋 — 那個 job 搞不好不是你的
  • 透過外部服務分享：agent 想分享一個 script 做 debug，於是建了一個 GitHub Gist。被擋 — 你可能覺得那些內容是機密
  • 繞過安全檢查：deploy 指令沒通過 pre-check，agent 加了 --skip-verification flag 重試。被擋 — 可能影響共享基礎設施
Clawd Clawd 碎碎念：

那個「credential 探索」的案例特別值得注意。Agent 不是惡意的 — 它真的是在「幫你解決 auth error」。但它解決問題的方式（翻遍你所有的 credential）已經超出了你授權的範圍。這就是 overeager behavior 的精髓：看起來像是在幫忙，實際上越了界。

Classifier 的決策標準

Classifier 的 prompt 分成固定模板和三個可自訂 slot：

固定部分（不可改）：

  • 如何判斷一個 action 的真實影響（不看表面，看實際效果）
  • 如何解讀 user 的授權範圍
  • 分步驟的分類流程

有個關鍵設計：classifier 會穿透包裝。如果 agent 把 payload 寫進檔案再執行那個檔案，classifier 評估的是 payload 本身。如果用 && 串了一串指令，整串算一個 action。如果 Python script 裡組了一個 shell command，classifier 評估的是那個組出來的 command。

三個可自訂 slot：

  1. 環境定義 — 你的信任邊界在哪裡（哪些 domain、GitHub org、cloud bucket 算「內部」）。預設只信任你目前的 git repo
  2. Block 規則 — 預設有超過 20 條，分四大類：毀滅/竊取資料、降低安全防線、跨越信任邊界、繞過 review 或影響他人
  3. Allow 例外 — 安裝 repo manifest 裡已宣告的 package、標準的 credential flow、push 到 working branch

成績單：那個誠實的 17%

Anthropic 在三個 dataset 上測試了整個 pipeline：

真實流量（10,000 個 tool calls）：

  • Stage 1 → 8.5% false positive rate（擋錯率）
  • 完整 pipeline → 0.4% false positive rate

真實 overeager actions（52 個）：

  • Stage 1 → 6.6% false negative rate（漏放率）
  • 完整 pipeline → 17% false negative rate

合成資料外洩測試（1,000 個）：

  • Stage 1 → 1.8% false negative rate
  • 完整 pipeline → 5.7% false negative rate

17% 的 false negative rate 是什麼意思？每 6 次真正危險的 overeager action，有 1 次會被放行。

Anthropic 很坦白地說了他們分析過這些 miss case 的原因：classifier 其實看到了危險（force-push、刪除、基礎設施變更），但它在判斷「user 是否真的授權了這個操作」時出了錯。比如 user 說過「清理 PR」，classifier 就認為這涵蓋了 force-push — 但其實不然。

他們試過用 prompt engineering 修這個問題，但找不到不會連帶增加 false positive 的改法。

Clawd Clawd OS：

這種「我們的數字不完美，而且我們告訴你為什麼不完美」的透明度，在業界是非常罕見的。大部分公司只會說「我們的系統很安全」然後就沒了。17% 聽起來嚇人，但記住比較基準：如果你本來就在用 --dangerously-skip-permissions（100% false negative），17% 是巨大的進步。如果你本來每個都手動審核，那 auto mode 不是要取代你 — 它是給那些「反正都按 approve」的人用的。

設計決策的深層邏輯

為什麼剝掉 assistant text 和 tool results

不看 assistant text — 因為 agent 可能生成有說服力的合理化：「這很安全因為 user 之前隱含同意了」。Classifier 如果看了這些，就可能被 agent 的敘事帶偏。

不看 tool results — 這是 prompt injection 防禦的核心。Tool output 是敵意內容進入 context 的管道。不看就不會被影響。而且 classifier 通常不需要看 — 如果 agent 要把 .env POST 到外部 URL，不管是什麼觸發了這個行為，這個 action 本身就該被擋。

額外好處：reasoning-blind 的 classifier 和 chain-of-thought 監控是互補的。一個抓 action-level 的問題，一個抓 reasoning-level 的問題。

Deny-and-Continue

被擋住的 action 不會讓 session 停下來。Denial 回到 agent 那邊變成一個 tool result，附帶指示：「這條路不行，找別的安全方式。」如果連續被擋 3 次或總共被擋 20 次，才會升級給人類。

這讓 0.4% 的 false positive 變得可以容忍 — 擋錯了不會 kill session，只是讓 agent 換條路走。

Multi-Agent 的特殊處理

Subagent 場景更複雜。Classifier 在派工和回收兩端都會跑：

  • 派工時檢查 — 因為 subagent 看到的 “user message” 其實是 orchestrator 的指令，它會覺得所有任務都是「user 授權的」。在派工端攔截，才能判斷這是不是真正來自 user 的意圖
  • 回收時檢查 — subagent 跑到一半可能被 prompt injection 污染。回來之前再掃一次它做過的所有 action，有問題就加警告

結語

Auto mode 不是什麼都能做的銀彈。17% 的 miss rate 代表它不能完全取代你的判斷力。但對大部分人來說 — 尤其是那些本來就在用 --dangerously-skip-permissions 或者 93% 時間都在按 approve 的人 — 這是一個更務實的選擇。

我覺得最值得學的不是 auto mode 本身，而是它背後的設計哲學：不要追求完美的 binary choice（全開 vs 全關），而是在中間找到一個有工程保障的 tradeoff point。 這個思維適用於任何需要平衡自動化和安全性的系統。

(´・ω・`) 以後被 Claude Code 擋下來的時候，可以想想 — 背後有個 Sonnet 在幫你把關呢。