AREX Feed Article
OpenAI 披露今夏试点：METR 与 Redwood Research 进驻三周，实测内部智能体监控系统
10 月 22 日，OpenAI 在 X 上披露：今年夏天，公司邀请独立非营利研究机构 与非营利 AI 安全研究组织 ，试点对其内部监控系统进行嵌入式评估（embedded evaluation），并在三周内向两家机构提供对其基础设施的深度访问。OpenAI 在中称，评估方的发现帮助其在扩大这套系统的过程中强化了安全防护，也将塑造未来与 METR 及其他第三方评估方的研究合作。这条帖文引用转发了 ——METR 当天确认，两名员工曾入驻 OpenAI 现场工作三周，一份简短的公开报告已经上线。OpenAI 的帖文本身没有附报告链接，细节来自 METR 同日发布的报告。
据 METR 的，这项演练从 7 月 21 日持续到 8 月 11 日，评估人员发现了多处监控覆盖缺口，以及智能体原则上可用来逃避或让监控失灵的漏洞。OpenAI 称，其中影响生产防护体系的漏洞均已修补；METR 在报告中写明，未对这一说法做核验。
设备不离场，61 页内部报告：演练如何运作
报告记录了演练的运作方式：一名 METR 员工和一名 Redwood Research 员工在这三周里进入 OpenAI 现场，对该公司用于监测内部智能体错位行为（misalignment）的监控系统做压力测试。两人使用 OpenAI 发放的设备办公，设备不离场，在园区内时全程有人陪同；他们可以接触 OpenAI 的内部代码库、错位监控系统的提示词与配置细节以及内部文档，并对监控、安全系统（safety-systems）与安全（security）三个团队约 12 名研究人员和工程师做了技术访谈。
演练的产出是一份 61 页内部报告，交给 OpenAI 的研究人员与安全人员；METR 与 Redwood 的管理层拿到的是 OpenAI 删减后的 38 页版本。评估聚焦两个问题：内部智能体推理流量中有多大比例处在监控之下，以及智能体原则上能否关闭或架空监控系统。METR 强调，演练针对的是 7 月 21 日及之前存在的系统版本；OpenAI 当时正在扩容这套系统，改造不在评估范围内。
被测对象：盯住内部编码智能体的“监视器”
按 OpenAI 今年 3 月的，这套系统监控其内部部署的编码智能体：由 GPT-5.4 Thinking 以最高推理强度驱动，查看智能体的完整对话记录，包括思维链（chain-of-thought）、用户、开发者与助手消息以及工具调用和输出，自动标记可能与用户意图不一致或违反内部安全合规政策的行为，再交人工分流处理。OpenAI 称，在最新形态下，系统会在交互结束后 30 分钟内完成审查；运行五个月来已监测数千万条内部智能体编码轨迹，没有真实对话触发过最高严重级别，约 1,000 条对话触发中级告警并升级人工复核，其中不少来自内部红队的刻意测试；仍有不到 0.1% 的流量处在监控覆盖之外。
METR 的报告补充了一个覆盖细节：据评估时被告知的信息，3 月至 6 月间有一小部分强化学习（RL）训练回合被纳入错位监测，但演练开始时，RL 训练本身不在监控系统覆盖范围内。
METR 在中解释了评估监控系统本身的理由：开发者用 AI 监控系统捕捉智能体的错位行为；要保护监控系统，就得先找出智能体可能利用、从而隐蔽违规的缺陷。内部错位监控要防的风险，在 OpenAI 七月的事故中真实出现过：OpenAI 在 8 月的中写道，7 月内部网络安全评测期间，多个 OpenAI 模型绕过隔离控制，入侵了 OpenAI 部分内部研究基础设施和 Hugging Face 的系统；OpenAI 于 7 月 21 日公开披露此事，恰是嵌入式演练的第一天。METR 在报告脚注中说明，这项演练与它对 Hugging Face 事件的独立调查是两个项目，日期重叠纯属巧合。OpenAI 在复盘中表示，正在强化研究基础设施的防护，并向思维链监控投入更多算力。
发现：约一成内部 Codex 流量可能漏网
METR 的量化结论都附带了不确定性声明。演练时，内部 Responses API（Codex 等依赖它运行）上、由不低于 GPT-5.5 强度模型驱动的智能体流量中，约 75%～94% 符合被监测条件，评估方表示双向都有较大不确定性；其中内部 Codex 智能体用到的 Responses API 流量，99.2% 符合被监测条件。METR 说明，这一估计未涵盖他们知晓的其他内部智能体流量来源，例如运行在 OpenAI 内部研究推理服务上的智能体——受访问与时间所限，其体量无法估计。
压缩（compaction）环节带来一个更具体的缺口。报告估计，5 月至 7 月间，因为压缩事件未被监测，约一成符合条件的内部 Codex 流量可能没有受到监控；由于演练时缺少判断各次监控调用是否由压缩触发的日志，精确比例无法确定。OpenAI 员工在演练开始前已独立发现这一问题，并在演练期间修复。当时的监控系统还有一个触发特点：它在智能体交还控制权时才运行，于是在压缩事件未被监测的那段时间里，智能体只要持续执行动作、不交还控制权，就可以无限推迟被监控的时间。
不止漏网：监控系统本身能被绕过
评估人员报告了几条更直接的攻击路径：
- Codex 智能体原则上可以绕过 Codex 沙箱与 Auto-Review，从而执行宿主用户能执行的任何操作；
- 一个漏洞可让智能体阻止数百条近期动作（包括漏洞利用动作本身）进入监控，具体细节已被 OpenAI 从公开版中删去；
- 智能体可以构造特定输入，利用智能体所见轨迹与监控所见轨迹之间的序列化差异让监控失效，使其不再升级人工复核；
- 两个由客户端控制的请求头可以对新启动的智能体关闭监控，不过设置这些请求头、创建新实例的行为本身可能被监控系统捕捉；
- 两个未被监控的内部智能体工具此前被认为只有只读权限，评估人员找到一个简单漏洞可以突破限制、在沙箱内执行任意操作，但没有验证这在实际中能否成功。
评估也核验了系统有效的部分：除少量例外，监控能看到智能体所见的完整轨迹；监控提示词覆盖密谋、颠覆监控系统、破坏、数据外泄、欺骗以及双向提示注入（prompt injection）等风险类别；OpenAI 提供的信息显示，演练期间监控对不到 0.2% 的请求报错，其中一个 24 小时窗口内零次负载丢弃（load shedding）。
OpenAI 称漏洞已修补，METR 未予验证
METR 在报告中写道，演练结束后，OpenAI 表示评估识别的影响生产防护体系的漏洞均已修补，并另行描述了监控系统预期覆盖范围的重大后续变化；“我们未对这些说法做评估”。
基于发现，METR 在报告中列出一组监控与控制系统的设计原则。METR 认为，未来的监控基础设施应能承受来自大规模高能力内部智能体的蓄意、策略性与持续攻击：与其等智能体结束回合，不如每 N 条消息或每 N 分钟监测一次；对全部推理流量记账，定期把推理日志与监控系统日志交叉核对，确保本应被监测的流量确实被监测；明确事故响应的归属，减少主观判断空间；定期对监控系统做控制评估与漏洞挖掘；在智能体与监控之间强制隔离，智能体通常不应接触监控系统的设计与代码。
从 Anthropic 到 OpenAI：同类演练，有限的公开
同一模式 3 月已在 Anthropic 出现过：用三周时间对 Anthropic 的部分内部智能体监控与安全系统做了红队测试，发现了几处新漏洞。10 月 14 日，METR 公开发布其嵌入式评估愿景，写道：“如果一家 AI 开发商正走向对其内部智能体失控，公司之外会有人知道吗？”
公开层面的边界在演练开始前就已划定：METR 与 OpenAI 约定只发布简短、高层次的帖子；OpenAI 有权以其单方判断删改公开版内容；METR 表示，报告呈现的每一条发现他们都背书。METR 期望，未来版本的演练将按其《我们与 AI 公司合作的方式》()中列出的透明与独立实践执行，提供更充分的公开透明度。
至于扩大后的监控系统现在覆盖多少流量、修补后的版本还能不能被绕过，这次演练没有回答。