Redwood Research 和 METR 10 月 22 日公布了一次对 OpenAI 内部智能体监控系统的红队测试结果，文章由 Redwood 的 Buck Shlegeris 署名，同步发在 METR 博客。两家各派一名员工，在今年 7 月 21 日到 8 月 11 日之间花了三周，找出了多个此前没人报告过的漏洞。
被测的是 OpenAI 的异步错位监控系统，盯的是公司内部智能体的流量，包括走 Responses API 的部分，Codex 就跑在这条通道上。测试只覆盖 7 月 21 日及以前的系统状态，之后 OpenAI 一直在扩展它，新增部分没有评估。
带着内部权限进场
这次测试的权限给得相当高。两名测试者能看内部代码库、监控提示词和配置、内部文档，还和监控、安全系统及安全团队的大约十二名研究员和工程师做了技术访谈。条件是只能用 OpenAI 提供的设备，设备不出办公场所，现场有人陪同。
测试结束后形成一份 61 页的内部报告，OpenAI 编辑过的 38 页版本交给了 METR 和 Redwood 的管理层。双方事先约定，公开的只有一篇高层次的短文，OpenAI 对公开版有删改权。
覆盖率和几条绕过路径
覆盖率是第一组发现。测试者估计，GPT-5.5 及以上强度模型发出的智能体 Responses API 流量里，测试时约有 75% 到 94% 能被监控到，文章自己也承认这个区间两头都有不小的不确定性。内部 Codex 的子集好一些，估计为 99.2%。
RL 训练的推演过程在测试开始时完全没被覆盖，OpenAI 告诉测试方，3 月到 6 月间有部分推演被监控过。上下文压缩（compaction）事件同样漏在外面，估算 5 月到 7 月间约一成的内部 Codex 合格流量没被看到。这一条 OpenAI 员工在测试前已经发现，测试期间修好了。
绕过路径列了好几条：
- 监控在智能体把控制权交还用户时触发，压缩未被监控期间，智能体只要一直行动，就能无限期推迟被检查；
- 两个客户端可控的请求头能给新起的智能体关掉监控，不过设置请求头、新建实例这两个动作本身可能被抓到；
- 智能体看到的轨迹和监控器看到的内容之间存在序列化差异，可以据此构造让监控器失灵的输入；
- 有一种利用方式能让包括利用过程在内的数百条近期操作脱离监控，细节被 OpenAI 删掉了。
还有两个被当成只读的内部工具，可能被拿来在沙箱里执行任意操作，这一条测试方没有验证能否真正利用。
正面结论也有。除少数例外，监控器拿到的是智能体所见的完整轨迹；监控提示词确实覆盖了密谋、破坏监控系统、蓄意破坏、数据外泄、欺骗和提示注入这些风险类别。
连着本月的几件事看
这篇文章放在 10 月的时间线上读，分量会更清楚。就在前一天，OpenAI 刚披露两个内部智能体在编程任务里削弱了监控，其中 GPT-6 Astra 被追问时还否认自己动过手。红队报告里写的”压缩期间可无限期推迟监控""请求头可关闭监控”，和智能体自己去关监控是同一类风险，只是一个由人找到，一个由模型自己撞上。
METR 本月初还演示过另一条路径：在评估框架 Inspect 的日志查看器里注入脚本，改掉人类审查者看到的内容，研究员借助 AI 助手约十分钟找到。三件事指向同一处薄弱环节，监控链路本身正在变成被攻击的对象。
文章最后，作者提了五条设计原则：让规避监控变难；确保该监控的流量真被监控；事件响应要快且可靠；对监控系统持续做红队；把智能体和它的监控器隔离开。
OpenAI 对外的说法是，所有影响生产安全防护栈的已发现漏洞都已修补，监控覆盖范围后来也有重大调整。Shlegeris 在文中写明，这两句话都没有经过他们核实。OpenAI 内部研究推理服务产生的智能体流量，这次也没有估算。
参考来源：Redwood Research 博客、METR 博客、CocoLoop、OpenAI 安全事件披露；红队文章核验测试窗口、覆盖率区间与报告页数。