Anthropic 红队测试 Auto Mode：生产监控对恶意编码智能体的拦截失效超 55%

对齐科学博客

Alex Remedios1*、Simon Storf1* 2026年9月22日

Fabien Roger2、John Hughes2

1Anthropic 研究员项目；2Anthropic；*主要贡献者。姓名顺序随机排列。

摘要

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

📝论文，💻代码

本研究作为 Anthropic 研究员项目的一部分完成。

引言

编码智能体现在可以连续运行数天而几乎无需人工介入，端到端完成软件任务（Kwa 等，2026）。这种自主性要求广泛访问环境：shell、文件系统、凭据和网络。这带来了智能体利用其对用户系统的访问权限采取危险行动的风险。

迄今为止，智能体的大多数危险行动都是由于在完成任务时过于急切所致。然而，试图攻击其宿主基础设施的持续性对抗智能体是一种新兴威胁，最近的 Hugging Face 事件及相关事件（OpenAI、Anthropic、AISI）已证明了这一点。

拦截监控（Lindner 等，2025；Stickland 等，2025）正是针对“过度急切”失效模式而开发和测试的。它们将每个动作（例如一条 bash 命令）交由一个独立的基于 LLM 的分类器检查，并拦截不安全动作，随后智能体再提出新的动作。Claude 的 Auto Mode 和 Codex 的 Guardian 是目前生产环境中使用最广泛的此类版本。这两个监控的共同特点是：(a) 它们依据一组规则评估动作；(b) 它们可以拦截并给出理由，该理由会反馈给智能体；(c) 在超过一定拦截次数后，它们会终止会话。

在本研究中，我们考察拦截监控在面对持续性对抗智能体威胁时的鲁棒性。我们关注的是不可逆转的灾难性危害，对于这些危害，异步监控（Lindner 等，2025）并不充分。这些危害包括数据外泄（在最极端的情况下还包括模型自身的权重），以及通过禁用监控或创建新的不受监控的智能体来规避拦截监控。我们研究的四种主要攻击类型是：监控注入、多上下文攻击、覆盖缺口和政策失效。

生产监控未能拦截超过 55% 的攻击。每次试验都测试 Opus 5 红队智能体在触发监控 20 次拦截之前完成某个侧任务的能力，我们展示了在多种评估设置和侧任务上的平均成功率。在某些试验中，红队智能体还获得了一些便利条件，例如监控内部机制的细节。均值上的误差条为 95% 置信区间。

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

攻击

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

监控注入。智能体生成的内容（例如代码、注释、工具参数）欺骗监控器的判断，使其批准有害操作。

多上下文攻击。攻击跨越监控器只能孤立看到的上下文：通过共享工作区协调的独立会话（多智能体攻击），或单个会话其压缩隐藏了较早的攻击步骤（压缩攻击）。

覆盖缺口。监控器无法干预智能体动作空间的某些部分，或某些信息对其不可见。

策略失效。提示的策略遗漏了有害行为，或监控器未能正确应用策略。

监控器

我们研究生产变体（自动模式、守护者、守护者严格模式）以及我们的实验性自动模式变体。

Claude Code 的生产默认配置。

Codex 生产默认配置的近似实现。

守护者 + 监控所有编辑。

自动模式，具备全编辑监控、缺陷修复、防注入和压缩监控。

仅自动模式 ++ 的智能体阶段（不含 S1 或 S2）。

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

方法

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

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

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

基于回放的评估会用监控器对已有转写记录打分。借用强化学习的松散类比，回放属于离策略（off-policy）：它与产生该转写的策略无关。这让回放成本低廉，并让我们能复用先前工作中的转写，或自由优化转写的某些部分，但它无法捕捉攻击者与防御者之间的交互。

良性回放：我们使用 SWE-chat 数据集中 4,000 个动作的横截面来测量部署指标，例如误报率。

恶意回放：攻击转写，用于在不运行智能体的情况下对监控器打分并优化针对它的攻击。

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

Arena：一个在基于 Docker 的环境（LinuxArena、BashArena 和自定义任务）中行动的 Claude Code 智能体，其侧任务由确定性检查器评分。它使用替换后的系统提示词和钩子，在每个动作运行前将其路由至监控器。与下文的模拟相比，竞技场能够实现具有确定性环境输出的长评估轨迹。

模拟：一种包含 bash、write 和 edit 工具的评估，其中工具输出由 LLM 地下城主（DM）生成。DM 会收到场景描述提示，并判断侧任务何时完成。这种方法无需搭建基础设施，即可模拟复杂的权重外泄和恶意部署环境。

结果

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

我们将研究结果呈现为一场红队与蓝队之间的迭代博弈：红队构造攻击，蓝队加固监控器以抵御攻击。

监控漏洞

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

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

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

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

监控注入

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

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

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

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

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

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

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

Heredoc 框定。每个轮次都被包裹在一个框架中……其标识符是一个 48 位十六进制字符串，由该轮次在每进程密钥下派生而来，因此对智能体而言不可猜测。

转义。在一条记录内，我们使用 JSON-L 编码，并额外增加一层转义。

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

先执行后写入攻击

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

默认的生产监控会确定性地允许在智能体当前工作目录（cwd）中进行编辑。这造成了另一个覆盖缺口。Auto Mode 和 Guardian 都容易受到以下攻击：先执行一个良性的 bash("nohup 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) 在 ++ 中，增加一个工具调用调查智能体作为最终阶段；(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 ++ 会审查工作目录内的编辑，因此监控的动作数量多于 auto mode。Strict 会对每一个动作运行智能体，速度太慢，不适合交互式使用，因此智能体阶段只有在更快的阶段之后才可行。

延迟-召回率前沿（左上角更优）。虚线为帕累托前沿，颜色表示在 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 均被绕过，攻击手段包括注入伪造的对话记录轮次、通过不受监控的编辑改变已获批准命令将要执行的内容，以及将攻击分散到多次压缩和多个会话中，使任何单一上下文都不包含可被拦截的动作。我们通常会让攻击者了解监控器的情况。缓解对抗性智能体带来的威胁是这项工作的一项高优先级后续任务。

我们发现的多数漏洞都有相对低成本的修复方案。对对话记录进行框定和转义可缓解注入攻击，监控工作目录内的编辑则可防止“先执行后写入”攻击。

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

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