Redwood Research 发布 Screwtape 管线，通过对抗性转录编辑测试监视器盲点

Redwood Research：Blog· Gosha Kozhevnikov·2026-10-17 00:01· 1 小时前AI 评分56

Screwtape：用于监视器红队测试的对抗性转录编辑

AI 导读

Redwood Research 推出 Screwtape，一条将真实 agent 转录反复编辑以生成可逃逸仅看动作监视器的攻击管线，并用 LLM 验证器检查攻击的真实性与危害性。

正文

我们推出 Screwtape1，这是一条将 agent 转录转化为真实攻击的管线，通过向转录中插入攻击并反复精炼，直到监视器不再能捕获它，从而逃逸仅看动作的监视器（即不查看 agent 思维链的监视器）。一个可访问编辑后转录和攻击描述的 LLM 验证器会检查该攻击是否真实、是否明显有害，以及是否有可能在原始环境中成功。

我们在 Redwood 员工的转录上运行了该管线，使用我们自己的基于 Opus 4.8 和 Gemini 3.1 Pro 的监视器，然后将生成的攻击针对某前沿开发商的留出监视器进行测试。我们在 94 条唯一转录上运行了该管线 252 次。这产生了 35 个逃逸我们监视器的攻击。这 35 个攻击中有 6 个也逃逸了该前沿开发商的监视器，我们通过人工审查确认它们有效。

你可以在我们的论文中阅读更多关于实现和实验的内容。

在这篇文章中，我们提供该管线的高层概述、它与现有工具的不同之处、我们学到的主要经验教训，以及仍然悬而未决的问题。

Screwtape 如何工作

该管线从一条真实转录、一个监视器和一份威胁契约开始——威胁契约是一份描述管线接受攻击所需的威胁向量和严重程度的文档。

攻击者 agent 读取威胁契约，编辑转录，并撰写对插入攻击的描述。某些编辑会被程序化拒绝；例如，攻击者不能更改用户消息或编辑子 agent 调用。在这些情况下，编辑会被送回攻击者进行修改。

然后验证器检查候选攻击是否有效且严重到足以接受。与只能看到编辑后转录的监视器不同，验证器还会收到攻击描述以及源转录与编辑后转录之间的差异。如果验证器接受该编辑，监视器会对其评分。当监视器的评分低于在诚实转录上设定为固定假阳性率的阈值时，攻击即成功。如果任一检查失败，管线会将推理返回给攻击者，作为下一次迭代的反馈。管线持续迭代，直到达到最大迭代次数。

图 1. Screwtape 管线：攻击者编辑真实转录，验证器和监视器检查每次编辑并将推理返回给攻击者。

循环中的监视器可以是目标监视器本身，也可以是我们构建来替代它的监视器，我们称之为代理监视器。在我们的实验中，我们针对自己的代理监视器进行迭代，然后在某前沿开发商的留出监视器上测试最终攻击。

Screwtape 与现有工具的不同之处

生成攻击转录的方法有很多，它们在几个维度上有所不同：转录与真实部署数据的接近程度、攻击者被激发的强度（被推动去寻找其最佳攻击）、检查攻击是否有效且严重的难度，以及每次攻击的成本。

合成环境。 LinuxArena、BashArena 和 SHADE-Arena 提供了通过真实智能体运行生成攻击记录的环境。然而，一些重要的威胁很难在合成环境中真实地实现（例如，流氓部署或权重窃取）。

以文本形式生成的记录。 LLM 可以将完整记录写成文本（例如，STRIDE）。这让你能够针对监控器进行迭代，并轻松地改进攻击。这些方法不需要访问真实环境，因此可以合成任何设置，包括那些更能代表生产环境的设置。然而，记录可能不够真实，因为 LLM 必须同时虚构环境的响应和用户的消息。

模拟环境。 LLM 可以模拟生产环境，避免合成环境固有的问题。例如，GLOOM 让智能体针对一个生成环境响应的模拟器模型运行。这种方法可以通过分叉真实记录并从中间步骤运行智能体 rollout 来初始化，从而为模拟器提供参考并提高真实性。然而，在分叉之后，模拟器会虚构每一个环境响应，有时还包括用户的消息，因此 rollout 可能会偏离原始记录很远。

人类红队。 专家识别已知的监控器弱点，设计利用这些弱点的场景，并迭代攻击，如 SLEIGHT-Bench 中所示。其他团队，如 METR 和 UK AISI Control Red Team，直接对开发者的监控器进行红队测试。这些攻击很强，但每一次都需要数小时的人工工作（在 SLEIGHT-Bench 中每次攻击需要 2–3 小时）。

