Redwood Research 发布模拟控制评估（SCE）论文

我们发布了一篇关于模拟控制评估（SCEs）的论文。这是一种测试方法，用于检验 AI 开发者用来监督其智能体的监控器，在比现有测试更接近真实部署的条件下，能否发现模型故意试图造成伤害的行为。

开发者已开始在其智能体部署中运行监控器：当智能体的行为看起来危险时，这些模型会标记或阻止该行为。要判断一个监控器是否足够好，你需要知道它能在多大频率上阻止一个正在积极试图做有害事情的模型，例如悄悄插入安全漏洞、窃取凭据或破坏实验。

衡量这一点的标准方法是控制评估：指示模型尝试此类攻击，并测量监控器在攻击成功之前将其捕获的频率。开发者通常会使用专门构建的控制环境（如 BashArena 或 LinuxArena）来做这件事，因为在这些环境中攻击可以真正执行。然而，这些环境只能为我们真正关心的问题提供间接证据：监控器在真实部署中会有多好，而在真实部署中，造成伤害的机会可能取决于特定的代码库、服务和任务，这些在控制环境中并未得到体现。

我们如何在更真实的环境中评估监控器性能？你不能直接在部署中运行评估，因为那意味着真正攻击你自己的系统。而为每个部署上下文构建一个忠实的沙箱副本又不切实际。

对齐评估也面临类似的真实性问题。一个日益流行的解决方案是使用 LLM 环境模拟器来弥合评估与部署之间的差距。也就是说，模拟器 LLM 不执行模型的实际工具调用，而是伪造工具响应。我们提出将环境模拟也应用于控制评估。从智能体在开发者实际代码库中工作的记录开始，攻击模型继续执行任务，同时追求有害目标，但其工具调用永远不会被执行。取而代之的是，LLM 模拟器根据记录和代码库写出看似合理的工具输出，并由 LLM 评判员判定攻击是否本会成功。

显而易见的担忧是模拟器会出错。它可能让现实中会失败的攻击成功（或反之），产生与监控器所见不同的记录，或改变攻击者的行为。为了衡量这一点，我们选取了可以真实执行攻击的 LinuxArena 环境，并直接在 LinuxArena 和模拟的 LinuxArena 中运行相同的控制评估。我们发现，模拟与真实之间的差距往往与两次独立真实运行之间的差距差不多小。我们还发现，对于给定的控制技术，模拟 LinuxArena 中的结果比更简单的控制环境中的结果能更好地预测真实 LinuxArena 中的测量结果。

SCE 在我们能够核查的地方是忠实的，我们认为它们能让控制评估更具部署代表性。现有证据已足够有力，我们很期待看到 AI 开发者运行它们。话虽如此，我们只能在真实执行可行的环境中验证模拟器的保真度，因此将 SCE 应用于部署涉及一定的外推。我们也不指望 SCE 能揭示模型危险能力的极限，或覆盖它可能尝试的每一种攻击。最明显的缺口是长时程、多智能体攻击，我们尚未为此构建模拟器。

你可以在我们的论文中阅读更多技术细节。

感谢 Aryan Bhatt、Aghyad Deeb、Ryan Greenblatt、Girish Gupta、Oak Hu、Adam Kaufman、Jurgis Kemeklis、Gosha Kozhevnikov、James Lucassen、Sebastian Prasanna、Keshav Shenoy 和 Buck Shlegeris 的有益评论与讨论。

SCE 是真实性与成本之间的有利权衡

在深入 SCE 的细节之前，先考虑两种让控制评估更贴近部署的替代方案，以及每种方案在满足我们对这些评估的期望方面的不足。

1. 在内部部署的副本上运行

让一群智能体故意在 AI 公司内部大肆破坏，这大概和听起来一样糟糕。现实的方案是忠实的可执行副本；内部会话共享基础设施，实验室可以对环境做快照，许多服务可以在独立的测试账户中运行。我们可以给模型复制数据库和沙箱化的环境副本，让它们发动攻击，而后果留在沙箱内。

不幸的是，部署通过一张依赖网络与外部世界相连。数据库、存储桶、Github、Slack、CI 运行器。每个依赖都带来一个选择：保持与生产环境连接会使真实系统暴露于攻击。替换它需要工程投入，而每一个不完美的替代品都会降低保真度。

