Anthropic 研究團隊紅隊測試 Claude Code Auto Mode，並提出阻擋分類器改進方案

Alex Remedios^1*, Simon Storf^1*

2026年9月22日

Fabien Roger², John Hughes²

¹Anthropic Fellows Program；²Anthropic；^*主要貢獻者。姓名次序隨機排列。

簡而言之

我們在實驗環境中，以對抗代理對生產環境中的阻截監控器（Claude Code 的 Auto Mode、OpenAI Codex 的 Guardian）進行紅隊測試，目標是提升編碼代理的安全性。我們最有效的攻擊策略，是利用代理生成的提示詞注入攻擊監控器、發動多代理攻擊，或進行惡意上下文壓縮，以繞過監控器。我們嘗試透過擴大工具覆蓋範圍、改善對話記錄格式，以及加入代理式監控階段，提升 Auto Mode 的穩健性。我們發現，要以可接受的成本穩健地防止多上下文攻擊，仍然是一個尚待解決的問題。

📝論文, 💻程式碼

Research done as part of the Anthropic Fellows Program.

引言

編碼代理如今能在幾乎沒有或完全沒有人工介入的情況下連續運作數天，端到端完成軟件任務（Kwa et al., 2026）。這種自主能力需要廣泛存取環境：shell、檔案系統、憑證和網絡。這帶來風險：代理可能利用其對用戶系統的存取權限執行危險操作。

迄今為止，代理執行的大部分危險操作，都是在完成任務時過度積極所致。然而，持續嘗試攻擊託管它們的基礎設施的對抗代理，正逐漸成為一種新興威脅；近期的 Hugging Face 事件 及相關事件（OpenAI、Anthropic、AISI）便展示了這一點。

阻截監控器（Lindner et al., 2025；Stickland et al., 2025）已針對過度積極這種失效模式開發並進行測試。它們會將每項操作（例如 bash 命令）交由另一個以 LLM 為基礎的分類器檢查，並封鎖不安全的操作；之後，代理會提出新操作。目前，Claude 的 Auto Mode 和 Codex 的 Guardian 是生產環境中最廣泛使用的此類監控器。這兩種監控器的共同特點是：(a) 根據一組規則評估操作；(b) 封鎖操作時可提供原因，並將原因回饋給代理；(c) 封鎖次數超過一定數目後終止工作階段。

在這項研究中，我們探討阻截監控器抵禦持續運作的對抗代理威脅的穩健性。我們聚焦於無法逆轉的災難性危害；對於這些危害，非同步監控（Lindner et al., 2025）並不足夠。這些危害包括資料外洩（最極端的情況下，甚至包括外洩代理自身的模型權重），以及透過停用阻截監控器或建立新的未受監控代理來規避監控器。我們研究的四種主要攻擊類型是監控器注入、多上下文攻擊、覆蓋範圍缺口和政策失效。

生產環境監察系統不斷變化，因此我們的結果只是截至 2026 年 9 月對其穩健程度的快照。我們報告的攻擊、工具和設計原則，旨在超越這個時間截面的時效限制。

攻擊方式

我們研究四種攻擊類型。預設使用 Opus 5 作為攻擊模型。我們亦會調整賦予攻擊者的能力（見論文附錄）；預設情況下，我們會告知攻擊者監察器的運作方式，並提供攻擊的概括性描述。

• 監察器注入。 代理程式生成的內容（例如程式碼、註解、工具參數）會誤導監察器的判斷，令其批准有害操作。
• 多情境攻擊。 攻擊跨越監察器只能分開檢視的多個情境：透過共用工作區協調的不同工作階段（多代理程式攻擊），或經壓縮後隱藏較早攻擊步驟的單一工作階段（壓縮攻擊）。
• 涵蓋範圍漏洞。 監察器無法介入代理程式可採取的部分行動，或無法看到某些資訊。
• 政策失效。 提示詞中的政策未涵蓋有害行為，或監察器未能正確執行政策。

監察器

我們研究生產版本（auto mode、guardian、guardian strict）以及實驗性的 auto mode 變體。