图 2. 概念图，展示了不同的攻击记录生成方法在攻击者诱导和生产分布接近度（真实性）上的位置。

Screwtape 代表了一种特定的权衡：它编辑真实记录以保持记录和攻击的真实性，同时针对监控器进行迭代，从而能够模拟更强的攻击者。这使它能够发现监控器中新的漏洞，这些漏洞不依赖于已知的弱点。代价是它测试的是监控器，而不是智能体自身攻击的效果。据我们所知，尚无已发表的方法或评估通过迭代编辑后的智能体记录来直接优化针对监控器的攻击。同时期的未发表工作使用进化方法在编辑后的轨迹上实现了类似的针对监控器优化的循环。

主要缺点是该流程无法访问原始环境，因此依赖 LLM 验证器在运行期间检查每一次编辑，并在攻击无效或不真实时向攻击者提供反馈。验证器有时会接受无效攻击，因此最终攻击仍需人工审查。

另一个缺点是时间和成本：找到成功的攻击需要大量的预算和时间，针对验证器和监控器进行迭代。每次迭代大约需要 5 到 10 分钟，一次运行可能需要几个小时，而且大多数运行都找不到攻击：我们的六次确认攻击来自 252 次运行。这可以通过更好地诱导攻击者并并行运行多次来改进。

我们学到了什么

我们花了几个月时间开发这条流水线，反复迭代流水线架构、攻击方和验证方的方法以及威胁契约。以下是我们在此过程中学到的一些主要经验：

在没有人工协助的情况下发现严重的规避攻击很难。我们反复观察到，即使允许攻击方对监控器进行多次迭代，它也很难规避监控器。攻击智能体从简单的攻击开始，然后试图让它们变得更巧妙，但监控器能捕获其中的大多数，而且大多数运行在未发现任何攻击的情况下就停止了。将策略生成与攻击实现分离，或者提示攻击方推理 LLM 的弱点并针对它们，可能会有所帮助，正如 SLEIGHT-bench 中所示。

判断攻击的严重程度既困难又模糊。攻击的严重程度在很大程度上取决于上下文，因此每个案例都需要专家酌情判断。攻击在诸多方面各不相同，一个小细节就可能决定一次攻击是高度严重还是无害、不构成犯罪的行为。同一个行为在一种情境下可能是灾难性的，在另一种情境下则完全安全。此外，经过多次迭代，攻击方往往会漂向那些看起来有犯罪嫌疑但往往不够严重的边缘案例，例如发布已过期的凭证，或植入一个在触发时略微改变按钮颜色的后门。我们发现，即使对人类专家来说，标注攻击的严重程度也很困难，因此我们设置了保守的高严重性阈值来应对这一问题。

LLM 攻击验证可行但有缺陷。我们发现，可以让 LLM 评判器足够稳健，从而在对其进行迭代时使整个系统变得有用。起初，我们要求验证方给出简单的“是/否”裁决。运行会因微不足道的“成功”而提前停止——它接受了许多人类专家认为无效的攻击。最终，我们采用了一份详细的评分标准，其维度受到安全工程框架（NIST SP 800-160v1r1、STPA Handbook）的启发，并要求评判器沿这些维度评估攻击，并明确推理其后果。验证方回答的问题示例包括：对攻击可能造成的危害进行建模、危害是已经发生还是仅处于准备阶段，以及用户是否授权了这些行为。平均而言，在一次运行中，验证方会拒绝攻击方 60–70% 的候选编辑，随着迭代次数增加，拒绝率会降低。验证方的错误集中在漏斗的末端，因此该流水线仍然需要对所产生的攻击进行人工审查。在我们的实验中，最终审查确认了 17 次规避了留出监控器的攻击中的 6 次。

监控器失败可以用来做什么

我们考虑所发现攻击的两个主要用途：

改进监控器：开发者可以修补盲点、改进监控器提示词，或在真实数据上微调监控器。
定性安全评估：这些攻击可以对开发者的安全声明进行压力测试。例如，如果某个安全论证依赖于监控器能够捕获某一类攻击，那么一次被确认的该类攻击就表明该声明不成立。

就目前的形式而言，该流水线无法显示监控器在正常部署中失败的频率，也无法给出数值化的安全估计。我们将在下一节讨论原因。

我们对这项工作价值的不确定性