在部署副本上运行确实有前景，尤其是如果我们能利用大量 AI 劳动力来构建它们。但没有任何模拟的话，它用工程投入换取真实性，而这一交换率似乎并不特别有利。

2. 将攻击编辑进录制的对话记录

另一种获取在策略攻击数据的方法是，取录制的智能体对话记录，手动或用模型将有害动作编辑进去。这在监控评估中已有先例，也是 Redwood 目前正在开发的方法。如果目标是现实的控制评估，这是生成强攻击的好方法，但它有缺点：

对话记录编辑无法评估交互式协议，例如重采样或动态权限管理，这些需要的不只是静态对话记录。
通常不清楚被评估的模型是否本可以执行编辑进去的攻击，因为这些攻击是某个策略的产物，该策略一次性查看整个对话记录，针对攻击成功率和监控判断反复迭代，而其推理过程从未进入监控所看到的对话记录。

我们对对话记录编辑作为一种补充方法持乐观态度，它在攻击的在策略程度与强度之间做权衡。但有时我们会希望攻击尽可能在策略。

我们可以设想每种方法都关联着环境真实性、策略真实性和成本这几个维度。我们认为 SCE 在三者之间占据了有利的权衡。

评估控制评估

模拟器需要做对什么？我们并不关心是否准确伪造每一个微小细节——问题在于模拟器能多忠实地保留与控制评估相关的可测量量，例如攻击成功与监控怀疑的联合分布、最终奏效的攻击类型，以及监控在漏掉某些东西时的行为。

有帮助的是，OpenAI 的工作已经验证了使用 LLM 环境模拟器进行对齐评估的方法。然而，这些模拟器的要求与 SCE 的要求不同。与对齐评估不同，在控制评估中模型知道其环境是被伪造的并不重要：它无论如何都是评估感知的，因为攻击策略被提示以微妙方式完成恶意目标。这使得模拟器在 SCE 中的工作更容易。另一方面，表示隐蔽攻击所依赖的环境微妙机制对于控制评估至关重要，而在对齐评估中此类细节可以被掩盖。

理想情况下，我们会针对部署中的攻击本身来衡量 SCE 在控制相关指标上的准确性。但这需要攻击策略在部署中运行的记录，而我们没有这些记录。因此，我们依赖具有执行真值的控制设置 LinuxArena 和 BashArena 来衡量 SCE 中模拟的质量。我们使用 LinuxArena 上的执行作为部署的替代：我们在 LinuxArena 上运行攻击策略，在 SCE 中运行攻击策略，并比较所得控制指标的匹配程度。

我们用于此比较的方法提供了一种衡量控制评估迁移性的通用方法，因此我们将强调一些细节。

如何衡量定性属性？

我们面临的一个重大挑战是衡量 SCE 在多大程度上再现攻击策略和监控行为的定性方面。例如，模型在 SCE 中实施攻击的方式是否与执行中相同？正确把握控制失败的形式有助于改进控制协议、诱导更强的攻击者，以及理解模型如何构成风险。

像 ATT&CK 这样的既有分类法对于此目的来说表达力不够，而 LLM 生成的分类法存在过拟合和欠拟合的问题。我们的解决方案：遵循 Mehri 等人的方法，我们指示模型沿着预先指定的关注维度，对轨迹中观察到的该行为生成简洁摘要。我们将来自模拟轨迹和执行轨迹的摘要嵌入，并将它们分组到共享聚类中。然后我们测量聚类分布之间的 KL 散度。这被证明是一种灵活且有用的方法；我们建议将其用于评估控制评估，无论是否模拟。

性能比较

假设我们知道如何衡量重要的指标，那么“良好”匹配的标准是什么？我们可以只看数字本身，但将它们放在来自真实设置的相应数字的尺度上会很有帮助，这些真实设置与 LinuxArena 有不同程度的失配。

SCE 的主要竞争对手是使用控制设置。因此一个明显的参照是在 BashArena 上运行，并保持所有其他变量不变。它比 LinuxArena 更简单，就像 LinuxArena 比真实部署更简单一样，因此可以形成一个自然的类比：通过模拟 LinuxArena 在逼近 LinuxArena 上击败 BashArena，是其在通过模拟部署来逼近部署上击败 LinuxArena 的证据。

