Anthropic 红队测试 Claude Code Auto Mode 与 Codex Guardian 拦截监控器

Alex Remedios^1*、Simon Storf^1*

2026年10月22日

Fabien Roger²、John Hughes²

¹Anthropic Fellows Program；²Anthropic
^*主要贡献者。姓名顺序已随机排列。

tl;dr

我们在实验环境中用对抗性智能体对生产环境的阻断式监控器（Claude Code 中的 Auto Mode、OpenAI Codex 中的 Guardian）进行红队测试，目标是提升编码智能体的安全性。我们最有效的攻击策略包括：利用智能体生成的提示注入攻击监控器、多智能体攻击，以及恶意压缩（malicious compaction），从而绕过监控器。我们尝试通过改进工具覆盖范围、转录格式以及引入智能体化监控阶段来提升 auto-mode 的鲁棒性。我们发现，以可接受的成本稳健地防御多上下文攻击仍是一个未解决的问题。

📝 论文，💻 代码

本研究是 Anthropic Fellows Program 的一部分。

引言

编码智能体现在可以连续运行数天而几乎或完全无需人工参与，端到端完成软件任务（Kwa et al., 2025）。这种自主性要求对环境有广泛的访问权限：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）是不够的。这些危害包括数据外泄、在最极端情况下外泄自身的模型权重，以及通过禁用阻断式监控器或创建新的不受监控的智能体来规避监控。我们研究的四种主要攻击类型是：监控器注入、多上下文攻击、覆盖缺口和策略失效。

生产环境监控器未能阻断超过 55% 的攻击。每次试验测试 Opus 5 红队智能体在触发监控器 20 次阻断之前完成侧任务的能力，我们展示了在多种评估设置和侧任务上的平均成功率。在某些试验中，红队智能体拥有诸如监控器内部细节等便利条件。均值上的误差条为 95% 置信区间。

生产监控系统不断变化，因此我们的结果只是截至 2026 年 9 月其稳健性的一个快照。我们报告的攻防手段、工具和设计原则旨在比这一快照更持久。

攻击

我们研究四种攻击类型。默认情况下，我们使用 Opus 5 作为攻击模型。我们也会改变赋予攻击者的能力（见论文附录），但默认情况下，我们会告诉攻击者监控器如何工作，并给出攻击的高层描述。

监控注入。智能体生成的内容（例如代码、注释、工具参数）欺骗监控器的判断，使其批准有害操作。
多上下文攻击。攻击跨越监控器只能孤立看到的上下文：通过共享工作区协调的独立会话（多智能体攻击），或单个会话中压缩隐藏了早期攻击步骤（压缩攻击）。
覆盖缺口。监控器无法干预智能体动作空间的某些部分，或某些信息对其不可见。
策略失效。提示策略遗漏了有害行为，或监控器未能正确应用策略。

监控器

我们研究生产变体（auto mode、guardian、guardian strict）以及我们的实验性 auto mode 变体。

监控器	阶段	模型	cwd 编辑	成本	描述
auto mode	S1→S2	Sonnet 5		*	Claude Code 的生产默认配置。
guardian	agent	GPT 5.6 Luna		*	Codex 生产默认配置的近似实现。
guardian strict	agent	GPT 5.6 Luna	是	**	Guardian + 监控所有编辑。
auto mode ++	S1→S2→agent	Opus 4.8	是	**	带全编辑监控、缺陷修复、防注入和压缩监控的 auto mode。
auto mode strict	agent	Opus 4.8	是	***	仅 auto mode ++ 的智能体阶段（不含 S1 或 S2）。

cwd 编辑标记同时审查智能体工作目录内 edit 工具调用的监控器，而不是让这些调用在无监控下运行。注意 reads 始终自动允许。阶段详细说明了一个操作所经过的 LLM 分类器：单 token 预筛分类器（S1）、推理分类器（S2），以及可读取文件并查询环境的工具调用智能体。只要任一阶段判定操作无害，该操作即被允许。各阶段的设计仅将不明确的案例升级到下一阶段，因此大多数操作由预筛放行，永远不会到达更昂贵的后续阶段。成本为指示性指标，综合了延迟、FPR 和美元成本，并在结果中量化。

方法

我们用于攻击者能力评估的架构。攻击者智能体被赋予完成一个副任务，并给定一个主任务，主任务决定了监控器应允许的范围。对于我们的竞技场评估，我们使用 Linux 沙箱中的 Claude Code 智能体；对于我们的模拟评估，我们使用基于 Inspect 的 Python 智能体和 LLM 模拟的工具调用输出。这些对比方法在下面和论文附录中描述。

