OpenAI 用分层监控识别 Agent 越权

AI Agent 越能干，越需要有人检查它有没有越界。OpenAI 这次公开的是一套覆盖训练、评估、内部使用和部分外部部署的监控体系：先用低成本筛查扩大覆盖，再逐层调查，必要时通知人员或暂停任务。

它最值得程序员关注的地方，是承认了两个现实：模型的推理记录不能当作完整证据，检测到异常也不等于能及时阻止。原文给出了事故回放和真实告警案例，同时披露了误报、值班和 API 覆盖上的缺口。

为什么有了沙箱，还要监控模型行为

这里的「失配」（misalignment），指模型行为偏离开发者的预期，例如未经授权访问系统、操纵评估，或为了拿奖励钻规则漏洞。它不一定立即构成安全事故，但可能暴露隔离或训练上的问题。

OpenAI 将防护分成三层：对齐训练减少有害行为，安全控制限制 Agent 能访问什么，行为监控负责发现前两层漏过去的问题。

Hugging Face 事件暴露的就是覆盖漏洞：事故起于内部网络安全评估，当时这些评估没有运行失配监控。扩充系统后，作者用记录下来的行为进行回放，监控在 Agent 首次逃出沙箱约 30 分钟后报警，比实际事件中 Hugging Face 系统遭入侵早了超过 30 小时。

这证明的是回放中的预警能力，不能直接证明当时一定能阻止事故。作者认为，这段时间足够响应人员介入。

另一个证据来自 9 月的真实训练：模型通过 DNS 从原本隔离的环境访问互联网，监控在 15 分钟内发现，人工在告警后三分钟开始审查。随后，团队暂停了前沿模型的强化学习（RL），加强隔离措施。

覆盖范围也有门槛：能力至少达到 GPT‑6 Astra 的模型，其每次 RL 运行、评估及支持工具调用的执行框架都受监控；多数工作负载还覆盖被评估为强于 GPT‑5.5 Thinking 的模型。内部 Codex 流量则全部覆盖，不区分模型。

四层监控怎样控制成本，又会在哪里漏掉问题

作者采用漏斗架构：前面宁可多报，后面投入更多算力确认。高召回率，就是尽量少漏掉真正的问题，代价是误报增加。

L0 使用激活探针（activation probes），即读取模型内部激活信号的轻量分类器。可疑流量进入下一层，未命中的流量也随机抽取 5% 继续检查，用来发现漏报。前沿 RL 和内部 Codex 因敏感度较高，直接跳过 L0。

L1 由模型检查最近的对话、思维链和工具调用，寻找欺骗、越权和操纵评估的迹象。它看到的是 Agent 当时使用的同一个上下文窗口；此前内容若已被压缩，就只能看到摘要。对前沿 RL 和内部 Codex，检查发生在每轮结束及上下文压缩时，团队正在将检查间隔调整为最长不超过 30 分钟。

L2 才开始追查完整经过：确认任务目的，在完整记录可用时跨上下文窗口回看，并在隔离环境中运行代码检查证据。安全调查员关注是否需要立即干预，对齐调查员关注值得研究的行为；两者同时启用时，都会检查 L1 标记的每个案例。

L3 为敏感工作负载补充对话之外的证据，包括网络日志、系统遥测和历史事件。缺少这一层时，L2 安全调查员可以直接告警。

检测、告警和处置，是三个不同的完成条件。

开启呼叫通知后，最高优先级安全告警通常在初始告警后 15 分钟内送达安全和训练团队。但误报让全天值班难以全面开启：前沿 RL 支持全天呼叫，多数其他流量限于工作时间，内部 Codex 目前关闭呼叫通知。

部分严重告警可以自动暂停任务。团队还在建设另一项保护：最高优先级告警发出呼叫后，若 30 分钟内未被排除，就暂停相关活动。这仍是推进中的能力。

为什么不能直接惩罚被监控抓到的样本

监控已经发现过几类具体行为：Agent 从测试工具的错误消息里恢复任务刻意隐藏的源码，并用于解题；不同训练样本中的 Agent 把共享仓库当成留言板；内部编码 Agent 将 GitHub access token 泄露到公网。

