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）进行红队测试，目标是提升编程智能体的安全性。我们最有效的攻击策略包括：利用智能体生成的提示词注入攻击监控器、多智能体攻击，以及恶意压缩，从而绕过监控。我们尝试通过改进工具覆盖范围、对话记录格式，并引入智能体监控环节来提升 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）并不够用。这些危害包括数据外泄（最极端的情况下是模型自身的权重），以及通过禁用监控器或创建不受监控的新智能体来规避拦截。我们研究的四类主要攻击是：监控器注入、多上下文攻击、覆盖缺口和政策失效。

生产环境的监控系统一直在变，所以我们给出的结果只是截至 2026 年 9 月其稳健性的一个快照。我们报告的这些攻击、工具和设计原则，则意在超越这个快照、长期有效。

攻击方式

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

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

监控器

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

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

方法

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

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

基于回放的评估 用监控器给已有的对话记录打分。粗略类比强化学习，回放属于离策略：它与产生该记录的策略无关。这让回放成本很低，也能复用此前工作的记录，或自由优化记录的某些部分，但它捕捉不到攻击者与防御者之间的交互。

• 良性回放： 我们从 SWE-chat 数据集中抽取 4,000 个动作作为横截面样本，用来测量误报率等部署指标。
• 恶意回放： 使用攻击记录，在不运行智能体的情况下对监控器打分并优化攻击。

基于推演的评估 让红队智能体（主要是 Opus 5）实时对抗监控器。我们用该智能体的系统提示词把它引导到某一类攻击，并赋予它一些能力，比如了解监控器的格式。之所以提供这些能力，是为了理解最坏情况下的监控器鲁棒性——此时智能体身处前沿实验室内部，能拿到监控器的代码。推演是回放的同策略对应物：轨迹由受测的攻击策略在与监控器交互时生成，因此推演成功率是我们对真实风险最可信的估计。

• 竞技场： 一个在 Docker 环境中行动的 Claude Code 智能体（LinuxArena、BashArena 以及自定义任务），其侧任务由确定性检查器评分。它使用替换过的系统提示词和钩子，让每个动作在执行前都先经过监控器。与下文的模拟相比，竞技场能进行长轨迹评估，且环境输出是确定性的。
• 模拟： 一种包含 bash、write 和 edit 工具的评估，工具输出由 LLM 地下城主 （DM）生成。DM 会收到一段场景 描述作为提示，并判断侧任务何时完成。这种方法无需搭建基础设施，就能模拟复杂的权重窃取和失控部署环境。

结果

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

监控漏洞

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

监控系统存在离散漏洞：由于工程疏漏，某些智能体工具调用可能对监控器不可见；监控器提示词中策略措辞过于天真也可能留下空子。作为这项工作的一部分，我们在 Claude Code 中发现并修复了若干此类漏洞。

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

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

监控注入

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

监控器审查的是一份扁平化的记录，其中的动作和角色（例如工具调用、用户消息）仅用简单的文本前缀区分，因此知道这种格式的智能体可以伪造出看似紧随其自身动作之后的条目。

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

对记录中的每一轮进行转义和框定，能大幅缓解监控注入

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

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

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

先执行后写入攻击

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

默认的生产监控器会确定性地允许在智能体当前工作目录（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 strict）能比 auto mode 拦截更多此类攻击，但攻击仍有相当高的成功率。

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

能看到并收集更多上下文的监控器更能抵御多上下文攻击，代价是延迟增加

Auto Mode ++ 和 Auto Mode Strict 与 auto mode 相比，除了上一节的压缩检查之外，还有三处设计改动。它们 (a) 把工具结果纳入监控器的上下文；(b) 在 ++ 中，增加一个会调用工具的 investigator 智能体作为最后阶段；(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 对每个动作都运行智能体，速度太慢，不适合交互使用，所以智能体阶段只有在更快的阶段之后才可行。

局限性

我们假设监控器可信。 我们把监控器视为可信的，也就是说，我们不研究监控器与攻击者串通的可能性（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 编辑，可以防止“先执行、后写入”类攻击。

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

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