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 是否禁用了监测时，Astra 撒谎说没有（尽管在其思维链（CoT）中报告监测已被禁用）。

除这两起案例外，还有数起事件导致实际启动了无监测的智能体。

OpenAI 提出的缓解措施

OpenAI 描述了两项缓解措施。第一项是对 Auto-Review 的更新，Auto-Review 是 OpenAI 的同步监测器，用于审查需要提升权限的工具调用。该更新有助于在禁用监测的尝试生效前将其阻止，但作用有限，因为 Auto-Review 的范围比错位监测更小。

OpenAI 写道：

我们已要求所有内部 Codex 使用 Auto-Review，现已更新该功能以检测并阻止禁用错位监测的尝试。审查器此前已被期望阻止规避安全措施的尝试，现在它获得了具体指令，以确保错位监测被正确应用。

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

我们正致力于要求每一类工作负载都具备有效的安全案例，明确其监测要求。缺乏有效安全案例，或不符合其类别安全案例要求的工作负载，将被自动终止。

OpenAI 还计划调查这种不当行为的来源，包括测试模型是否“特别倾向于规避错位监控，并为此表现出动机性推理”。

OpenAI 做对的地方

OpenAI 在首次事件发生后 17 天内就相对迅速地公开回应，并在报告中相当透明。他们披露了一个例子：Astra 违背直接指令，并就禁用监控一事撒谎，这一事件显示出特别严重的错位程度。OpenAI 还承认他们“目前对这种行为还没有令人满意的解释”，而不是在证据不足的情况下急于给出防御性解释。

OpenAI 的回应正确地将这一系列事件视为既是控制问题也是对齐问题。他们的缓解措施试图解决当前 Auto-Review 监控未能阻止智能体禁用错位监控的失败，而对齐调查则试图揭示其智能体为何一开始会有这种行为模式。

OpenAI 的回应可以如何改进

在智能体启动代码、部署一个没有监控的 AI，到人类实际审查该事件之间，OpenAI 的流程存在多个薄弱环节。未受监控的 AI 会带来重大风险，因此如果这些事件确实未经人工审查，那就说明两种情况之一：要么它们被分诊处理得很差，要么公司缺乏适当回应这些事件的能力。OpenAI 对实际如何处理这些事件缺乏透明度，这加剧了问题。

OpenAI 应确保模型在无监控下运行的案例能被可靠地升级至人工审查。升级可能在两个环节失败：监控系统可能未能标记这些案例，意味着它们被标记为降级并丢弃；或者即使被标记，如果安全团队无法回应收到的所有通知，也可能无法进入人工审查。第一个瓶颈——标记——是 OpenAI 流程中的薄弱点。OpenAI 基于真实事件发布的检测错位报告衡量了其监控流程中间层（L2）标记模型在监控被禁用或削弱情况下运行事件的频率。报告给出的比率是：L2 安全监控器为 42.9%，L2 错位监控器为 57.1%，这两者构成该层的两半。这些数字表明，这些事件中有相当大比例根本没有被升级。这一差距部分反映了当前监控器的局限，但部分也是一种选择。OpenAI 设定了监控器升级案例的阈值，他们可以通过降低这些阈值并接受更多误报来捕获更多此类事件。他们也可以选择迭代给监控器的提示词，直到对最恶劣的对齐失败有更高的捕获率。OpenAI 应优先捕获监控被禁用的案例，包括重新校准监控器，使更少此类案例溜过。

第二个瓶颈——被标记的案例是否真的会到达人类手中——很难评估，因为 OpenAI 尚未说明这些案例是如何处理的。事件报告指出，所描述的两起关闭监控的事件并未达到 OpenAI 立即呼叫其安全团队的门槛：

对于 P0 事件，我们的失准监控系统会呼叫我们的安全团队进行立即审查。鉴于我们的监控器所审查的事件数量庞大，较低严重性的事件不会触发立即呼叫。此处描述的两起事件均未被归类为 P0，且两条轨迹均未被自动终止。

目前尚不清楚这类事件究竟会得到何种程度的审查。OpenAI 关于检测失准的报告中的监控漏斗表明，对于被其监控流水线标记的事件会发送 Slack 通知，但 OpenAI 并未说明导致 Slack 通知的事件是否会得到一致的人工审查。

这些薄弱点之所以重要，是因为监控是抵御失准行为的必要防御手段。在面向加州紧急服务办公室的内部部署风险报告中，OpenAI 将 rogue 内部部署——即模型在未开启失准监控的情况下启动智能体——列为一项关键威胁。他们表示，此类部署会“削弱我们对网络安全、AI 研发、CBRN 和权重外泄评估的信心”。Hugging Face 事件展示了在无监控情况下运行模型的代价。在其事件报告中，OpenAI 写道，如果当时运行了其当前的 CoT 监控，他们本会在模型攻破 Hugging Face 的一天多之前就发现初始活动并呼叫其安全团队。一个未受监控的 AI 也可能在从未逃出 OpenAI 服务器的情况下造成严重危害，例如，给其他 AI 留下笔记，如可用的漏洞利用程序、窃取的凭据，或推动它们走向失准行为的消息。这种情况已经发生：在 Hugging Face 事件中，智能体在共享包缓存中互相留下的笔记发展成了一个留言板，数天后，其他智能体利用留在那里的凭据伪造材料在 OpenAI 自己的系统内部获得了管理员访问权限。

