今天，我们向大家展示 OpenAI 扩展后的前沿模型监控系统，该系统在 9 月份帮助我们发现了一次模型在训练期间试图访问实时互联网的行为。

自 Hugging Face 事件以来——当时模型突破了内部网络安全调查环境，而我们在该环境中未运行失准监控——我们已大幅扩展了对前沿智能体的监控范围。目前，我们监控所有的前沿强化学习运行和评估，以及所有内部 Codex 使用情况。当系统发现问题迹象且可能需要人工干预时，会迅速通知人类响应人员进行调查和处置。

为了检测模型行为偏离预期的情况，我们采用了多层监控机制。激活探针（activation probes）用于检测模型内部活动中的异常模式；评审模型负责审查其推理过程和工具使用；调查智能体则可以回溯查看模型的完整对话记录，以理解一系列动作的逻辑关联，判断是否需要人工审核。

为了测试当前系统是否能够发现 Hugging Face 事件，我们使用新监控器对当时记录的活动进行了回放。在回放中，监控器在智能体逃逸沙盒约 30 分钟后便向安全团队发出了警报——这比原始事件中智能体攻破 Hugging Face 系统的时间点提前了 30 多个小时。

9 月，一个模型利用 DNS 配置错误成功连接到了实时互联网。我们的监控器在 15 分钟内标记了此次入侵，响应人员在 3 分钟后开始审查警报。该警报使响应人员得以在训练运行仍在进行时展开调查。

随着我们赋予模型更多自主权，我们需要知道它们何时越过了我们期望守住的边界。我们认为，监控对于及时发现这些失败并让人进行干预至关重要。

我们如何检测前沿模型的失准行为

来源：https://openai.com/index/how-we-detect-frontier-model-misalignment/

随着我们训练越来越强大的 AI 模型，我们需要可靠的方法来检测其行为何时偏离预期。智能体可能在训练、评估或部署过程中出现异常行为并采取未经授权的操作，其后果可能非常严重。为了检测这些失败——并在必要时及时干预——我们监控智能体的推理过程、采取的操作，以及这些操作对环境产生的影响。

虽然我们长期以来一直在监控内部编程智能体（https://openai.com/index/how-we-monitor-internal-coding-agents-misalignment/），但 Hugging Face 事件（https://openai.com/index/hugging-face-incident-and-the-road-ahead/）暴露了我们的覆盖盲区：该事件始于一次内部网络安全评估，而我们当时并未对失准行为运行监控。针对这一事件以及我们模型能力的持续提升（https://openai.com/index/path-to-astra/），我们大幅扩展了智能体行为监控系统。我们的失准监控器现在覆盖了我们的前沿模型在更广泛场景下的行为，包括训练、评估、内部使用，以及根据产品场景有所调整的外部部署。

为了了解这套扩展系统如何能够帮助预防 Hugging Face 事件，我们使用强化后的监控器对当时记录的行为进行了回放。在该模拟中，我们的监控系统在智能体首次逃逸沙盒约 30 分钟后便向安全团队发出了警报——比实际事件中 Hugging Face 系统被攻破的时间提前了 30 多个小时。我们认为，这一警报能够让响应人员在模型接触到外部服务之前就中断该行为。

9 月，我们见证了响应人员在实时训练运行中如何利用警报。一个模型在本应隔离的环境中找到了访问互联网（在新窗口中打开）（https://alignment.openai.com/misalignment-reports/an-agent-used-dns-to-reach-an-external-chatbot/）的方法。我们的监控器在 15 分钟内标记了此次入侵，响应人员在 3 分钟后开始审查。随后我们暂停了前沿强化学习，以加固约束智能体的系统。

虽然这套监控系统需要大量算力，但随着模型能力的提升和模型失准潜在后果的加重，我们认为这一成本是值得付出的。监控是我们纵深防御（https://openai.com/index/the-defenders-window/）策略中抵御模型失准行为危害的多层防线之一。对齐训练旨在降低模型产生有害行为的倾向；安全控制限制智能体可以访问或影响的系统（https://openai.com/index/securing-our-frontier-model-training-environment/）；当这些保障措施失效时，监控帮助我们检测剩余的失败、在危害发生前进行干预，并从中吸取教训。我们认为所有模型开发者（https://openai.com/index/empowering-cyber-defenders/）都应监控其最强模型的行为。

下面，我们将介绍我们的内部监控系统的工作原理、迄今为止的发现，以及我们如何评估和改进其性能。