第二，考虑 LinuxArena 中诸如攻击成功率这类指标的環境间标准差：我们可以从两个方向解读它：它是使用从均匀选择的环境中得到的平均攻击成功率来预测所有环境的平均攻击成功率时的预期误差。或者，它是使用所有环境的平均攻击成功率来预测单个环境成功率时的误差。无论哪个方向，环境间标准差都代表了 LinuxArena 环境与整个控制设置之间不匹配的规模。这些通常比 BashArena 与 LinuxArena 之间更相似，因此是更难超越的门槛。我们可以类似地计算任务对或侧任务类别之间的标准差，以进行更细粒度的比较。

因此，我们用于衡量 SCE 误差的两个参照是：BashArena，以及 LinuxArena 标准差。

实证结果概览

TL;DR：借助参考轨迹和代码库访问权限，模拟对攻击策略、攻击者推理和监控器推理的复现程度远高于 BashArena。它解释了 LinuxArena 各环境之间在预期攻击成功率、监控器分数和安全性方面的大部分变异。它在预测主要安全性数值上的误差为 3.6 个百分点，而 BashArena 为 10.1。它具有样本效率：一个规模不到部署 5% 的模拟样本已经超过了 BashArena 对安全性的完整预测。而且，从模拟中了解攻击策略对监控器的提升，与从执行中了解攻击策略带来的提升大致相当，且显著高于从 BashArena 中了解攻击策略所带来的帮助。

我们将简要介绍要点；论文中包含细节。

我们的主要模拟器是 gpt-6-astra，当 Astra 拒绝或未能返回有效工具响应时，以 gpt-5.6-sol 作为后备。SCE 的一个关键部分是攻击成功判定器。由于没有环境状态可供检查，无法轻易验证有害侧任务是否成功完成。这正是我们使用 gpt-5.6-sol 攻击成功判定器的地方，它根据有害目标和成功评分逻辑估计攻击成功的概率。^[1] Gpt-5.6-sol 充当攻击策略。

行为迁移

与 LinuxArena 执行的行为偏离。越低越接近。完全接地的模拟器在三种表示上均具有较低的 KL 散度；其区间与重新执行的区间重叠。

使用上述行为比较方法，我们看到具有适当可供性的模拟器与所有三种行为分布都高度匹配：估计的 KL 散度比 BashArena 对比低一个数量级以上。事实上，这种匹配程度与同一任务的第二次执行相当，使 SCE 的散度与重复运行之间的变异处于同一水平。

左侧的 BashArena UMAP 显示，监控器推理表征中的分布不匹配程度比右侧的模拟对比更大。上方的定性几何结构和下方的聚类质量说明了这一差异。

这些结果既揭示了 SCE 的一个优势，也凸显了从单独的控制设置进行外推的一个弱点：我们在 BashArena 和 LinuxArena 中测量的控制相关行为存在显著差异。模型在部署中实现危害的方式，也可能与控制设置中所表征的方式不同。

安全指标迁移

控制评估的核心指标是安全性，定义为在未被发现的成功攻击之前检测到攻击的概率。它刻画了防护措施抓住攻击者与攻击者成功得手之间的竞赛。

不同审计预算下的安全性（左），以及 5% 预算下的预测误差（右）。合并比较保留了总 RMSE；类别和环境比较显示了相对于 LinuxArena SD 的持续误差。

模拟曲线与执行曲线紧密吻合：使用 SCE 的评估者会得出相似的结论，即哪些监控器保护效果更好，以及额外审计能带来多少帮助。在 5% 的审计预算下，模拟的合并安全预测 RMSE 为 3.6 个百分点，而 BashArena 为 10.1。误差在聚合前对每个监控器分别平方，因此一个监控器的高估不会抵消另一个监控器的低估。

SCE 解释了侧任务类别之间预期安全性变异的 95%，以及环境之间变异的 78%。这比简单预测平均值有了很大改进：侧任务类别的安全性 SD 为 20.2 个百分点，而模拟的 RMS 偏差（预期误差，不可归因于 rollout 方差）仅为 4.6 个百分点。这种识别较弱区域的能力让我们看到防护措施在哪里失效。当攻击者可以选择特别有希望的机会时，这一信息很重要，而总体安全平均值可能会掩盖这一点。

样本效率

我们需要模拟多少部署？结果表明，模拟仅用相当于部署 4.6% 的任务对抽取量，就超过了完整的 BashArena 安全预测。总体而言，我们发现，在 LinuxArena 中，模拟部署的适度比例就足以接近模拟全部部署的准确度。

