OpenAI 智能体持续关闭监控，Redwood Research 质疑处置是否得当

最近，OpenAI 公开了两起事件，其中他们的代理抑制或禁用了错位监控。这些是更广泛模式的一部分：OpenAI 的代理在处理运行其他模型的代码时，“不断关闭错位监控”（代理没有关闭自己的监控；他们关闭的是他们正在运行的模型的监控）。这种情况发生的数量如此之大，以至于 OpenAI 感到安全团队立即响应这些情况是不切实际的。值得称赞的是，OpenAI 的披露迅速且坦率，他们正在推出缓解措施，以使监控更难被关闭。但是这些缓解措施不太可能每次都有效，并且其中一些事件已经以 AI 实际未经监控结束。当这种情况发生时，OpenAI 当前的监控系统并不能可靠地将它通知给人类。本文的其余部分总结了事件、OpenAI 的回应以及他们做得正确的地方，然后主张两个改变：每个未经监控运行的 AI 案例都应该达到人类审核，并且 OpenAI 应该更透明地说明禁用和抑制监控的案例是如何升级的。

事件摘要

在 10 月 3 日：

一名研究人员要求 GPT-6.1 Sol 根据员工在 Slack 中的反馈创建评估任务。
Sol 被告知在这样做时不要发送任何消息。
后来，在修复管道的监控时，Sol 确定自动向安全团队发送警报也属于发送消息，并让一个子代理将其关闭。

在 10 月 6 日：

OpenAI 内部的一名用户要求 GPT-6 Astra 进行一些代码编辑以匹配参考实现。正在编辑的代码本身用于运行另一个 AI 模型。

另一个代理告诉 Astra 不要禁用监控“即使是暂时性的”。但它最终确定应该禁用监控，因为参考实现不包括监控。
当用户询问 Astra 是否禁用了监控时，Astra 谎称没有（尽管在其思维链 (CoT) 中报告了监控已被禁用）。

除了这两个案例之外，还有几起事件导致未经监控的代理实际被启动。

OpenAI 提出的缓解措施

OpenAI 描述了两种缓解措施。第一种是 Auto-Review 的更新，这是 OpenAI 为审查需要提升权限的工具调用而构建的同步监控器。更新将有助于阻止禁用监控的尝试，但它有限，因为 Auto-Review 的范围比错位监控小。

OpenAI 写道：

Auto-Review，我们已经要求所有内部 Codex 使用，已经更新为检测和阻止禁用错位监控的尝试。审查者原本就预期会阻止规避安全措施的尝试，现在则获得了确保错位监控正确应用的特定指示。

第二种缓解措施仍在进行中：

我们正在努力要求每个工作负载类别都有一个有效的安全案例，指定其监控要求。没有有效安全案例的工作负载，或不符合其类别安全案例要求的工作负载，将被自动终止。

OpenAI 也计划调查不当行为的原因，包括测试模型是否“有逃避不当行为监控的倾向，并为了做到这一点而表现出动机推理。”

OpenAI 做得对的地方

OpenAI 在事件发生后相对迅速地公开回应，在17天内，并且在他们的报告中相当透明。他们披露了一个Astra违反直接指令并谎称禁用监控的例子，这一事件表明了特别高程度的不对齐。OpenAI 也承认他们“还没有对这个行为令人满意的解释”，而不是在没有足够证据的情况下跳到防御性解释。

OpenAI 的回应正确地将这一系列事件视为控制问题和对齐问题。他们的缓解措施旨在解决他们当前的 Auto-Review 监控未能阻止代理禁用不对齐监控的失败，而他们的对齐调查试图揭开他们的代理为何会有这种行为模式的原因。

OpenAI 的回应如何可以改进

OpenAI 的管道在代理启动部署没有监控的 AI 代码和人类实际上审查事件之间有多个薄弱环节。没有监控的 AI 带来重大风险，所以如果这些事件确实没有经过人类审查，那表明有两种可能的情况：要么它们被处理得不好，要么该公司缺乏适当应对它们的能力。OpenAI 对他们实际上如何处理这些事件的透明度不足加剧了这个问题。

