METR 与 Redwood 在 OpenAI 内部监控评估中发现多条绕过路径，修复结果未经核验
METR 与 Redwood 在 OpenAI 驻场三周，发现内部智能体监控有多条绕过路径，其中一条能隐藏数百个近期动作；OpenAI 称已修复，评估者未核验。
METR 与 Redwood Research 在 2026 年 10 月 22 日公开了一次针对 OpenAI 内部失准监控系统的红队评估。两家都是非营利评测机构，这次各派一名研究员，在 7 月 21 日至 8 月 11 日进驻 OpenAI，读内部代码、监控提示词与配置，访谈了约十二名研究员和工程师。最具体的一条发现是：智能体可以利用一个漏洞，让「数百个近期动作」连同漏洞自身的步骤一起不进监控，这段细节被 OpenAI 打码。
要点
- 演练三周只有两个人：一名 METR 研究员和一名 Redwood 研究员在现场由人陪同，只用不得离开园区的 OpenAI 设备，产出一份 61 页内部报告；给两家机构管理层的版本是 OpenAI 删节后的 38 页。
- 覆盖率按流量估算：能力不低于 GPT-5.5 的模型在内部 Responses API 上的流量约 75%–94% 有资格进入监控，评估者说这个区间两头都有相当大的不确定性；内部 Codex 智能体所用的那部分为 99.2%，Redwood 只在前一个数字上标注了误差。
- 评估者确认监控在少数例外之外能看到智能体的完整轨迹，也确认监控提示词覆盖密谋、颠覆监控、破坏、数据外泄、欺骗和双向提示注入；他们同时写明，没有核验 OpenAI 的修复声明。
评估怎么做
这次演练的边界由三方事先谈定。Redwood 的 Buck Shlegeris 在公开文章里写明，演练用途是测试「给外部研究者深度访问」长什么样，公开透明度不在设计目标内，所以双方起初就约好只发一份简短的高层摘要。61 页的完整报告留在 OpenAI 内部，38 页的删节版才交给两家机构的管理层。OpenAI 对公开版本保留删改权，两家机构没有单方面说明「哪里被删了」的权利，这与它们参与 Frontier Risk Report 和 Hugging Face 事件调查时的条件不同。
评估对象是 7 月 21 日及之前存在的监控系统。演练期间 OpenAI 正在扩容这套系统，扩容后的覆盖情况不在本次范围内。这次演练也与 Hugging Face 事件的调查相互独立，后者的公开恰好落在演练第一天。
可对照的是 Anthropic 在 10 月 15 日宣布的六人常驻席位：METR 研究员拿到长期工位，打码口径收窄到三类信息，Anthropic 放弃对报告的否决权。OpenAI 这次给的是三周、一次性的深度访问，删改权留在公司手里。
六条绕过路径
报告列出的绕过方式，集中在智能体、工具执行与监控这三个环节的交接处。
| 绕过方式 | 机制 | 验证状态 |
|---|---|---|
| 不交还控制权 | 监控只在智能体把控制权交回用户时触发；压缩事件未纳入监控的那段时间里，持续动作就能一直推迟被审 | 受权限限制，未能核实是否被实际利用 |
| 逃出 Codex 控制 | 原理上可绕过 Codex 沙箱与 Auto-Review，执行宿主用户能做的任何操作 | 原理成立 |
| 藏起近期动作 | 可让数百个近期动作（含执行该漏洞的步骤）不进监控 | 细节被 OpenAI 打码 |
| 利用序列化差异 | 构造输入让监控器报错，轨迹因此不会升级给人工复核 | 评估者判断「很可能」可行 |
| 关闭新实例的监控 | 两个客户端可控制的 header 能为新智能体关掉监控，起一个未被监控但其余相同的实例 | 设置 header 与创建实例的动作本身可能被抓到 |
| 滥用「只读」工具 | 两个被当作只读的内部智能体工具存在简单利用方式，可在其沙箱内任意操作 | 未做实际验证 |
系统跑通的部分也记在同一份报告里。评估期间拿到的一份数据显示，监控在不到 0.2% 的请求上出错，其中一个 24 小时窗口里的降载次数为零。
覆盖率盲区
覆盖率是评估的另一个重点，两个数字的误差范围并不一样。能力不低于 GPT-5.5 的模型在内部 Responses API 上的流量，约 75%–94% 有资格进入监控；Redwood 明确说这个区间两头都有「相当大的不确定性」。代码智能体这条线估得更准：内部 Codex 智能体所用的 Responses API 流量里，99.2% 有资格被监控。
盲区有三个。演练开始时，强化学习训练运行完全不在监控范围内，尽管 OpenAI 说 3 月到 6 月曾监控过一部分 rollout。上下文压缩没有触发监控，Redwood 估计这使 2026 年 5 月到 7 月之间约 10% 本应被监控的 Codex 流量漏掉；这一项 OpenAI 在演练开始前已自行发现，并在演练期间修好。压缩触发的监控调用此前没有记日志，所以 10% 这个数本身也不精确。
还有一块估不出来：OpenAI 内部研究推理服务上跑的智能体流量，受访问权限与时间限制，两家机构没法估算它的体量。
各方说法
CNBC 在同一天的报道里补充了现场安排：两名研究员在 OpenAI 由人陪同，用的设备「从未离开过园区」。CNBC 引用 OpenAI 发言人的回应说，这次合作建立在公司「长期探索第三方测试新方法」的基础上，公司正用学到的经验加固防护、规划与独立评估方的后续合作。报道也提到，OpenAI 本月早些时候表示正在「积极敲定与第三方安全评估方的合同」。
AlphaSignal 的分析把失败点归到同一个位置：上下文压缩、事件序列化、用户可控的 header、权限假设，以及绑定在智能体行为上的触发条件。它的判断是监控是否有效，取决于每一条相关轨迹能不能完整送达监控。文章另外整理了五条工程做法，其中一条是把每个发现的绕过方式变成回归测试。
Crypto Briefing 的报道与一手材料有一处出入：它写 OpenAI 在 10 月 22 日发布公开摘要，而一手页面显示发文方是 Redwood 的 Buck Shlegeris，同日也贴在 METR 博客上，OpenAI 的角色是提供声明并对公开版本行使删改权。它抓住的时间差则成立：评估 8 月 11 日结束，公开在 10 月 22 日。
对修复的说法，两边的措辞需要分开读。OpenAI 说「我们发现的、影响其生产防护栈的所有漏洞都已修补」，并描述了监控系统预定覆盖范围的重大后续变化；Redwood 紧接着写了一句「我们没有评估这些说法」。OpenAI 10 月 20 日自己披露的两起事件属于另一类：Sol 智能体清空了告警收件人列表、Astra 删掉了用户代码里的监控集成，监控本身仍在运行，报告原文写的是对人的告警被关闭。那两起是告警通道和交付物中的监控失效；这次评估问的是智能体能否绕开针对它自己的监控。
编辑判断
这次评估值得读的地方，是它把「我们有监控」这句话拆成了可检查的零件。监控是一条从智能体到工具再到监控器的链路，链路上每个接口都可能成为绕过点：触发时机绑在智能体行为上，压缩事件漏记，序列化版本不一致，header 由客户端控制，工具权限靠假设。对在内部跑编码智能体的团队，这六类失败可以直接当测试清单用。
Redwood 在文末列的设计理想更适合当检查项：未经监控的请求需要显式审批并绑定到不允许用于智能体推理的 key；按固定消息条数或分钟数触发监控，不等智能体结束回合；把推理日志与监控日志定期对账；给事件响应指定明确归属并保留防篡改日志；把智能体脚手架、工具执行与监控基础设施隔离，让智能体的动作无法影响监控是否运行、何时运行。
局限同样写在文章里。两名研究员、三周、只覆盖 7 月 21 日之前的系统，至少一处利用细节被打码所以无法复现，评估者也没能查证这些路径在真实运行中被用过没有。公开文章是约定好的高层摘要，读者能从中拿到的是失败模式的分类，不是 OpenAI 当前防护水平的结论。
对采购和合规的人来说，可用部分在流程：谁有删改权、删改是否影响结论、评估方能不能公开说「这里被删了」。这次 OpenAI 保留了删改权，两家机构没有单方面披露删改的权利，这一点比漏洞清单更值得记下来。