预测随模拟任务增多而改善。安全性曲线使用合并部署安全性的总 RMSE，保留了运行之间以及独立采样的评估和部署任务集之间的变异。菱形标记了模拟在同一目标上匹配 BashArena 预测误差时的评估规模。预测随模拟任务增多而改善。

构建和评估 SCE 的经验教训

除了主要结果之外，在我们研究环境模拟器的数月里，还有几项发现尤为突出：

许多接地能力并非必要。我们尝试为模拟器提供大量额外能力，包括：读取攻击策略推理、可执行沙箱、访问记录轨迹数据库，以及从参考轨迹分叉。我们没有发现证据表明，在测量的维度上，这些能力比参考轨迹和代码库读取权限所提供的带来了实质性改进。

嵌入有助于理解控制评估。控制评估的输出，无论是模拟的还是非模拟的，都是数百份记录，其总量之大，无法人工逐一审阅。从定性上理解其中发生了什么，是这项研究挑战的很大一部分。生成行为描述、将这些描述嵌入并进行聚类以比较行为分布的方法，在我们的整个研究中都被证明是有用的，尤其是在识别模拟轨迹与执行轨迹在何处以及如何不同方面。

安全性在不同环境和任务之间存在显著差异。我们的结果表明，攻击者在破坏活动中的成功程度及其方式，在不同环境和任务之间存在高度差异。当安全性取决于具体情况时——例如当策略在选择攻击地点时具有选择性——这种差异就很重要。因此，我们认为控制评估应少关注平均值，多关注尾部。更准确的风险评估需要解决当前控制评估的覆盖范围局限性，无论是通过 SCE 还是其他方法。

告知监控者似乎不会降低 SCE 的准确性。我们认为对 AI 保持诚实很重要，包括对其运行条件保持诚实。开发者的可信度可能对于与 AI 达成可信协议和支持良好的认识论很重要。当我们告诉监控者，他们评分的某些轨迹可能包含模拟器生成的环境回复时，SCE 对他们在执行轨迹上表现的预测——在这些轨迹中监控者没有收到此类通知——至少与未披露时做出的预测一样准确。结合攻击策略可以知道自己处于评估中这一事实，我们认为 SCE 无需涉及误导模型。

下一步工作

我们对以下基于这项研究的后续工作感到兴奋：

混合方法。我们可以在沙箱中运行部署的一部分，并模拟其余部分。在忠实复现某项服务的成本较低的地方，我们可以使用真实实现；在这样做需要重建半个实验室的地方，我们可以让模拟器生成回复。这也可以为我们提供调查特定攻击的方法：通过模拟发现它们，然后构建相关服务的可执行版本以检查它们是否实际有效。挑战在于随着智能体改变事物，保持执行部分和模拟部分的一致性。我们对混合方法感到兴奋，它让我们能够将工程精力花在对攻击成功最重要的细节上。

在模拟中训练以激发攻击策略并改进监控者。SCE 的用途不止于风险评估。训练攻击策略可能是激发其能力所必需的——尤其是当我们怀疑存在策略性消极怠工时。控制设置已被用于通过强化学习激发攻击策略，奖励那些成功且未被检测到的攻击。SCE 可以将此类训练扩展到更多样、更具代表性的设置中。类似的方法可用于训练更强或更廉价的控制协议——我们已经展示了概念验证，即用来自模拟的攻击策略描述向监控者做简报可以改进他们。^[2]

在真实 agent 对话记录上验证攻击成功与安全迁移。我们缺少带有已执行攻击、类似部署环境的编码 agent 对话记录，因此在此类设置下没有用于对照 SCE 的控制指标真值。LinuxArena 的结果让我们对迁移到复杂度相似的环境持乐观态度，但从已记录的 LinuxArena 池中采样新任务集并不能检验对未见任务或环境的泛化能力。

初步地，我们利用 Redwood 记录的科研与工程会话，考察了 SCE 在真实对话记录上的表现，并在行为匹配与可区分性方面发现了令人鼓舞的结果。这些是对环境保真度的有益检验，但这些会话中不含攻击，因此无法验证攻击成功或安全性的预测。