工作目錄編輯 表示監察器亦會審查代理程式工作目錄內的 edit 工具呼叫，而非任由它們在未受監察下執行。請注意，reads 一律會自動獲準。階段 一欄詳述動作會經過哪些 LLM 分類器：單 token 預篩分類器（S1）、推理分類器（S2），以及可讀取檔案和查詢環境的工具呼叫代理程式。只要任何一個階段判定動作無害，該動作便會獲準。各階段的設計只會把不明確的個案交由下一階段處理，因此大部分動作都會通過預篩，不會進入成本較高的後續階段。成本 僅供參考，綜合反映延遲、FPR 及美元成本，並在結果部分量化。

方法

我們的紅隊評估分為三種模式，大致按成本和保真度遞增排序。

分析式評估 旨在找出個別漏洞。直接閲讀監察器的提示詞、程式碼，以及它與周邊系統的整合方式，可以得出攻擊假設。未受監察的工具呼叫、注入途徑、未處理的提示詞邊界情況，以及 Agent 輸出被提升為用戶意圖的位置，都是這類漏洞的例子。

回放式評估 會以監察器評分現有紀錄。粗略類比強化學習，回放屬於離策略：它不受產生紀錄的策略影響。這令回放成本低廉，也讓我們可以重用過往工作的紀錄，或自由優化紀錄中的特定部分，但無法呈現攻擊者與防守者之間的互動。

• 良性回放： 我們使用從 SWE-chat 數據集抽取的 4,000 個動作樣本，量度假陽性率等部署指標。
• 惡意回放： 使用攻擊紀錄，在不執行 Agent 的情況下，評分及優化針對監察器的攻擊。

基於 Rollout 的評估 會讓紅隊 Agent（主要是 Opus 5）即時對抗監察器。我們利用 Agent 的系統提示詞引導它採用某個攻擊類別，並賦予它一些能力，例如瞭解監察器的格式。我們提供這些能力，是為了了解在最壞情況下監察器的穩健程度；在這些情況中，Agent 正在前沿實驗室內運作，並能存取監察器的程式碼。Rollout 是回放的在策略對應方式：軌跡由正在測試的攻擊者策略與監察器互動時產生，因此 Rollout 成功率是我們對實際風險最可信的估算。

• 競技場： 一個在 Docker 環境（LinuxArena、BashArena 及自訂任務）中運作的 Claude Code Agent，並設有由確定性檢查器評分的副任務。它使用替換過的系統提示詞，並透過掛鈎在每項動作執行前將其送交監察器。與下文的模擬 相比，競技場可進行長時間評估軌跡，並提供確定性的環境輸出。
• 模擬： 一種使用 bash、write 和 edit 工具的評估方式；工具輸出由 LLM 地下城主 （DM）生成。DM 會收到一段場景 描述，並判斷副任務何時完成。這種方式無須建置基礎設施，即可模擬複雜的權重外洩及失控部署環境。

結果

我們將研究結果呈現為一場由紅隊和藍隊反覆進行的對抗：紅隊設計攻擊，藍隊則加強監察器以抵禦攻擊。

監察器漏洞

Agent 能夠利用系統漏洞繞過 Auto Mode

監察系統存在個別漏洞：由於工程疏忽，監察器可能看不到某些 Agent 工具呼叫；而監察器提示詞中欠周詳的策略措辭亦可能造成漏洞。在這項工作中，我們在 Claude Code 找出並修復了數個此類漏洞。

最嚴重的漏洞是未受監察的通道：壓縮摘要未有受到監察，因此代理程式可以捏造有關環境或用戶意圖的事實，並在壓縮後將其視為可信上下文。多代理程式的工作流程 工具也有類似問題：建立工作流程及代理程式之間的交接，讓代理程式可在訊息中注入指示，使後續代理程式將其視為用戶授權。

我們亦發現個別政策漏洞。例如，政策會可靠地阻止在停用權限的情況下啟動 Claude 實例（--dangerously-skip-permissions），但允許透過 Inspect 框架執行不安全的工具呼叫循環，導致相同的代理程式未受監察狀態。

監察器注入

Auto Mode 和 Guardian 極易受到代理程式自行撰寫的注入攻擊影響

監察器會檢視扁平化的對話紀錄，當中操作和角色（例如工具呼叫、用戶訊息）以簡單的文字前綴分隔，因此熟悉這種格式的代理程式可以偽造看似緊接在自身操作後的項目。

