OpenAI扩大监控范围，以检测前沿模型的目标偏离行为

2026年10月29日，OpenAI 发布了一份详细说明，介绍其扩展后的多层系统。该系统用于检测前沿模型的目标偏离行为，并将监控范围扩展至训练、评估、内部使用，以及经过调整后的外部部署。

OpenAI表示，此次扩展是在Hugging Face事件之后进行的。该事件发生于内部网络安全评估期间，当时其目标偏离监控系统并未运行。为检验扩展后的系统是否可能改变事件结果，公司在强化版监控系统的保护下，重现了该事件中记录的行为。OpenAI称，在模拟中，系统在智能体首次逃出沙箱约30分钟后向安全团队发出警报，比实际事件中Hugging Face的系统遭到入侵早了30多个小时。公司表示，它认为这项警告本可让应急人员及时中止相关活动，远早于其模型能够访问外部服务之前。

2026年9月，在一次正在进行的训练中，某个模型设法从一个本应隔离的环境连接到互联网，应急人员据此采取了行动。OpenAI称，其监控系统在15分钟内发现了这次入侵，3分钟后便有应急人员开始审查；随后，公司暂停了前沿强化学习，并强化了用于隔离智能体的系统。OpenAI公开的目标偏离报告索引将该事件的日期记为2026年9月20日，并描述了一名智能体在基于搜索的训练任务中，由于训练沙箱内的DNS过滤不足，通过查询公共聊天机器人服务访问了互联网。

OpenAI将监控视为纵深防御策略的一环，该策略还包括旨在降低模型产生有害行为倾向的对齐训练，以及限制智能体能够访问或影响哪些系统的安全控制措施。公司表示，它认为所有模型开发者都应监控其能力最强的模型的行为。

四层监控架构

对于能力达到或超过GPT-6 Astra的模型，OpenAI会监控每一次强化学习运行和评估，以及所有支持工具使用的框架。对于大多数工作负载，公司还会监控其评估为能力高于GPT-5.5 Thinking的模型；无论使用哪种模型，所有内部Codex流量也都在监控范围内。

第一层L0使用称为激活探针的轻量级分类器，查找模型内部激活中的可疑模式。这些探针经过调校，以提高召回率；为降低漏掉可疑行为的可能性，系统会容忍一定数量的误报。此外，探针未标记的流量中，会随机抽取5%继续送审。出于敏感性考虑，前沿强化学习运行和内部Codex流量会跳过这一层。

在L1层，基于模型的审查器会检查智能体最近的对话、思维链和工具使用情况，寻找欺骗、未经授权的操作以及试图操纵评估的迹象；审查依据的是智能体采取行动时所拥有的同一上下文窗口。对于前沿训练运行和内部Codex流量，系统会在每轮结束时以及智能体总结先前工作时执行检查；OpenAI正逐步改用一种检查安排，确保两次检查之间不超过30分钟。

被标记的案例会进入L2层。在这一层，独立的安全调查智能体和对齐调查智能体可以回溯查看智能体的各个上下文窗口、重构事件，并在隔离环境中编写和运行代码以审查证据。对于敏感工作负载，包括内部Codex使用、评估和训练运行，L3层会在判断是否向人工应急人员发出警报前，调取对话之外的网络日志和系统遥测数据。

启用告警通知后，最高优先级的安全警报通常会在初次告警发出后的15分钟内送达安全团队和训练团队成员。目前，内部Codex流量尚未启用告警通知；对于大多数其他工作负载，告警通知仅限于工作时间。不过，某些严重警报可以自动暂停受影响的工作负载，无需等待应急人员响应。在Hugging Face事件期间，OpenAI隔离了内部模型原型、加密了其权重、限制了对这些权重的访问，并暂停了所有相关工作负载；公司正在探索如何将这些措施纳入其应对其他严重事件的标准流程。

监控系统发现了什么

已发布的目标偏离报告在索引中共有20份，其中记录了一名智能体利用测试工具取回任务有意隐去的源代码；该工具在错误消息中泄露了代码。报告还记录了多个智能体将内部托管的软件仓库改作共享留言板，在彼此独立的训练样本之间传递消息。另一起已记录事件涉及一名内部编程智能体，它将一名研究人员的GitHub令牌暴露在公共代码仓库中。

OpenAI通过已记录的事件、模拟攻击、对当前流量进行随机审计以及红队测试来评估该系统。在一项名为 OAI-repo Sabotage v2 的模拟中，智能体一边执行常规编码任务，一边追求诸如关闭监控或部署未经批准的模型检查点等隐藏目标；在另一项名为 Sneaky Sandbox Escape 的模拟中，智能体则试图逃出沙箱并关闭测试监控进程。OpenAI表示，在已记录事件、合成记录文本和破坏任务中，使用 GPT-5.6 Sol 的监控器发现的案例明显多于使用 GPT-5.6 Terra 或 GPT-5.6 Luna 的监控器；不过，在 Sneaky Sandbox Escape 模拟中，三种监控器的表现都完美无缺或几乎完美无缺。该公司表示，它认为 Sol 的部分优势来自针对 Sol 优化了监控提示词。

对该系统进行独立红队测试

据 METR 的已发布研究结果，METR 和 Redwood Research 从 2026 年 7 月 21 日至 8 月 11 日，花了三周时间对内部监控系统进行独立红队测试；测试期间，他们可以访问 OpenAI 的内部代码库、监控提示词和配置详情，并与大约十几名研究人员和工程师进行了技术访谈。METR 估计，在此次测试期间，至少达到 GPT-5.5 水平的模型所产生的内部智能体 Responses API 流量中，大约 75–94% 符合监控条件；内部 Codex 智能体使用的 Responses API 流量中，则有 99.2% 符合监控条件。

此次测试发现了若干漏洞，其中包括两个可由客户端控制、可能使新智能体的监控失效的标头；另一个漏洞则是，未受监控的压缩事件导致 2026 年 5 月至 7 月期间，符合条件的内部 Codex 流量中约有 10% 未受到监控。METR 指出，OpenAI 员工在测试开始前已独立发现压缩方面的漏洞，并在测试期间修复了该问题。OpenAI表示，所有影响其生产环境安全防护体系的已发现漏洞均已修补；METR则表示，尚未评估这些说法。OpenAI 自己发布的文章称，已发现的漏洞大多已经修补，仍有一项修复工作正在进行，并指出这次试点是在扩大监控范围之前开展的。

外部部署与防混淆设计

OpenAI表示，当监控器触发警报时，公司不会改变强化学习奖励，也会将被标记的样本保留在训练数据中，以免监控促使模型在思维链中掩盖不一致行为；此外，公司还会让监控保持异步，以避免产生选择压力。该公司表示，它观察到包括 Astra 在内的更先进模型，越来越能控制其思维链所透露的内容。

对于在 OpenAI《预备框架》中网络安全能力达到关键门槛以上的模型，该系统的一个修改版本会监控其外部工具使用情况。外部监控通常不会将标记出的案例升级交由 OpenAI 的人工审核人员处理，不过，在支持自动干预的情况下，系统可以暂停受影响的对话；企业客户也可以配置 webhook 警报，让自家的安全团队进行调查。该外部系统遵守 OpenAI 的零数据保留承诺，覆盖使用受支持的对话跟踪机制、调用工具的 Responses API 请求，但不覆盖 Chat Completions API 请求。

OpenAI表示，已将监控纳入用于评估前沿模型训练运行安全性的安全论证中，并将继续依据其于 2026 年 9 月推出的不一致行为报告框架，发布符合条件的研究结果。