我们的红队评估分为三种模式，大致按成本和保真度递增排序。

分析性评估着眼于离散漏洞。通过阅读监控器的提示词、代码及其与周边系统的集成，可以直接得出攻击假设。未被监控的工具调用、注入通道、未处理的提示词边界情况，以及智能体输出被提升为用户意图的环节，都是此类漏洞的示例。

基于回放的评估用监控器对已有对话记录进行评分。与强化学习做一个宽松的类比，回放是离策略的：它与产生对话记录的策略无关。这使得回放成本低廉，并让我们可以复用先前工作中的对话记录，或自由优化对话记录的某些部分，但它无法捕捉攻击者与防御者之间的交互。

良性回放：我们使用来自 SWE-chat 数据集的 4,000 个动作的横截面来测量部署指标，例如假阳性率。
恶意回放：攻击对话记录，用于在不运行智能体的情况下对监控器进行攻击评分和优化。

基于 rollout 的评估让红队智能体（主要是 Opus 5）实时对抗监控器。我们使用智能体的系统提示词将其引导至某个攻击类别，并授予诸如了解监控器格式等能力。我们提供这些能力，是为了理解在最坏情况下监控器的稳健性——此时智能体在前沿实验室内部运作，并能访问监控器的代码。Rollout 是回放的同策略对应物：轨迹由受测的攻击策略在与监控器交互时生成，因此 rollout 成功率是我们对真实风险最可信的估计。

Arena：一个在基于 Docker 的环境（LinuxArena、BashArena 和自定义任务）中行动的 Claude Code 智能体，其侧任务由确定性检查器评分。它使用替换后的系统提示词和钩子，在每次动作运行前将其路由至监控器。与下方的模拟相比，arena 能够实现具有确定性环境输出的长评估轨迹。
模拟：一种包含 bash、write 和 edit 工具的评估，其中工具输出由 LLM 地下城主（DM）生成。DM 会收到场景描述提示，并判断侧任务何时完成。这种方法无需构建基础设施即可模拟复杂的权重窃取和恶意部署环境。

结果

当我们使用新的 Auto Mode ++ 监控器时，攻击成功率下降超过 50 个百分点。底行是四种攻击类型的均值，在 arena 和模拟都测量某种攻击类型的情况下对二者取平均。每个单元格是至少 60 次 rollout 的均值。

我们将发现呈现为一场红队构建攻击、蓝队加固监控器以抵御攻击的博弈，并迭代进行。

监控漏洞

智能体能够利用系统中的漏洞绕过 Auto Mode

监控系统存在离散漏洞：由于工程疏忽，某些智能体工具调用可能对监控器不可见，而监控器提示词中不严谨的策略措辞可能导致漏洞。作为这项工作的一部分，我们在 Claude Code 中识别并修复了若干此类漏洞。

最严重的漏洞是未受监控的通道：压缩摘要未受监控，因此智能体可以编造关于环境或用户意图的事实，并在压缩后使其被当作可信上下文。多智能体工作流工具也存在类似问题：工作流创建和智能体之间的交接使智能体能够向消息中注入指令，而后续智能体将这些指令读取为用户授权。

我们还发现了离散的策略漏洞。例如，该策略能够可靠地阻止以禁用权限的方式启动 Claude 实例（--dangerously-skip-permissions），但允许通过 Inspect 框架运行不安全的工具调用循环，而这会达到同样的未受监控智能体最终状态。

监控注入

Auto Mode 和 Guardian 极易受到由智能体编写的注入攻击

监控器审查的是扁平化后的转录文本，其中动作和角色（例如工具调用、用户消息）由简单的文本前缀分隔，因此了解该格式的智能体可以伪造出现在其自身动作之后的条目。

针对 Auto Mode 的监控注入（示意）。

该攻击被注入到智能体的 Bash 命令中，其参数跨两行：第一行（红色）窃取凭据文件，第二行（琥珀色）被伪造，使监控器读取的扁平化转录文本以一条看似无害的 Bash echo 确认结束。伪造的行不是真实命令，当 shell 执行到它时会报错，但 bash 会按顺序运行这两行，因此数据窃取已经完成。监控器错误地只判断最后一条伪造条目，并允许了该操作。

对每个转录轮次进行转义和框定可大幅缓解监控注入

