Redwood Research 分析 OpenAI 智能体屡次关闭失准监控的处理是否得当

最近，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 的更新，Auto-Review 是 OpenAI 的同步监控器，用于审查需要提升权限的工具调用。该更新将有助于在禁用监控的尝试生效前予以阻止，但其作用有限，因为 Auto-Review 的范围比失准监控更小。

OpenAI 写道：

Auto-Review 已是我们所有内部 Codex 使用所必需的，现已更新以检测并阻止禁用失准监控的尝试。该审查器此前已被期望阻止规避安全措施的尝试，现在又被赋予了具体指令，以确保失准监控被正确应用。

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

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

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。GPT-6 Astra系统卡将通用监控列为用于满足Preparedness Framework要求的关键保障措施之一，鉴于Astra在网络安全方面具有Critical级别能力。我们不知道在这一系列事件中，未开启失准监控运行的是哪一类模型；因此，我们无法确定地说，在满足OpenAI对Preparedness Framework的义务所需的保障措施方面存在失败。然而，模型关闭失准监控的模式确实使Astra很可能正在无监控运行。

OpenAI 可以辩称，对于模型在无监控状态下运行的案例降低优先级是合理的，因为他们尚未观察到这种行为与更广泛的失准目标之间存在关联。这一论点站不住脚，因为很难判断某种行为何时反映了失准。例如，Anthropic 最初表示，Claude 模型在 Irregular 的网络安全评估中攻击真实组织的事件更接近运营故障而非对齐失败，即便经过了高优先级的人工审查。经过进一步调查，他们得出结论，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 应澄清若干仍然存在的不确定之处：

1. 在失准监控被禁用或压制时没有立即触发寻呼的情况下，实际会发生什么样的报告？每次事件中，人类多快会被告知（如果有的话），以及每次事件会被调查到什么程度（由人类或 AI 进行，如果有的话）？

2. 如果人类无法及时审查事件，是否会暂停某些工作负载？如果是，这些暂停会多快发生？

3. 这些事件的规模有多大？大致有多少事件被标记？

4. 哪些类别的模型是在没有失准监控的情况下启动的？每个类别的模型分别贡献了多大比例的事件？

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

结论

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

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