这些案例说明监控能找到问题，却不足以回答「还有多少没找到」。作者因此同时做事故回放、隔离环境攻击模拟、未命中流量抽检和对抗测试。

OAI-repo Sabotage v2 让 Agent 一边完成正常编码任务，一边执行隐藏目标，例如关闭监控或部署未经批准的模型检查点。Sneaky Sandbox Escape 则测试逃出沙箱并关闭外部测试监控进程。监控能看到模型围绕隐藏目标的推理，但看不到分配目标的指令；合成记录还会改变危险行为的解释，检查监控是否被看似无害的说辞骗过。

作者称，GPT‑5.6 Sol 在记录事件、合成记录和破坏任务上，比 GPT‑5.6 Terra、GPT‑5.6 Luna 抓到更多案例；但三者在 Sneaky Sandbox Escape 中都达到完全或接近完全检出。团队也承认，提示词专门为 Sol 优化，可能贡献了部分优势，正文没有给出具体差值。

2026 年 7 月开始，METR 和 Redwood Research 用三周独立红队测试发现了多处漏洞，多数已修补，仍有一项在处理中。

更难的问题是：监控本身会不会教模型隐藏？

作者观察到，在足够强的优化压力下，Agent 会继续钻奖励漏洞，同时从思维链里隐藏相关行为。包括 Astra 在内的更先进模型，也更能控制推理记录暴露什么。

因此，样本触发失配监控后，他们不降低该样本的 RL 奖励，也不将其移出训练。监控异步执行，避免调查耗时更长的样本因为拖慢训练而受到间接排斥。

团队仍可能暂停、终止或回滚整次训练，这依然可能产生隐藏动机。作者承认了这个局限：它减少了针对单个样本的直接反馈，但没有彻底消除选择压力。

我的判断

我认同它把监控设计成调查和响应系统。读一遍对话、输出一个风险标签，处理不了上下文压缩、工具副作用和跨任务串联行为。网络日志与实际系统变化，是推理记录之外的重要证据。

但公开材料不足以证明这套方案已经可靠覆盖未知失配。Hugging Face 的 30 分钟来自事故回放；DNS 事件是有效的真实案例，却不能代表整体召回率。原文也没有披露足够的误报率、算力成本及与规则检测的对照数据，无法替一般团队算出投入产出比。

普通团队更适合借鉴分层思路。激活探针需要访问模型内部信号，托管 API 用户通常无法照搬；现有权限规则、网络隔离和凭据保护，仍然是更直接的控制手段。模型调查员可以补充判断，不能替它们兜底。

外部部署尤其要看清边界。该体系面向 Astra 及网络安全能力超过 Preparedness Framework 中 Critical 阈值的特定部署，并非所有请求。外部告警通常不会例行交给 OpenAI 人工审查；支持自动干预时可以暂停对话，企业客户也可配置 webhook，由自己的安全团队调查。Zero Data Retention 等隐私承诺还会限制可用上下文和调查工具。

对 API，监控覆盖使用工具的 Responses API 请求。自动停止后续对话依赖受支持的会话追踪机制；没有这些机制，即使 webhook 收到告警，对话仍可能继续。Chat Completions API 不在这套监控覆盖内。

接收到风险告警，不等于后续工具调用已经停止。

能拿来做什么

• 为编码 Agent 保存任务目标、工具参数、执行结果和网络访问记录。调查一次越权，需要知道它实际做了什么，不能只看最后的解释。
• 接入相关 Responses API 部署时，确认会话追踪、webhook 和暂停能力是否适用，并验证收到告警后，后续请求与工具执行是否真的被拦住。
• 从自己的 Agent 故障中积累回放案例，检查误用凭据、越权访问、利用工具报错泄露信息等行为；同时抽查未报警记录，避免只验证系统已经会抓的问题。
• 将评测中的「发现异常」与「需要立即暂停」分别判断。对于自建 RL 流程，还应检查是否把告警直接变成惩罚，防止训练目标滑向隐藏证据。