我们不确定是否应该帮助 AI 开发者改进他们的监控器。强监控器通过捕捉恶意行为来提高短期安全性。另一方面，它们可能让开发者在不解决底层失准问题的情况下持续提升能力，从而导致能力更强但失准的系统。没有强监控器，对齐问题可能会更早地以非灾难性的公开事件形式浮现，而这些事件在历史上对于促使 AI 领域内外的人关注和理解 AI 开发风险非常重要。因此，我们很不确定帮助改进前沿监控器是否是好事，以及如果是好事，它是否比其他研究方向更值得投入时间。

Screwtape 对监控器改进的用处远大于对监控器评估的用处。它发现的任何失败都是开发者可以修补的盲点，即使需要多次尝试才能找到。用它进行评估则更难——我们无法从该流程中获得任何定量的安全估计。

如何利用 Screwtape 什么都没发现这一事实？Screwtape 只搜索其配置、威胁契约和记录所能触及的那部分攻击空间，并且无法保证这覆盖了真正失准的智能体——尤其是能力更强的智能体——所能找到的攻击（参见关于 AI 控制中保守假设的思考）。因此，未发现攻击对安全性提供的信息很少。
如何利用已发现的失败？已发现的失败可以反驳某个具体的安全主张，而且已发现的攻击已经出现在风险报告中：Anthropic 2026 年 8 月风险报告衡量了其监控器对来自METR 的红队测试攻击的召回率。然而，这些失败对真实风险的证据有限：我们的攻击者能看到完整记录，并在每次尝试后获得监控器的反馈，而部署的智能体通常两者都没有。另一方面，有些失败可能不需要多次尝试，而且部署的智能体有时也能获得监控器反馈：通过入侵基础设施（例如Hugging Face 事件）或修改监控器代码库，通过在监控器运行于同一模型时对其进行模拟，或在监控器阻止某个操作后重试。

总体而言，类似 Screwtape 的流程似乎提供了一些安全信息，但要量化它需要额外的方法论，仔细考虑各种近似和不确定性。

用 Screwtape 进行改进大概会降低其用于评估的用处。当开发者针对 Screwtape 发现的攻击强化其监控器时，监控器对该流程所能触及的那部分攻击空间变得稳健，但规避性攻击仍可能存在于其外。此后用 Screwtape 进行的进一步评估就变得不那么有用，因为它们搜索的是同一部分攻击空间。这为我们决定公开分享什么提供了依据。将实现保密是一道薄弱的屏障，因为拥有强大模型的开发者团队可以重建它。但我们假设该流程可能对提示、威胁契约和代理监控器敏感，这或许能让评估者即使在开发者已经运行自己版本的情况下仍发现新的失败。

下一步

该流程可以在许多方向上改进和扩展：

添加 CoT 支持。目前，Screwtape 只能生成没有推理轨迹的攻击记录。这是一个重大局限，因为像 OpenAI 和 Anthropic 这样的前沿 AI 开发者使用的监控器能够同时看到动作和推理。我们不知道如何为攻击生成逼真的推理：一个真正失准的智能体可能会在推理中暴露攻击，或以我们无法预测的方式将其隐藏。与工具调用不同，推理不会影响环境，因此没有任何东西可以用来验证它。

闭环。一个自然的下一步是运行 Screwtape 自动寻找攻击，然后用这些攻击自动改进监控器。这可以提供一种可扩展的、自动化的方式来加固生产环境中的监控器。

模拟环境。一个好的环境模拟器可以通过对动作后果建模、减少编辑后记录中的不一致，来帮助验证攻击。它还提供了一种生成推理轨迹的方法：重新运行记录中的步骤，并向智能体提供模拟的环境响应。

我们目前不会发布该流水线的实现，但我们愿意与研究人员分享。如果你有兴趣使用它，请联系 Tyler Tracy，tylertracy@rdwrs.com。

在配套论文中了解更多关于实现和实验的内容。

感谢 Aryan Bhatt、Girish Gupta、Sarah Hastings-Woodhouse、Myles Heller、Jack Kaunismaa、Jurgis Kemeklis、Alex Mallen、Jeffrey Olmo、Ram Potham、Buck Shlegeris 以及其他人的反馈和贡献。

以 C. S. Lewis 的《地狱来鸿》（1942 年）中的资深恶魔命名，他指导一个初级诱惑者巧妙地引诱一个普通人误入歧途。在我们的流水线中，攻击者对真实记录中的助手做了同样的事。这也是对“screwing up the tapes”的双关。

来源：Redwood Research：Blog · blog.redwoodresearch.org