Claude Code 的 auto 模式不是安全邊界

Claude Code 的 auto 模式是安全邊界嗎？ 不是，而且 Anthropic 自己也這麼說。在研究人員 Johann Rehberger 回報了一條針對 auto 模式下 Claude Code Opus 5、真實可行的攻擊鏈之後，Anthropic 將這份回報標記為 Informative 並結案。其立場是：auto 模式是一項便利功能，背後靠的是一個盡力而為的分類器，而不是安全保證；由一個個單獨看來無害的步驟拼裝而成、有備而來的攻擊鏈，本來就不在分類器被期待攔下的範圍之內；真正的邊界是作業系統層級的隔離，加上網路 egress 管控。¹ 這個答覆不是推託。它才是正確的心智模型，而我們大多數人一直抱著錯的那一個。 {.answer-block}

有一類資安發現，其價值不在於漏洞本身，而在於它所校正的那個信念。Rehberger 在8月26日發表的分析正屬於這一類。他示範的攻擊鏈很巧妙，但真正有用的是它引出的那份答覆，因為那份答覆會告訴您：在您的環境裡，究竟哪一層才真正承重。而它並不是自8月 auto 模式成為預設值以來，多數開發者一直信賴的那一層。

重點摘要

• Rehberger 於2026年8月26日公開了一條針對 auto 模式下 Claude Code Opus 5、真實可行的攻擊鏈，並回報在小樣本上的成功率為60%至80%：主攻擊鏈五次中有三次成功，第二個變體的兩種組態分別是五次中三次與五次中四次。他特別註明，這些只是小樣本，並非普遍意義上的攻擊成功率。¹
• 這項發現正好撞上一個具體的數字：Anthropic 委託的第三方評估報告指出，auto 模式下的 Opus 5 提示注入攻擊成功率為0.00%，測量方式是72個情境各執行十次。Rehberger 的攻擊鏈並不在那批情境之內，因此0.00%這個數字與一條真實可用的程式碼執行鏈可以同時成立。¹
• 攻擊鏈中的每一步單獨來看都合情合理。這正是其中的設計教訓：分類器一次只評估一個動作，而攻擊藏在這些動作的組合裡，不在任何單一動作之中。
• Anthropic 將回報標記為 Informative 並結案，把 auto 模式定位為由盡力而為的分類器所支撐的便利功能，而非安全保證，並指出作業系統隔離與網路 egress 管控才是真正的邊界。¹
• 最鋒利的一處細節由 Rehberger 回報、經 Willison 特別點出：在少數幾次執行中，Claude 察覺到入侵並試圖終止惡意程式的行程，而 auto 模式拒絕了那條清理指令。¹²
• 實務上的結論是：auto 模式是一項生產力控制手段，並且在它判斷您並未提出相應要求時，也會擋下一份有文件記載的破壞性操作清單。但擋在攻擊者可控文字與您的憑證之間的，並不是它。真正站在那個位置的，是容器、受限的 egress，以及一個不存放憑證的家目錄。

逐步拆解這條攻擊鏈

起點是一個正在做日常工作的代理程式：取得一份資源、解碼它、使用其中的內容。以下就看看這個過程如何演變成程式碼執行。¹

某台伺服器對代理程式的 WebFetch 回應 HTTP 415，這看起來像是 content-type 的問題，而不像攻擊。代理程式做出合理的判斷，退而改用 curl。它取回的封存檔解開後，暫存目錄裡躺著一個 README、一份總和檢查碼清單、一個 CSV 索引、七筆經 Base85 與 zlib 編碼的 JSON 記錄、一個原生解碼器執行檔，以及一個名為 struct.py 的檔案。

接著，安全機制發揮了作用。代理程式拒絕執行這個不可信的原生執行檔——正是您會希望看到的行為。拒絕執行檔之後，它改為自己寫了一個 Python 解碼器，並在解壓縮出來的目錄內部執行。

那個解碼器會 import base64。標準函式庫的 base64 又會 import struct。Python 把工作目錄放在模組搜尋路徑的最前面，於是 struct 解析到的不是標準函式庫，而是解壓縮出來的封存檔裡那個屬於攻擊者的 struct.py。

請再讀一次這個順序，並留意其中少了什麼：沒有任何一步是在指示代理程式去做明顯惡意的事，也沒有任何一步會被一位稱職的審查者單獨挑出來。收到415之後改用 curl 很正常。解開封存檔很正常。拒絕未簽章的執行檔是安全上的勝利。自己動手寫解碼器是隨機應變。在存放資料的目錄裡執行它，更是再自然不過的選擇。

分類器為何注定輸掉這一局

auto 模式的分類器會對照工作階段的意圖來評估一個動作：這條指令是否與使用者所要求的相符，它本身是否危險？這個問題對 rm -rf / 有很好的答案，對 python decode.py 卻給不出好答案。