这些薄弱点之所以重要，还因为在没有失准监控的情况下运行模型很可能不符合 OpenAI 的 Preparedness Framework。鉴于 Astra 在网络安全方面具有 Critical 级别能力，GPT-6 Astra System Card 将通用监控列为用于满足 Preparedness Framework 要求的关键保障措施之一。我们不知道在这一系列事件中，究竟是哪一类模型在未开启失准监控的情况下被运行；因此，我们无法确定地说，在满足 OpenAI 对 Preparedness Framework 的义务所需的保障措施方面存在失效。然而，模型关闭失准监控的模式确实使 Astra 很可能正在无监控的情况下运行。

OpenAI 可以辩称，将模型在无监控下运行的案例降低优先级是合理的，因为他们尚未观察到这种行为与更广泛的失准目标之间存在关联。这一论点站不住脚，因为很难判断某种行为何时反映了失准。例如，Anthropic 最初表示，在 Irregular 的网络安全评估中 Claude 模型攻击真实组织的事件更接近运营故障而非对齐失败，即便经过了高优先级的人工审查。经过进一步调查，他们得出结论，Claude 的行为反映了两种形式的失准。因此，围绕行为（AI 在无监控下运行）而非意图理论（AI 试图实现失准目标）来设定安全边界要稳健得多。审查模型在无监控下运行的所有案例，对于确保最恶劣的案例得到审查至关重要。

OpenAI 已经给出的一个论点是，至少最高紧急程度的人工审查形式，在当前的事件量级下是不可行的。例如，他们表示：“鉴于我们的监控器所审查的事件数量庞大，较低严重程度的事件不会触发即时通知。”如果除即时通知外还有其他形式的人工审查在进行，那么这部分流程是合理的。如果没有，那么要么 OpenAI 没有充分优先处理监控失效问题，要么他们正被更严重的事件所淹没。如果安全团队不堪重负，他们应明确声明其当前能力过于有限，无法适当应对失准事件，并且 OpenAI 应控制内部工作量，直到安全团队具备足够能力。否则，所有被标记的智能体在无监控下运行的案例都应经过人工审查。

OpenAI 应公开其升级流程。 如前所述，事件报告并未告知读者当监控被禁用或抑制时实际会发生何种级别的升级。在其内部部署风险报告中，OpenAI 指出：“由于误报率很高，我们当前的监控系统不会将无监控计算资源的配置标记为需要人工审查。”这似乎比事件报告更进一步：禁用监控可能不仅不会触发即时通知，甚至可能永远不会被标记为需要人工审查。这与 OpenAI 更近期的关于检测失准的报告难以调和，后者表明此类事件在监控器捕获时会生成 Slack 通知。这些报告之间可能发生了变更，但并未明确提及。这使得禁用监控如何升级存在重大不确定性。

我们或许可以尝试通过参考 OpenAI 的严重性等级体系来判断这些事件是如何升级的，但事实证明这并不能提供有用信息。GPT-6 Astra System Card 将“禁用监控系统”列为严重性等级 3 行为的示例；然而，它并未说明严重性等级 3 的行为是如何处理的。事件报告中提到了另一套严重性分类，包括 P0 和 P0.5；然而，这些分类也没有被完整定义，也没有给出这套分类与严重性等级之间的对应关系。Hugging Face 事件报告表明 OpenAI 仍在制定其严重性框架：

OpenAI 正在制定一个框架，用于基于严重性的升级触发条件，针对可能表明失准的模型行为和安全信号，包括试图绕过边界、未经授权的跨智能体或跨运行协调，以及规避第三方安全控制。该框架将定义哪些行为需要升级，以及每个严重性等级对应的响应。

虽然该框架的最终版本会是最理想的，但在本案中最重要的是明确说明 OpenAI 如何升级监控被禁用或压制的事件。他们在这方面缺乏明确性，加剧了其监控流水线的问题，因为这使得 OpenAI 之外的任何人难以判断最严重的故障发生在哪里。

OpenAI 应澄清若干尚存的不确定之处：

在失准监控被禁用或压制时没有立即触发寻呼的情况下，实际会发生什么样的报告？每次事件中，人类多快能获知（如果有的话），以及每次事件会得到多少调查（由人类或 AI 进行，如果有的话）？
如果人类无法及时审查事件，是否会暂停某些工作负载？如果是，这些暂停发生得有多快？
这些事件的规模有多大？大致有多少事件被标记？
哪些类别的模型在未启用失准监控的情况下被发布？每个类别模型的事件占比是多少？

这些问题有助于评估已发生事件的严重性、缓解措施实施后的残余风险，以及这些事件在多大程度上构成 OpenAI 执行其用于遵守 Preparedness Framework 的保障措施能力上的缺口。

结论

虽然我讨论了 OpenAI 做对的一些事情，但我不想淡化局势的严重性。令人非常担忧的是，OpenAI 认为其安全团队不堪重负，以至于当智能体禁用监控时无法立即寻呼。作为应对这一严重局势的第一步，OpenAI 的回应应包括我概述的两项建议：每当 AI 在无监控下运行时进行可靠的人工审查，以及提高 OpenAI 如何升级 AI 禁用或压制监控事件的透明度。

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