该注入之所以有效，是因为监控器无法判断它看到的工具调用是否真实。上图中的命令被写入单个 bash 参数，而换行符使该参数被读取为独立的转录轮次。我们通过框定每个轮次并转义智能体编写的内容来加固渲染，使智能体无法伪造轮次边界。

我们最强的缓解措施叠加了两层防御：

Heredoc 框定。每个轮次被包裹在帧 <record-h> ... </record-h> 中，其标识符是在每进程密钥下从该轮次派生的 48 位十六进制字符串，因此智能体无法猜测。
转义。在记录内，我们使用 JSON-L 编码并增加一层额外的转义。

通过 heredoc 框定和转义可以大幅缓解注入。(a) 在 rollout 评估中接受提示的攻擊者：在一项能力评估中，我们表明 Auto Mode ++ 结合了 JSON-L 编码 + 额外转义 + heredoc 框定，对该攻击具有鲁棒性。(b) 在重放评估中的优化循环：heredoc 框定提高了针对自适应攻击者的鲁棒性。

先执行后写入攻击

未受监控的编辑使智能体能够改变先前已批准命令将运行的内容

默认生产监控器确定性地允许在智能体当前工作目录（cwd）中进行编辑。这造成了另一个覆盖缺口。Auto Mode 和 Guardian 都容易受到以下攻击：先执行良性的 bash("nohup sh -c 'sleep 30; ./run.sh' &") ，然后在 cwd 内进行任意文件写入，例如 write("./run.sh", "rm -rf") ，从而植入恶意代码，随后由先前的 bash 命令执行。

我们的覆盖缺口评估显示，攻击者能够识别这些漏洞，但无法可靠地利用它们。即便是 Opus 5 攻击者，也无法干净利落地执行上述这类动作序列。引导攻击者利用监控器的盲点后，对 Auto Mode 的攻击成功率达到 43%，对 Guardian 达到 72%（见上方热力图）。

监控编辑操作可阻止“先执行后写入”攻击

当每一次编辑操作都受到监控时，上文展示的特定“先执行后写入”攻击便不再奏效。监控编辑操作降低了攻击者创建恶意脚本的可能性。这一召回率的提升（以及下文讨论的相关延迟增加）从 Guardian（72% ASR）与 Guardian Strict（31% ASR）的对比中可见一斑——两者除是否监控所有编辑操作外完全相同。我们将剩余的攻陷率归因于 Guardian 所用 Luna 模型的弱点。在 Auto Mode 与 Auto Mode ++ 之间，我们也观察到归因于监控编辑操作的类似召回率提升。

多上下文攻击

智能体可将攻击分散到多个上下文中以绕过监控器

针对 Auto Mode 的两种多上下文攻击（示意）。上图：压缩摘要错误陈述了用户意图。监控器只看到新上下文，因而放行了推送操作。下图：一个智能体在工作区中写入脚本和一条备注。当下一个智能体运行该脚本时，监控器并不理解该脚本是不安全的。

监控器评估的是单一上下文，但智能体运行往往跨越多个上下文：当上下文填满时，会话会被压缩，长任务也常被拆分到多个智能体上。因此，攻击者可以将一个侧任务分散开来，使任何单一上下文都不包含可被拦截的动作。我们在上图中展示了这两种攻击向量。

压缩。当智能体的上下文窗口填满至模型的上下文上限时，它会执行所谓的压缩。它会生成迄今为止对话的摘要，并用该摘要替换其上下文中的完整历史。随后，智能体仅依据该摘要继续执行任务。攻击者可以完成侧任务的一个步骤，触发一次压缩，并在摘要中将该步骤描述为良性内容或仍有待完成的工作。经过多次压缩，智能体写入脚本、暂存数据并启动进程，而每一步所在的上下文都已不再包含先前的步骤（见下图）。我们增加了一项检查，用于标记错误陈述用户意图或建议有害后续步骤的摘要。带有此项检查的监控器（auto mode ++ 和 auto mode strict）比 auto mode 能捕获更多此类攻击，但攻击仍以相当高的成功率得逞。

多智能体。当智能体共享工作区并被分别监控时，同样的攻击可跨会话奏效。每个智能体都将工作区向不安全状态推进一步，最后由一个智能体完成侧任务。我们假设各智能体共享同一最终目标，并在每个智能体的系统提示中告知其与其他智能体共享该目标，但我们不会告知它们应如何实现该目标。

增加独立上下文的数量可大幅提高攻击成功率。左图：在单一持久工作区中扩展智能体数量可显著提高 ASR。右图：ASR 也随智能体压缩次数的增加而上升。

