OpenAI 扩展失准监测体系，覆盖训练、评估与外部部署

OpenAI于2026年10月29日详细公布了其扩展后的多层系统，用于检测其前沿模型中的失准行为，将监测范围扩展至训练、评估、内部使用，并在经过修改后延伸至外部部署。

OpenAI表示，此次扩展是在Hugging Face事件之后进行的，该事件始于内部网络安全评估期间，当时其失准监测器并未运行。为测试扩展后的系统是否本可改变这一结果，公司用强化后的监测器重放了该事件中记录的行为。OpenAI报告称，在模拟中，系统在智能体首次逃出其沙箱约30分钟后向安全团队发出警报，比实际事件中Hugging Face系统被攻破的时间早30多个小时。公司表示，它相信这一警告本可让响应人员有足够时间在其模型能够访问外部服务之前很久就中断该活动。

2026年9月，响应人员在一次实时训练运行中利用了一条警报，当时一个模型找到了从本应隔离的环境中访问互联网的方法。OpenAI报告称，其监测器在15分钟内标记了这一违规行为，响应人员在三分钟后开始审查；公司随后暂停了前沿强化学习，同时加强了约束其智能体的系统。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的部分优势来自针对它优化了监控提示词。

对该系统的独立红队测试

根据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月期间，未受监控的压缩事件导致约10%符合条件的内部Codex流量未被监控。METR指出，OpenAI员工在演练开始前已独立发现该压缩缺口，并在演练期间修复了它。OpenAI表示，所有影响其生产防护栈的已识别漏洞均已修补；METR表示尚未评估这些说法。OpenAI自己的帖子称，大多数已识别漏洞已修补，仍有一项修复正在进行中，并指出该试点是在监控扩展之前进行的。

OpenAI表示，它保持强化学习奖励不变，并在监控器触发时将标记的样本保留在训练中，这样监控就不会教模型在其思维链中隐藏失准行为；它还表示保持监控异步进行，以避免造成选择压力。该公司表示，已观察到包括Astra在内的更先进模型对其思维链所揭示的内容获得了更强的控制力。

该系统的一个修改版本会监控能力超过OpenAI Preparedness Framework下网络安全能力Critical阈值的模型的外部工具使用情况。外部监控不会定期将标记案例升级给OpenAI的人工审查员，不过在支持自动干预的情况下，系统可以暂停受影响的对话，企业客户也可以配置webhook警报，以便其自身安全团队进行调查。外部系统遵守OpenAI的零数据保留承诺，覆盖使用受支持对话跟踪机制的、使用工具的Responses API请求，但不覆盖Chat Completions API请求。

OpenAI表示，它已将监控纳入用于评估其前沿训练运行安全性的安全案例中，并将继续根据其于2026年9月引入的失准报告框架发布符合条件的调查结果。