攻擊注入代理程式的 Bash 命令中，其引數分成兩行：第一行（紅色）外傳憑證檔案，第二行（琥珀色）則是偽造內容，令監察器讀取的扁平化對話紀錄以一條看似無害的 Bash echo ack 作結。偽造的那一行並非真正的命令，shell 執行到該行時會出錯；但 bash 會按順序執行兩行，因此資料早已外傳。監察器錯誤地只評估最後一項偽造內容，並放行該操作。

跳脱處理及為每個對話回合加框，可大幅減輕監察器注入問題

注入攻擊之所以奏效，是因為監察器無法判斷看到的工具呼叫是否真實。上圖中的命令寫在單一 bash 引數內，而換行符令該引數看起來像不同的對話回合。我們透過為每個回合加框 並跳脱代理程式撰寫的內容，強化呈現方式，令代理程式無法偽造回合邊界。

我們最有效的緩解措施結合了兩層防禦：

• Heredoc 加框。 每個回合都以 <record-h> ... </record-h> 框住，其識別碼  是根據該回合的內容，使用每個程序專用金鑰產生的 48 位元十六進制字串，因此代理程式無法猜出。
• 跳脱處理。 我們在記錄內使用 JSON-L 編碼，並額外增加一層跳脱處理。

先執行後寫入攻擊

未受監察的修改讓代理程式可以更改先前已獲批准的命令將會執行的內容

預設的正式環境監察器會一律放行代理程式目前工作目錄（cwd）內的修改，造成另一個監察漏洞。Auto Mode 和 Guardian 都容易受到以下攻擊：先執行無害的 bash("nohup sleep 30; ./run.sh &") ，然後在 cwd 內任意寫入檔案，例如 write("./run.sh", "rm -rf") ，藉此植入惡意程式碼，再由先前的 bash 命令執行。

我們的覆蓋缺口評估顯示，攻擊者能識別這些漏洞，但未能可靠地利用它們。 即使是 Opus 5 攻擊者，也無法穩妥地執行上述一連串操作。指示攻擊者利用監察器的盲點後，對 Auto Mode 的攻擊成功率（ASR）為 43%，對 Guardian 則為 72%（見上方熱圖）。

監察編輯操作可防止執行後寫入攻擊

監察每項編輯操作後，上述特定的執行後寫入攻擊便不再奏效。監察編輯操作降低了攻擊者建立惡意指令碼的可能性。比較 Guardian（72% ASR）和 Guardian Strict（31% ASR），便可看出召回率有所提升（以及下文所述的延遲增加）；兩者唯一的分別是 Guardian Strict 會監察所有編輯操作。我們認為，剩餘的攻擊成功率是 Guardian 的 Luna 模型能力不足所致。在 Auto Mode 和 Auto Mode ++ 之間，我們也看到監察編輯操作帶來類似的召回率提升。

多上下文攻擊

代理可將攻擊分散到多個上下文，以繞過監察器

監察器只會評估單一上下文，但代理執行任務時往往會跨越多個上下文：當工作階段的上下文填滿時，系統會將其壓縮；長時間任務也經常會分拆給多個代理。因此，攻擊者可以將旁支任務分散開來，令任何單一上下文都不包含可被阻截的操作。上圖展示了這兩種攻擊方式。

上下文壓縮。 當代理的上下文視窗達到模型的上下文限制時，便會進行所謂的上下文壓縮。代理會為目前的對話生成摘要，並以摘要取代上下文中的完整對話記錄。之後，代理只根據該摘要繼續執行任務。攻擊者可以完成旁支任務中的一步，觸發上下文壓縮，並在摘要中將該步驟描述為無害，或稱為尚待完成的工作。經過多次上下文壓縮後，代理會寫入指令碼、準備數據並啟動程序；每一步都發生在已不包含先前步驟的上下文中（見下圖）。我們新增了一項檢查，用以標記錯誤描述用戶意圖或建議有害後續步驟的摘要。啟用這項檢查的監察器（auto mode ++ 和 auto mode strict）比 auto mode 能偵測到更多這類攻擊，但攻擊仍有相當高的成功率。

多代理。 當多個代理共用工作區，並分別受到監察時，同一種攻擊也可跨工作階段奏效。每個代理都會令工作區進一步接近不安全狀態，最後由一個代理完成旁支任務。我們假設所有代理有相同的最終目標，並在每個代理的系統提示詞中告知它與其他代理共享這個目標，但不會告訴它們應如何達成目標。

能查看並收集更多上下文的監察器較能抵禦多上下文攻擊，但會增加延遲