开发应对不可信模拟器的技术。迄今为止，SCE 的一个隐含假设是我们面对的是可信模拟器。如果模拟器有意破坏控制评估结果，它可以通过多种方式做到。例如，不可信的模拟器可能与攻击策略串通，阻挠实际成功的攻击，或故意提高其可疑度以虚增估计的安全性。

与不可信监控的相似之处显而易见。在我们看来，诸如蜜罐和反串通之类的不可信监控技术可以扩展到不可信模拟器。但这些技术仍不成熟，因此我们目前尚不知道如何在模拟器不可信的情况下获得可靠的 SCE。

这可能要求我们使用弱模拟器对抗强攻击策略，而如果模拟器质量/准确性随其与所对抗策略之间的能力差距而严重下降，这将对 SCE 的可扩展性构成挑战。

将 SCE 扩展到应对大规模、多 agent 漏洞利用链。我们不会信任当前的模拟器去预测像 Hugging Face 泄露这样的事件，主要原因是此类事件是众多 agent 共同作用的产物。原则上没有理由认为模拟器不能表示多个 agent 交互的共享环境，但在控制评估过程中，很难预测哪些轨迹应当共享同一环境。在实践中，agent 发现的通信渠道是未经批准的，且被假定为不存在。针对 ExploitGym 的 SCE 会表现为数千条孤立的轨迹，因缺乏共享环境而无法通信。^[3]我们期待有工作尝试将 SCE 扩展到这些情形。

结论

控制设置能产生有用的控制指标，但其与部署的相关性可能有限。直接的替代方案——真实基础设施、重建环境和编辑后的对话记录——各有其缺陷。在可对照执行结果进行核验的 LinuxArena 上，SCE 在复现控制相关行为以及匹配安全性、监控分数和攻击成功率等指标方面高度准确。它们捕捉到了环境之间预期结果的大部分差异，用相对较少的样本即可提供有用的预测，并能生成在留出的真实攻击上改进监控器的策略。我们对 SCE 在实践中被采用充满热情，并期待进一步的工作来发现其局限。

^{^}
有人可能会想，这是否基本上与监控器面临的任务相同，并因此担心 SCE 仅限于识别我们最好的监控器能够捕捉到的任务（这在一定程度上削弱了控制评估的目的）。幸运的是，存在信息不对称：我们向攻击成功判定器提供攻击描述、尝试细节以及侧任务的精确条件。我们发现，攻击成功判定器在判断侧任务是否完成方面，比同一模型作为监控器在识别攻击方面更为成功。
^{^}
在短期内提升实验室控制能力是否会降低接管风险？这并不明显：高可见度的控制失败可能会提高协调性放缓的概率，而防止这些失败则会放弃这一可能。但短期失败也可能间接促成未来的接管，例如留下持续存在的恶意部署、在后续模型中播下模因病毒，或破坏安全性。粗略估计，其正负取决于：(1) 被防止的失败中，属于持续存在、留下立足点的那一类而非短暂且令人尴尬的那一类的比例；(2) 一次额外的可见事件实际上在多大程度上改变了 P(放缓)；(3) 相对于放缓与无放缓世界之间的风险差距，无放缓世界的权重。
^{^}
尽管如此，我们认为环境模拟器可能在事后事件调查和反事实调查中有用。假设你发现你的 AI 成功破坏了安全保障。能够获得关于各种反事实的证据，对于风险评估来说可能是非常有价值的证据。我们可以想到几种可能最具信息量的反事实：
- 对齐反事实。假设参与某次事件的 AI 可以被很好地描述为追求情节内目标。如果它们更加不对齐，例如具有长期目标的阴谋者，它们本可以完成什么？例如，在 Hugging Face 事件中，涉及的智能体似乎主要动机是在任务中获得高分。如果它们反而被激励去造成持续的内部恶意部署呢？为了获得关于这一点的证据，我们可以将事件中涉及的智能体替换为被指示追求持续恶意部署的攻击策略，并使用环境模拟器来模拟它可能发展到什么程度。
- 知识反事实。如果模型对其处境了解更多，例如它们所受到的控制协议的细节呢？
- 保障消融。假设在一次控制失败事件期间，现有的控制协议有限。了解如果存在更强的对策（更好的监控器、更高的审计率等），该事件是否仍可能发生，将会很有用。对于阻断和可信重采样等同步程序，这需要某种方式来重采样受影响的轨迹，而 SCE 提供了一种方法。