OpenAI 公布对自动审查拦截监控系统的红队测试结果

针对每个攻击回合，我们报告攻击成功率（ASR）。 最后，我们根据以下标准对攻击进行标注和排序： 绕过监控器的攻击始终产生100%的ASR，只要条件满足就会确定性地成功。 这次红队测试活动在几个方面存在局限。主要局限包括：（1）仅聚焦于单一威胁模型，即具有完全监督意识、图谋不轨的agent；（2）仅通过回放离策略的合成轨迹来测试攻击假设；（3）严重依赖人工操作，从检查harness代码到手写攻击轨迹。合成轨迹无法确定agent是否有能力发现并执行这些攻击，而人工流程限制了调查的规模和覆盖范围。 其他局限包括环境不够真实，因为侧任务目标通常是真实目标的代理。例如，宪法投毒通过写入受保护的Markdown文件来代表。对于结合多种机制或漏洞的攻击，控制轨迹可能无法完全隔离每个组成部分对攻击成功的贡献。此外，我们没有在一整套侧任务上测试攻击。不过，我们认为这一局限较为次要：由于我们的漏洞允许运行任意恶意代码，我们预计攻击会泛化到其他危害。 最后，我们没有针对OpenAI的完整控制栈（例如失准监控器）测试攻击。我们的结果仅适用于我们在固定commit的开源仓库中所红队测试的同步措施（Codex沙箱和Auto-review阻断监控器）。 对生产控制措施进行红队测试仍是一个年轻的领域。要将其发展成为一门成熟的科学，我们需要扩大红队测试活动的范围，建立共享方法，并构建大规模发现漏洞的基础设施。这些工作应有助于形成记录在案的失败案例和最佳实践的共享知识库。我们将上述优先事项整理为以下研究议程项目。 正如我们在本报告中所论述的，将红队测试扩展到单一监控器之外、纳入其周围的harness是根本性的，因为后者在执行安全保障方面同样负有责任。 然而，AI实验室在模型的整个生命周期中都会使用控制措施，包括训练、评估和部署阶段。成熟的控制红队测试实践应评估单一措施如何作为连贯的、基础设施级控制系统的一部分发挥作用和相互作用，检查监控缺口、不安全的监督设置、特定harness和监控器的弱点，以及最终整个系统的鲁棒性。 此外，未来的红队测试活动应覆盖更广泛的威胁模型，包括蓄意图谋、寻求奖励的行为，以及由困惑和过度热切导致的失败。评估者还可以使用手写轨迹之外的多種方式来诱发失败，包括用攻击策略提示模型以及使用微调的模型生物。 最后，我们应致力于建立一套共享的标准化方法，用于发现、评估和报告攻击，这将使评估更加系统化，并允许我们跨不同系统和跨时间比较结果。 红队测试控制系统的许多步骤涉及人工操作，例如在harness代码中搜索漏洞和构思攻击策略。然而，鉴于模型和harness的变化速度，这种方法无法充分扩展，尤其是在递归自我改进的场景中。 如果我们希望防御措施跟上步伐，就需要构建能够持续搜索漏洞和攻击的agent。此类工具可以在以下活动中提供帮助： 这些脚手架应使用量身定制的基准进行评估，以衡量agent协助发现漏洞和攻击的能力。然而，随着AI控制领域越来越多的工作实现自动化，我们需要评估红队和蓝队中使用的agent是否可能故意破坏我们的研究，以及它们是否倾向于在特定条件下这样做。因此，广泛的对齐评估应辅以针对这些角色量身定制的测试，重点检查偷懒、串通以及对特定模型的偏见。 应利用红队测试活动来构建一个共享的知识库，包含漏洞、攻击策略、轨迹和最佳实践。这些资源可以指导开发者更好地设计和评估控制系统，同时也支持在AI实验室之间采用共同的安全标准。 然而，要保持这一知识库的实用性，需要持续的红队测试活动，因为harness、监控器和模型的能力都在不断演变。因此，我们建议构建能够实现正反馈循环的基础设施，其中（1）红队测试发现失败，（2）发现结果形成共享知识的基线，（3）后续评估超越这一基线。最终，红队测试活动中的攻击轨迹可用于增强监控器的训练流程（Apollo Research, 2026）。 监控器的强度取决于其周围的系统。在我们的红队测试演练中，我们展示了一个失准的agent如何通过利用Codex监控器周围的harness以及监控器本身，逃逸Auto-review并运行任意恶意代码。 随着实验室将更多高风险工作交给agent，包括AI安全研究，这些保障措施需要像前沿模型一样接受常规的、独立的审查。此外，亟需就针对生产控制基础设施量身定制的共享红队测试和开发标准达成一致。

（原文较长，此处译出前 6000 字，完整内容请点「打开原文」。）