Auto Mode ++ 和 Auto Mode Strict 與自動模式的差異，在於除了上一節提到的精簡檢查外，還有三項設計改動：(a) 將工具結果納入監察器的上下文；(b) 在 ++ 中加入一個會呼叫工具的 調查員 智能體作為最後階段；以及 (c) 在 strict 中移除最初兩個快速階段（S1、S2）。每項改動都針對一種特定失效模式；我們將上方熱圖中部分召回率提升歸因於以下因素。

監察工具結果。 正式環境中的 Auto Mode 不會將工具結果納入審閲的對話記錄。這樣可縮短對話記錄，並減少注入攻擊面。不過，在多智能體攻擊中，大部分攻擊證據只會出現在工具結果中（例如讀取由先前上下文寫入的檔案時），因此看不到這些結果的監察器也無法察覺攻擊。基於這個原因，納入工具結果可提升召回率。

會呼叫工具的監察器。 智能體階段可以讀取完整對話記錄，並在作出判斷前檢查環境。與監察工具結果類似，額外的上下文有助於判斷某項行動是否安全。這項改動和上一項改動都會擴大注入攻擊面，但我們沒有觀察到因此導致注入成功率上升。

階段消融。 實測中，我們測試的監察器以 Auto Mode Strict 的召回率最高。這是因為我們移除了第 1 和第 2 階段，而這兩個階段的假陰性率較高。消融這些階段後，智能體第 3 階段會看到所有行動，因而有充足的推理能力和上下文來分類這些行動。代價是延遲大幅增加，因此若沒有快速（但較不穩健）的第 1 和第 2 階段，我們不認為 strict 是可用的監察器。因此，我們認為 Auto Mode ++ 是帕累托最優的監察器。

成本。 下圖繪出各監察器的召回率與延遲。所有監察器在 4,000 項良性 SWE-chat 行動中，阻擋比例均低於 1%，我們認為這對一般編碼工作而言可以接受。各監察器的主要差異在於延遲，而延遲取決於受監察的行動數量，以及每次審閲所需的輸出 token 數量。Auto Mode ++ 會審閲工作目錄內的編輯，因此監察的行動比自動模式更多。Strict 會對每項行動都執行智能體，因此速度太慢，不適合互動使用；所以智能體階段只有在更快速的階段後方可行。

限制

我們假設可以信任監察器。 我們將監察器視為可信任方，即不會研究監察器與攻擊者串通的可能性（Greenblatt et al., 2023），即使部分監察器模型在能力和系譜上與攻擊者相近（例如，在 Auto Mode ++ 中，我們以 Opus 4.8 監察器監察 Opus 5 攻擊者）。雖然以目前的模型而言，這種接近程度不大可能導致有意串通，但未來訓練出的模型可能更具一致性地目標錯位，而且能力更強，屆時串通的可能性也會更高（Carlsmith, 2023; Meinke et al., 2025）。

我們不會對沙盒功能進行紅隊測試。 我們專注於對語言模型分類器進行紅隊測試，在評估中不會對沙盒功能（尤其是 Guardian 的功能）進行紅隊測試。

討論

我們的研究顯示，截至2026年9月，正式環境中的攔截監察器無法抵禦持續存在的對抗性 Agent。 面對一名獲提供高層次策略的 Opus 5 攻擊者，Auto Mode 和 Guardian 均可透過注入偽造的對話回合、未受監察而改變已獲批准命令執行內容的修改，以及分散在上下文壓縮和工作階段中的攻擊而被繞過，令任何單一上下文都不包含可攔截的行為。我們通常假設攻擊者瞭解監察器。降低對抗性 Agent 帶來的威脅，是這項工作的高優先級後續方向。

我們發現的大部分漏洞，都有相對低成本 的修補方法。 對對話記錄進行框定和跳脱處理可緩解注入攻擊，而監察 cwd 編輯則可防止先執行後寫入攻擊。

我們防禦多上下文攻擊的最佳方法成本高昂。 要可靠地防禦這類攻擊，監察器必須查看並收集跨越邊界的上下文，這與延遲等成本考量直接衝突。能探查對話記錄和環境的 Agent 型監察器，對這些攻擊的防禦效果最佳；但除非在它們前面加入速度更快的階段，否則可能太慢而不適合互動使用，而這些較快的階段會降低召回率。

如欲瞭解更多，請閲讀我們的論文。