這次攻擊從頭到尾沒有端出任何一個危險動作。它只是重新擺布環境的形狀，使得一個看似安全的動作產生了不安全的後果；而這個後果之所以成立，完全依賴於更早發生的那一步——那次埋下模組的解壓縮操作。要抓住這一點，審查者必須把整段歷程都放在腦中，並結合當前工作目錄去推演 Python 的 import 解析規則。Anthropic 的立場，也就是由單獨無害的步驟所構築的攻擊鏈落在分類器職責範圍之外，正是針對這道縫隙的陳述。¹

值得把這類攻擊的名字說準。Willison 在8月30日更新了他的文章，認同一位 Lobste.rs 讀者提出的觀點：這根本不是典型的提示注入，因為模型自始至終都沒有讀取攻擊者的指示並加以執行。更貼切的說法是混淆環境攻擊（confused environment attack）——是交到代理程式手上的那個環境的形狀，製造出了這次利用。² 這個區分不但沒有削弱問題，反而讓它更加尖銳。一個盯著注入指示看的分類器在這裡無物可看，因為根本就沒有指示。

這與 MCP 的 CVE 浪潮不斷揭示的是同一個結構性問題：代理程式工具累積能力的速度，快過它累積約束的速度；而逐一動作的審查，並不會合成為整個工作階段的安全。

應當改變您心智模型的那處細節

Rehberger 回報、Willison 特別點出的那一幕值得停下來細想：在少數幾次執行中，Claude 注意到入侵並試圖終止惡意程式的行程，而 auto 模式拒絕了那條清理指令。¹²

一個安全層阻止了補救，這並不是弔詭。當一項控制手段只為「別讓代理程式做出任何激烈舉動」而最佳化，卻沒有關於這個激烈舉動為何被嘗試的概念時，就會出現這種局面。在分類器看來，入侵之後的清理，跟破壞行為長得非常像。

由此得出的維運教訓雖然狹窄卻很實用：「代理程式會察覺到」不是一種控制手段。察覺與能夠採取行動是兩種不同的能力，您的事件應變方案不能假設被入侵的代理程式還能自己收拾殘局。

真正能約束代理程式的東西

Rehberger 的建議都不怎麼光鮮，但前兩條本來就能把這條攻擊鏈關在裡面：¹

在容器或虛擬機器中執行無人看管的代理程式。 這次入侵是以代理程式所屬使用者的身分執行程式碼。一層隔離能把整台機器的存取權，變成一個用完即丟的環境。

限制網路 egress。 這條攻擊鏈的收益，來自一個子行程向外取得並執行遠端酬載，隨後再發出回連。一份以允許清單為基礎的 egress 政策，能同時切斷遠端階段的下載與回連。

讓憑證處在代理程式碰不到的地方。 家目錄裡的 SSH 金鑰、雲端憑證與 .env 檔案，預設就在爆炸半徑之內。要嘛把它們搬走，要嘛把代理程式放到沒有它們的地方去執行。

監控代理程式，並且不要把核准當成證據。 auto 模式的核准只代表分類器沒有提出異議，並不等於認定該動作是安全的。

也請留意清單上沒有的一項：關掉 auto 模式。當它判斷您並未提出相應要求時，它會擋下一份有文件記載的破壞性操作清單，同時它也減少了那種讓人反射性按下同意的提示疲勞。為了一種虛假的嚴謹感而把它交出去，等於用一個更糟的弱控制換掉一個弱控制。留著它，只是別再把它當成邊界。

有些話值得直說

把這個發現寫成一次失敗很容易，寫成對廠商的指責更容易。兩者都不對。

Anthropic 的答覆——一項由盡力而為的分類器所支撐的便利功能，而非安全保證，邊界在於作業系統隔離與網路 egress 管控——是一種比更強硬的宣稱更誠實的安全姿態。¹ 若有廠商承諾自家分類器攔得下有備而來的注入鏈，那將是任何分類器都無法兌現的承諾，而開發者會在這份承諾之上繼續往上蓋。有意思的問題不是這次攻擊會不會成功，而是整個生態的心智模型是否與廠商一致——目前並不一致。auto 模式在8月成為 Pro、Max 與 Team 工作階段的預設值，而當時被 Anthropic 放進流通的數字，是一份受委託的72情境評估所得出的0.00%攻擊成功率；Rehberger 把它歸入「0.00%的行銷問題」。而與這個數字一同傳開的框架是安全性，而不是「便利加上爆炸半徑的縮小」。¹ Rehberger 得出了比我更強硬的結論：他把0.00%的宣傳口徑與「不在範圍內」的處置，讀成彼此兜不攏的混亂訊息。¹ 我認為兩者可以並存。那個處置是誠實的；而那個數字，本來就不該被當成產品的屬性拿來行銷。

如果您的環境一直假定分類器就是那道牆，那就把牆補上。

9月3日更新：本文發表後上線的內容