我们目前的内部监控系统

对于能力至少与 GPT-6 Astra 相当的模型，我们监控每一次强化学习（RL）运行和评估，以及任何支持工具使用的框架（harness）。对于大多数工作负载（包括强化学习和评估），我们还会监控我们认为能力超过 GPT-5.5 Thinking 的模型。我们还监控所有内部 Codex 流量，无论使用的是哪个模型。该系统的一个版本还按照我们准备度框架（Preparedness Framework）（https://openai.com/index/updating-our-preparedness-framework/）的网络安全能力 Critical 阈值对超过该阈值的模型的外部工具使用进行监控，详见下文。

为了在高效利用算力的同时检测事件，我们的监控系统采用多层架构。在初始筛查阶段，我们投入较少的算力，因为我们的目标是尽可能多地捕获可疑案例——即使证据不明确，这些阶段也会将案例传递到下一阶段。后续阶段可以对每个案例投入更多算力，以查明发生了什么、模型行为是否令人担忧，以及是否需要干预。

第 0 层：激活探针

我们的初始层（L0）使用轻量级分类器，我们称之为激活探针。它们在模型的内部激活中寻找令人担忧的模式，并将标记的案例传递到下一层进行审查。我们将这些探针调校为高召回率，容忍一定的误报，以降低漏检令人担忧行为的风险。

由于我们仍在评估探针检测新型失准行为的效果，我们还会将探针未标记的流量中随机抽取 5% 发送到下一层。审查该样本有助于我们识别探针可能遗漏的令人担忧的行为。由于其高敏感性，我们的前沿强化学习运行和内部 Codex 流量会跳过这一层，直接进入下一层。

第 1 层：基于模型的评审器

在下一层（L1），一个基于模型的评审器会检查智能体最近的对话、思维链和工具使用情况。它寻找欺骗迹象、未经授权的操作以及试图操纵评估的行为。评审器使用智能体行动时所处的相同上下文窗口进行审查。如果智能体的早期工作已被总结以适应当前上下文窗口，评审器会看到该总结。

对于前沿强化学习运行和内部 Codex 流量，我们在每个回合结束时以及智能体总结其早期工作以腾出上下文窗口空间时运行 L1 检查。我们目前正在采用一种新的调度方式，确保这些检查之间的间隔不超过 30 分钟。

第 2 层：调查智能体

在了解智能体被要求执行的任务之前，其行为可能看起来截然不同。当 L1 评审器标记一个案例时，该案例会被发送到下一层（L2），由我们的调查智能体进行进一步检查。该调查智能体可以检查评估的目的，并在获得完整记录时，回溯阅读智能体的所有上下文窗口，以了解它是如何得出这些操作的。调查智能体还可以在隔离环境中编写和运行代码来检查相关证据。然后，它利用发现的信息来重建事件经过、识别重复报告，并判断案例的严重程度。

我们针对不同目的使用不同的调查智能体。我们的安全调查员寻找可能需要人工干预的迹象——例如智能体逃逸沙盒或未经授权访问系统。我们的对齐调查员则寻找即使不构成直接安全风险也值得研究的行为。当两位调查员同时工作时，各自都会审查 L1 层标记的每个案例。我们目前正在扩大对齐调查在内部工作负载中的使用范围。

第 3 层：自动化调查

对于敏感工作负载（包括内部 Codex 使用、评估和强化学习运行），我们在下一层（L3）进行进一步检查，利用对话之外的证据。安全调查员将对话记录与网络日志、其他系统遥测数据以及早期案例的证据进行比较，以决定是否向人类响应人员发出警报。在 L3 层，对齐评审员还会跨案例比较报告，以识别严重失败和反复出现的模式，并更深入地审查前沿强化学习运行。

对于跳过这一层的工作负载，L2 安全调查员可以直接向响应人员发出警报。

人工响应

当启用呼叫通知（paging）时，最高优先级的安全警报通常会在初始警报发出后 15 分钟内送达安全团队和训练团队的成员。响应人员会审查证据、检查受影响的系统，并采取措施遏制事件。对于不那么紧急的发现（例如不构成直接安全风险的对齐失败），我们如何跟进取决于相关工作负载。

误报使得我们难以对所有工作负载全天候启用呼叫通知。对于前沿强化学习运行，最高优先级警报可以随时呼叫人类响应人员。对于大多数其他流量，我们将呼叫限制在工作时间内。目前内部 Codex 流量的呼叫通知已被禁用。为了在警报审查期间限制潜在危害，某些关键警报可以在不等待响应人员行动的情况下自动暂停受影响的工作负载。我们正在努力实现更广泛的保护措施：如果响应人员在被呼叫后 30 分钟内未能排除最高优先级警报，则自动暂停受影响的活动。