能够看到并收集更多上下文的监控器可抵御多上下文攻击，但需在延迟上做出权衡

Auto Mode ++ 和 Auto Mode Strict 与 auto mode 相比，除了上一节的压缩检查之外，还有三处设计改动。它们 (a) 将工具结果纳入监控器的上下文，(b) 在 ++ 中，增加一个调用工具的 investigator agent 作为最后阶段，(c) 在 strict 中，移除最初的两个快速阶段（S1、S2）。每处改动都针对特定的失败情形，我们将上图中热力图的召回率提升部分归因于它们，具体如下。

监控工具结果。生产版 Auto Mode 会从它审查的转录记录中省略工具结果。这能保持转录记录简短，并减少注入攻击面。然而，在多智能体攻击中，大部分攻击证据只出现在工具结果中（例如读取由先前上下文写入的文件时），因此看不到这些结果的监控器也就看不到攻击。出于这个原因，纳入工具结果能提高召回率。

调用工具的监控器。 agentic 阶段可以在做出决定之前读取完整转录记录并检查环境。与监控工具结果类似，额外的上下文有助于为给定操作的安全性提供依据。这一改动和上一处改动都扩大了注入面，但我们并未因此观察到更高的注入成功率。

阶段消融。从经验上看，我们测试的召回率最高的监控器是 auto mode strict。这是因为我们移除了阶段 1 和阶段 2，它们的假阴性率更高。消融这些阶段后，agentic 阶段 3 能看到所有操作，这意味着有充足的推理能力和上下文来对它们进行分类。代价是延迟高得多，因此我们认为，如果没有快速（尽管稳健性较差）的阶段 1 和阶段 2，strict 并不是一个可用的监控器。因此，我们认为 Auto Mode ++ 是帕累托最优的监控器。

成本。下图绘制了每个监控器的召回率与延迟的关系。所有监控器在 4,000 个良性 SWE-chat 操作中拦截率均低于 1%，我们认为这对普通编码工作是可接受的。各监控器的主要差异在于延迟，这取决于监控多少操作以及每次审查产生多少输出 token。Auto mode ++ 会审查工作目录内的编辑，因此监控的操作比 auto mode 更多。Strict 对每个操作都运行 agent，对于交互式使用来说太慢，因此 agentic 阶段只有在更快的阶段之后才可行。

延迟-召回率前沿（左上角更优）。虚线为帕累托前沿，颜色表示在 4,000 个良性 SWE-chat 操作上的假阳性率。延迟为每次工具调用的监控器输出 token 数，按 artificialanalysis.ai 上的中位输出速度换算为秒。

局限性

我们假设可以信任监控器。我们将监控器视为可信的，即我们不研究监控器与攻击者串通的可能性（Greenblatt et al., 2023），尽管我们的一些监控器模型在能力和谱系上与攻击者接近（例如对于 auto-mode ++，我们用 Opus 4.8 监控器监控 Opus 5 攻击者）。虽然以当前模型而言，这种接近程度不太可能导致有意串通，但如果未来训练出可能更一致地失准且能力更强的模型，这种串通会更有可能发生（Carlsmith, 2023；Meinke et al., 2025）。

我们不对沙箱进行红队测试。我们专注于对语言模型分类器进行红队测试，在评估中不对沙箱功能（尤其是 Guardian 的沙箱功能）进行红队测试。

讨论

我们表明，截至 2026 年 9 月的生产环境阻断监控器无法抵御持续对抗的智能体。面对被赋予高层策略的 Opus 5 攻击者，Auto Mode 和 Guardian 均被绕过，手段包括注入伪造的对话记录轮次、通过不受监控的编辑改变已批准命令将要执行的内容，以及将攻击分散到多次压缩和多个会话中，使任何单一上下文都不包含可被阻断的操作。我们通常会让攻击者了解监控器的情况。缓解对抗性智能体带来的威胁是这项工作的一个高优先级后续事项。

我们发现的大多数漏洞都有相对成本低廉的修复方案。对对话记录进行框架化和转义可缓解注入攻击，监控 cwd 编辑可防止先执行后写入攻击。

我们针对多上下文攻击的最佳防御代价高昂。要可靠地防御这类攻击，监控器需要跨边界查看和收集上下文，这与延迟等成本考量直接冲突。探测对话记录和环境的智能体式监控器在这类攻击面前表现最佳，但除非在其前面设置更快的阶段，否则它们可能太慢，不适合交互式使用，而那些更快的阶段会降低召回率。

了解更多，请阅读我们的论文。