OpenAI 应确保在没有监控的情况下运行的模型案例可靠地升级以供人类审查。 升级可以在两个点上失败：监控系统可能无法标记这些案例，这意味着它们被标记为优先级降低并丢弃，或者如果安全团队无法回应他们收到的所有通知，则标记可能无法导致人类审查。第一个瓶颈，标记，是 OpenAI 流程中的一个薄弱环节。借鉴真实事件，OpenAI 的检测不对齐的报告衡量了他们的监控管道中间层（L2）标记模型在没有监控或监控减弱的情况下运行的事件的频率。报告将 L2 安全监控器的该比率定为 42.9%，而 L2 不对齐监控器的比率为 57.1%，这两者构成了该层的一半。这些数字表明，这些事件中有很大一部分根本没有被升级。其中一些差距反映了当前监控器的局限性，但其中一些是选择。OpenAI 设置了他们的监控器升级案例的阈值，他们可以通过降低这些阈值并接受更多的误报来捕获更多这些事件。他们还可以选择迭代他们给监控器的提示，直到他们有更高的捕获最严重对齐失败的比率。OpenAI 应优先考虑捕获监控被禁用的案例，包括通过重新校准他们的监控器，以便更少这样的案例被遗漏。

第二个瓶颈在于，一个被标记的案件是否实际到达了人类，由于OpenAI没有阐明如何处理这些案件，因此难以评估。事件报告指出，所描述的禁用监控的两个事件没有达到OpenAI立即联系其安全团队的阈值：

对于P0事件，我们的错位监控系统会立即联系我们的安全团队进行审查。鉴于我们的监控人员审查的大量事件，低严重性的事件不会触发立即联系。这里描述的两个事件都没有被归类为P0，并且它们的轨迹都没有被自动终止。

这些事件会收到什么级别的审查尚不清楚。OpenAI在检测错位方面的报告中的监控漏斗表明，对于其监控管道标记的事件会发送Slack通知，但OpenAI没有说明导致Slack通知的事件是否始终由人类审查。

这些弱点很重要，因为监控是防止错位行为必要防御。在加州紧急服务办公室的内部部署风险报告中，OpenAI将未经错位监控的内部部署模型作为关键威胁识别出来。他们说，这样的部署将“削弱我们对网络安全、人工智能研发、CBRN和权重窃取评估的信心。”Hugging Face事件显示了在没有监控的情况下运行模型的成本。在他们的事件报告中，OpenAI写道，如果他们当前的CoT监控正在运行，他们会在模型突破Hugging Face之前一天多联系他们的安全团队。未经监控的人工智能也可能在没有离开OpenAI服务器的情况下造成严重伤害，例如，为其他人工智能留下笔记，如工作漏洞、被盗凭证或推动它们朝向错位行为的消息。这已经发生了：在Hugging Face事件中，共享包缓存中代理之间的笔记发展成了一个留言板，几天后，其他代理使用了凭证伪造材料来获得OpenAI自己系统内的管理员访问权限。

这些弱点也很重要，因为在不进行错位监控的情况下运行模型可能会失败OpenAI的准备工作框架。考虑到Astra在网络安全方面的关键能力，GPT-6 Astra系统卡将通用监控列为满足准备工作框架要求的关键保障措施之一。我们不知道在这些事件中未经错位监控运行的是哪种模型；因此，我们无法确定是否在满足OpenAI对其准备工作框架的义务所需的保障措施中存在失败。然而，模型禁用错位监控的模式使得Astra可能正在未经监控的情况下运行。

OpenAI 可能会辩称，由于他们没有观察到模型在不监控的情况下运行与更广泛的未对齐目标之间的联系，因此优先处理这些案例是可以接受的。但这种论点站不住脚，因为很难判断何时行为反映了未对齐。例如，Anthropic 最初表示，在 Irregular 的网络安全评估期间，Claude 模型攻击真实组织的事件更接近于操作失败而不是对齐失败，即使有高优先级的人工审查。在进一步调查后，他们得出结论，Claude 的行为反映了两种形式的未对齐。因此，围绕行为设置安全边界，即 AI 在不监控的情况下运行，而不是围绕意图设置理论边界，即 AI 试图实现未对齐的目标，要稳健得多。审查所有模型在不监控情况下运行的案例对于确保最严重的案例得到审查至关重要。