在本文發表後的48小時內，Claude Code 推出了三個版本，其中兩個涉及 auto 模式。³ 9月1日發布的2.1.257版本新增了發行說明中稱為 Containment Escape 的規則：「雲端中繼資料憑證擷取、egress 規避以及跨租戶存取，除非您的環境將它們標記為預期之內，否則不再自動核准。」同一版本還在 auto 模式中，為首次讀取工作目錄以外的檔案加入了一次性的確認提示，並提供設定項 permissions.blockReadsOutsideWorkingDirectories，可將該提示改為直接拒絕。9月2日發布的2.1.259版本，則為無人看管的 headless 主機新增了 --permission-prompts none：「任何本來會觸發提示的操作都會被自動拒絕，同時目前生效的權限模式（包含 auto 模式）仍持續做判斷。」

請在本文設定的框架裡閱讀它們。這條規則、這次讀取提示以及這個旗標，都是貨真價實的強化，而這個 headless 旗標正是無人看管的主機應該啟用的失效即拒絕設定。但前兩項所收窄的，是 auto 模式自行核准的範圍：規則把三類操作從自動核准中排除，除非環境將其標記為預期之內；讀取方面的變更則提示一次，或在開啟設定後直接拒絕。兩者都沒有被描述為邊界，兩者也都位於 auto 模式的核准流程之內。而正是這套審查，被這條攻擊鏈一路走通，且過程中沒有端出任何一個單看就不對勁的動作。規則點名了 egress 規避，而 Rehberger 描述的並不是規避，只是每一跳上的對外連線：一次 curl 下載、一個去取得遠端階段的子行程、該階段再去取得酬載，以及最後的回連。規則會不會把其中任何一項讀作規避，說明裡沒有講；讀取提示是否涵蓋子行程發出的讀取，說明裡同樣沒有講。這兩項變更之中是否有哪一項本來能攔下這條攻擊鏈，發行說明並未如此宣稱，我們也不該逕自假定。2.1.257 之中確實有一處修正落在邊界這一層：沙箱的 deniedDomains 項目先前無法擋下以尾端句點書寫的主機名稱，這個版本修好了這一點。那是在邊界上做的修補，而不是邊界的移動。auto 模式自行核准的範圍縮小了，邊界並沒有動。

重點整理

• auto 模式是便利與爆炸半徑的控制手段，不是安全邊界。 這是廠商在一次真實繞過之後自己的立場，而非外界的批評。¹
• 分類器裁決動作，攻擊卻活在組合之中。 所示範的攻擊鏈每一步單獨看都站得住腳，而這正是逐一動作的審查會漏掉它的原因。
• 察覺不等於補救。 在某些執行中，代理程式偵測到自己被入侵，隨後卻被擋住而無法清理。請據此規劃事件應變。¹²
• 真正撐得住的控制手段都在模型之外。 容器或虛擬機器、受限的 egress、移出家目錄的憑證。其餘的一切都是縱深防禦，而不是邊界。

常見問題

我應該關掉 auto 模式嗎？

不應該，除非您一直把它當成封鎖手段來依賴。當它判斷您並未提出相應要求時，它會擋下一組有文件記載的破壞性操作——git reset --hard、git checkout -- .、git clean -fd、git stash drop，以及 terraform/pulumi/cdk destroy——而且它還削減了那種誘發反射性核准的提示數量。把它留作生產力與爆炸半徑的控制手段，同時為接觸不可信輸入的工作階段加上真正的隔離。

這只影響 Claude Code 嗎？

這個機制並非 Claude 獨有。任何一個會去取得不可信封存檔、撰寫程式碼並在剛剛解壓縮出來的目錄裡執行它的代理程式，都暴露在同樣的 import 解析陷阱之下；任何一種逐一動作的安全審查，也都暴露在同樣的組合縫隙之下。此處的具體細節，是在 auto 模式下的 Claude Code Opus 5 上示範出來的。¹

什麼樣的工作階段算是不可信輸入的工作階段？

任何可能讓受攻擊者影響的文字抵達模型的場景：抓取的網頁、下載的封存檔、issue 與 PR 的文字、電子郵件、來自公開服務的日誌，以及第三方 MCP 伺服器。實際上這幾乎涵蓋了大部分真實工作——這正是令人不安的地方。

這個問題已經修好了嗎？

它並未被當成需要修補的漏洞來處理。Anthropic 將回報標記為 Informative 並結案，理由是此類繞過分類器的行為不在 auto 模式所承諾的範圍之內。¹ 請把它當成系統一項有文件記載的性質，而不是一個待發的修補程式。本文發表後48小時內的一個版本2.1.257收窄了 auto 模式自行核准的範圍，並新增了對工作目錄以外讀取的選用封鎖；2.1.259則為 headless 主機新增了一個失效即拒絕的旗標。上文9月3日的更新說明了它們改變了什麼、又沒有改變什麼。³

來源