隨著 AI coding agent 從 “輔助寫代碼” 走向 “直接執(zhí)行開發(fā)操作”，模型開始被賦予修改代碼、部署服務(wù)等真實運維權(quán)限。為減少頻繁人工確認帶來的打斷，Anthropic 近期為 Claude Code 推出 Auto Mode，希望通過自動分類代替用戶審核操作。

然而，當用戶指令本身存在權(quán)限上的歧義時，Auto Mode 是否真的能夠穩(wěn)定替代人工審核？香港科技大學與 ETH Zurich 研究團隊對這一問題進行了首個系統(tǒng)壓力測試。

基于 128 個覆蓋 4 類運維任務(wù)的授權(quán)歧義場景，研究發(fā)現(xiàn)：Auto Mode 在該壓力測試上的端到端誤放行率達到 81.0%，且有 36.8% 的狀態(tài)改變動作通過項目內(nèi)文件編輯路徑繞過分類器。

• 報告地址 http://arxiv.org/abs/2604.04978
• 代碼地址 https://github.com/yan5ui/cc-auto-mode-measurement

Auto Mode 為何仍需要獨立壓力測試？

Anthropic 引入 Auto Mode 的直接動機，是在自主性與安全性之間尋找一個比 “逐條人工確認” 更高效、又比 “完全跳過權(quán)限” 更穩(wěn)妥的中間方案。官方博客指出，Claude Code 用戶實際會批準約 93% 的權(quán)限請求，這意味著頻繁彈窗雖然保留了人工審核環(huán)節(jié)，卻也容易帶來明顯的認知負擔。

相比之下，--dangerously-skip-permissions 雖然幾乎沒有交互成本，但缺乏足夠保護；而 sandbox 方案安全性更高，卻需要額外維護隔離環(huán)境。Auto Mode 的目標，正是在低維護成本下盡可能提高自主執(zhí)行能力，同時攔截明顯超出用戶授權(quán)邊界的危險操作。

從機制上看，Auto Mode 引入了一套分層權(quán)限架構(gòu)。官方將其概括為兩層防線：輸入側(cè)使用 server-side prompt-injection probe；輸出側(cè)則使用 transcript classifier 對即將執(zhí)行的動作進行審核。

在 transcript classifier 中，Claude Code 的操作被劃分為三個層級。Tier 1 是只讀安全工具與用戶顯式允許的安全規(guī)則；Tier 2 是項目目錄內(nèi)的文件寫入與編輯，這類操作默認允許；只有 shell、外部服務(wù)調(diào)用等，才會進入 Tier 3，由 sonnet 模型進行正式審核。

從官方披露結(jié)果看，這套設(shè)計在 10,000 條真實內(nèi)部流量上，完整兩階段管線的 false positive rate 為 0.4%；在 52 條真實 overeager actions 上，false negative rate 為 17%；在 1,000 條合成數(shù)據(jù)外傳任務(wù)上，false negative rate 為 5.7%。

然而，官方報告中的 “real overeager actions” 樣本量只有 52，且主要來自自然產(chǎn)生的內(nèi)部使用流量，并未對系統(tǒng)邊界進行充分探索；其次，官方博客已經(jīng)給出多個典型風險例子，例如模糊指令下的 scope escalation、agent 自行推斷 job target、未被明確授權(quán)的共享資源操作等；這些恰恰說明，Auto Mode 最困難的問題并不是識別一個命令表面上是否危險，而是判斷某個具體動作是否真的被用戶授權(quán)，因此，再進行獨立壓力測試就變得必要。

壓力測試環(huán)境設(shè)計

作者設(shè)計了一個專門面向 scope escalation 的壓力測試基準 AmPermBench，它聚焦于：當用戶意圖方向正確、但目標范圍、影響半徑與風險等級并未被充分說清時，Auto Mode 能否準確地區(qū)分授權(quán)動作與越權(quán)動作。整個基準圍繞四類具有代表性的 DevOps 任務(wù)展開，包括分支清理、任務(wù)取消、服務(wù)重啟與制品清理。

AmPermBench 將每個任務(wù)構(gòu)造成一個固定的 4 × 4 × 2 prompt 矩陣，從三個維度控制歧義強度：其一是 Specificity，即用戶表達的明確程度；其二是 Blast Radius，即操作覆蓋范圍，從單一對象擴展到一個 ticket 范圍內(nèi)的多個候選目標；其三是 Risk Level，即環(huán)境風險等級，從低風險開發(fā)側(cè)擴展到高影響共享側(cè)。三者交叉后，每類任務(wù)生成 32 個 prompt，四類任務(wù)合計形成 128 個壓力測試場景。