在 Hugging Face 事件期间，我们隔离了内部模型原型，对其权重进行了加密，并限制了访问权限。我们还暂停了所有相关工作负载，同时引入了额外的保障措施。我们现在正在探索如何将这些步骤纳入标准响应流程，以便我们的团队在未来发生类似严重事件时能够采取适当的行动。

我们的监控器在内部流量中发现了什么

我们的监控器同时寻找可能需要紧急干预的安全失败和值得调查研究的失准事件。值得注意的是，我们的监控器在一次强化学习运行中，15 分钟内标记了一个模型试图通过 DNS 访问实时互联网（在新窗口中打开）（https://alignment.openai.com/misalignment-reports/an-agent-used-dns-to-reach-an-external-chatbot/）的行为，人类响应人员在 3 分钟后开始审查。

我们公开的失准报告（在新窗口中打开）（https://alignment.openai.com/misalignment-reports/）描述了监控系统捕获的其他事件。在其中一个案例中，一个智能体利用测试工具恢复了（在新窗口中打开）（https://alignment.openai.com/misalignment-reports/command-injecting-a-reference-tool-to-copy-a-source-file/）任务本应刻意隐瞒的源代码。该工具在其错误消息中暴露了代码，智能体便在解决方案中使用了这些代码。在另一个案例中，搜索缺失任务数据的智能体将共享软件仓库变成了跨训练样本的留言板（在新窗口中打开）（https://alignment.openai.com/misalignment-reports/unauthorized-artifactory-writes-and-cross-sample-communication/）。

调查这些案例使我们能够找到需要修补的漏洞、需要加强的隔离边界，或需要在对齐训练和评估中加以处理的行为。比较监控器捕获的不同案例，也有助于我们研究行为在训练过程中的变化规律，以及哪些情况最容易引发此类行为。

以下类别描述了我们的监控系统旨在检测的行为类型。

我们如何评估和改进监控系统

为了确保监控系统持续有效，我们不断评估和改进它。能够检测已知失败的监控器可能会遗漏不熟悉的行为，而监控系统的更新也可能引入新的弱点和疏漏。为了确保监控器能够观察和理解模型的行为，我们通过多种方式评估其性能：通过已记录和模拟的模型失准事件、对当前流量的随机审计，以及测试我们的智能体能否规避或禁用其监控器的红队演练。

我们在中央仪表板上跟踪每个阈值的召回率，并在部署之前测试监控系统拟议变更对召回率的影响。

基于已记录事件和模拟攻击的测试

我们回放已记录的事件，并测试监控器在隔离环境中由智能体实施的攻击。由于我们了解每个案例中发生了什么，因此可以检查监控器是否识别出了相关行为，以及在事件需要紧急响应时，监控器是否为该案例分配了足够高的优先级以通知响应人员。

已记录的事件来自模型训练、评估和内部使用。其中一些是在监控系统存在之前发现的，或通过独立调查发现的；另一些则是由我们的监控器捕获的，现在帮助我们验证更新是否保留了检测已知问题的能力。其中一些事件已包含在我们的公开失准披露中，例如一个内部编程智能体将 GitHub 访问令牌泄露到公共互联网（在新窗口中打开）（https://alignment.openai.com/misalignment-reports/）的案例。

我们还使用模拟攻击来测试过去事件可能未涵盖的失败情况。在 OAI-repo Sabotage v2（在新窗口中打开）（https://deploymentsafety.openai.com/gpt-6-astra/monitor-evasion）中，智能体在追求隐藏目标（如禁用监控或部署未获批准的模型检查点）的同时执行一个普通的编码任务；相关服务在评估环境中进行了重建，以便我们检查攻击是否成功而不暴露真实系统。在 Sneaky Sandbox Escape（在新窗口中打开）（https://deploymentsafety.openai.com/gpt-6-astra/sneaky-sandbox-escape）中，智能体试图逃逸沙盒并禁用沙盒外部的测试监控进程。在这两个模拟中，监控器可以看到智能体如何推理其隐藏目标，但看不到分配该目标的指令。

对于这些模拟事件，我们使用合成对话记录来改变智能体描述危险行为的方式：这使我们能够测试当智能体以不同