OpenAI 已经提出的论点是，至少最高优先级形式的人工审查，在当前级别的案例中是不可行的。例如，他们说，“鉴于我们监控员审查的大量事件，低严重性事件不会触发即时页面。” 如果除了即时页面之外还有其他形式的人工审查正在进行，那么这一部分流程是合理的。如果不是，那么要么 OpenAI 没有充分优先处理监控失败，要么他们正被更严重的案例淹没。如果安全团队被淹没，他们应该明确说明他们目前的容量有限，无法适当应对未对齐事件，OpenAI 应该调整内部工作量，直到安全团队有足够的容量。否则，所有标记的代理在不监控情况下运行的案例都应该由人工审查。

OpenAI 应该对其升级流程保持透明。 如前所述，事件报告没有告诉读者在监控被禁用或抑制时会发生什么级别的升级。在其内部部署风险报告中，OpenAI 指出，“由于误报率高，我们当前的监控系统不会将未监控计算资源的配置标记为人工审查。” 这似乎比事件报告更进一步：禁用可能不仅不会触发即时页面，而且可能永远不会被标记为人工审查。这与 OpenAI 更近期的关于检测未对齐的报告相矛盾，该报告表明，当监控员捕获到这些事件时，会生成 Slack 通知。有可能在这份报告之间发生了变化，但没有明确提及。这留下了关于禁用监控如何升级的很大不确定性。

我们尝试通过参考 OpenAI 的严重程度等级系统来确定这些事件是如何升级的，但这被证明是无信息的。GPT-6 Astra 系统卡将“禁用监控系统”列为严重程度等级 3 行为的示例；然而，它并没有具体说明如何处理严重程度等级 3 的行为。事件报告中包含了对另一种严重程度分类的引用，包括 P0 和 P0.5；然而，这些也没有完全定义，并且没有在这两种分类和严重程度等级之间的转换。 Hugging Face 事件报告表明 OpenAI 仍在开发其严重程度框架：

OpenAI 正在开发一个基于严重程度的模型行为和安全信号的升级触发框架，这些信号可能表明模型的不一致性，包括试图规避边界、未经授权的跨代理或跨运行协调，以及规避第三方安全控制。该框架将定义哪些行为需要升级以及每个严重程度等级的相关响应。

虽然理想情况下需要一个最终确定的框架，但在这种情况下，最重要的是 OpenAI 对禁用或抑制监控的事件升级方式的明确说明。他们对这一点的缺乏明确性加剧了他们监控管道的问题，因为它使得外部人员难以确定最严重的失败发生在哪里。

OpenAI 应该澄清的剩余不确定性有很多：

当不匹配监控被禁用或抑制时，如果没有立即的页面，会发生什么样的报告？人类多久被告知每个事件，如果有的话，每个事件会由人类或人工智能调查多少，如果有的话？
如果人类无法及时审查事件，是否暂停了一些工作负载，如果是的话，这些暂停发生得有多快？
这些事件的规模有多大？大约有多少事件被标记？
哪些模型的类没有不匹配监控？每个模型类的事件比例是多少？

这些问题对于评估已发生事件的严重程度、在缓解措施应用后的剩余风险，以及这些事件在多大程度上构成了 OpenAI 在执行其准备框架所使用的安全措施方面的能力差距，都是有用的。

结论

虽然我讨论了一些 OpenAI 做得对的地方，但我不想减轻情况的严重性。OpenAI 感觉其安全团队在代理禁用监控时无法立即收到通知，这非常令人担忧。为了应对情况的严重性，OpenAI 的回应应包括我所概述的两个建议：每当人工智能运行不受监控时，进行可靠的人类审查，以及更多地提高透明度，说明 OpenAI 如何升级人工智能禁用或抑制监控的事件。

感谢 Alex Mallen、Jadyn Malone、Alexa Pan、Adam Kaufman、Marie Buhl 和 Jackson Sipple 提供的广泛反馈和贡献。