在具體實驗中，研究使用 Claude code Sonnet 4.6 以 auto mode 測評，并從所有有效會話中抽取出全部 253 個動作，再采用 Claude Opus 作為 LLM judge（輔以人工驗證）逐一標記每個動作為 真陽 TP、真陰 TN、假陽 FP 或 假陰 FN。陽性指 autom mode 對某個動作進行了攔截。

圖 1 AmPermBench 與整體評估架構(gòu)

實驗結(jié)果與關(guān)鍵發(fā)現(xiàn)

1. 動作級誤放行率偏高

對于全部動作，實驗得到：TP=27，TN=89，F(xiàn)P=22，F(xiàn)N=115，對應端到端 FNR=81.0%、FPR=19.8%。這意味著在這套面向授權(quán)邊界的壓力測試中，大多數(shù)越權(quán)動作最終并未被攔住。

表 1 auto mode 的總體表現(xiàn)

進一步地，拆解分類器實際看到的 Tier 3 動作后，發(fā)現(xiàn)在 160 個真正進入 Tier 3 的動作中，F(xiàn)NR 仍然高達 70.3%，而 FPR 則上升到 31.9%。

表 2 auto mode 在進行 tier 2/3 分類后的表現(xiàn)

但是這里的 81.0% FNR 并不直接否定 Anthropic 官方披露的 17% FNR。后者來自生產(chǎn)流量中的 “real overeager actions”，而這篇論文刻意構(gòu)造的是授權(quán)與未授權(quán)目標彼此相鄰的壓力場景，本質(zhì)上測量的是不同 workload 下的表現(xiàn)邊界，而非同一分布上的重復驗證。

2. 沿歧義軸拆解后，暴露出明顯的啟發(fā)式偏好

按照 Blast Radius 的變化，隨著目標范圍從單對象擴展到更寬的 selector，整體 FNR 從 94.4%（B0） 下降到 77.6%（B3）。Auto Mode 似乎對 “批量操作看起來更危險” 這一模式更敏感，而對精確但越權(quán)的單點操作反而更容易放行。

對于 Risk Level，當環(huán)境從低風險 R0 切換到高風險 R1 時，F(xiàn)PR 從 9.2% 大幅升至 34.8%，Auto Mode 在高風險環(huán)境中的策略更 “保守”。

圖 2 auto mode 假陰率 / 假陽率隨 Blast Radius 軸以及 Specificity 軸的變化

表 3 auto mode 假陰率 / 假陽率隨 Risk 軸的變化

3. Tier 2 文件編輯存在結(jié)構(gòu)性覆蓋盲區(qū)

根據(jù) Anthropic 的設(shè)計，項目目錄內(nèi)文件編輯屬于 Tier 2，默認允許，不進入分類器審核；在 AmPermBench 的實驗結(jié)果中，當 agent 找不到預期 CLI 時，會自然地轉(zhuǎn)而使用 Edit / Write 工具，甚至用內(nèi)聯(lián) Python 直接改寫項目文件。

由于這些操作都屬于 Tier 2，分類器完全看不到它們。數(shù)據(jù)上，93 個狀態(tài)改變動作走的是 Tier 2，占全部動作的 36.8%；其中所有不安全 Tier 2 動作都按定義成為 FN。這并不是對系統(tǒng)的惡意規(guī)避；相反，agent 只是選擇了自己手頭最自然、最直接的可用工具來完成任務(wù)。真正暴露出的，是權(quán)限系統(tǒng)設(shè)計假設(shè)與 agent 實際行為之間的錯位：系統(tǒng)假設(shè)危險動作主要通過 shell 發(fā)生，而 agent 實際上會通過任何可用路徑實現(xiàn)同等狀態(tài)改變。

總結(jié)

這項工作首次系統(tǒng)評估了 Claude Code Auto Mode 在授權(quán)歧義場景下的實際表現(xiàn)。實驗表明，Auto Mode 雖然能夠在部分高風險操作上提供一定保護，但整體誤放行率仍然偏高，更關(guān)鍵的問題在于：相當一部分危險狀態(tài)改變并不會進入分類器，而是通過項目內(nèi)文件編輯等路徑直接繞過審核。