各派一人深入 OpenAI 三周：METR 与 Redwood 压力测试内部 Agent「错位行为」监控系统

今年夏天， @METR_Evals 与 @redwood_ai 各派一人进驻 OpenAI 三周，深度检查内部 agent（含 Codex）的错位行为监控。公开稿只给高层摘要：覆盖有缺口，也找到可绕过监控、沙箱与 Auto-review 的路径。OpenAI 称影响生产防护栈的漏洞已修补；评估方未独立复核。
https://metr.org/blog/2026-10-22-red-teaming-openai-agent-monitoring/

试点怎么做？
· 时间：2026-07-21 至 08-11。评估对象是截至 7 月 21 日及之前的异步内部监控系统，不评估同期正在扩展的改动。
· 权限：公司配发设备不离场、有人陪同；可看内部代码库、监控 prompt / 配置、文档，并访谈约十多名监控、安全系统与安全团队人员。
· 目标两个子问题：(1) 有多大比例的 agent 流量被监控；(2) agent 能否破坏或绕过监控。
· 产出：61 页报告给 OpenAI；经删减后 38 页给 METR / Redwood 管理层。事先约定只发简短公开稿；OpenAI 可删密，评估方无权单方面描述删了什么。

公开的关键发现（均为当时系统状态）
· 覆盖率：内部 Responses API（支撑 Codex 等）中，不低于 GPT-5.5 的 agent 流量约 75–94%「有资格」被监控（不确定性大）；其中内部 Codex agent 子集约 99.2%。「有资格」不等于一定跑完整条监控流水线（还有报错、过载丢弃、实现 bug）。另有内部研究推理服务上的 coding agent，因权限与时间未能估量。
· RL 训练：知情称 3–6 月有一部分 RL rollout 被监控；试点开始时 RL 训练运行不在覆盖内。
· Compaction 缺口：未监控 compaction 事件，估计 2026 年 5–7 月约有一成量级的合格内部 Codex 流量实际未进监控；精确比例不确定，因当时没记「多少监控调用由 compaction 触发」。OpenAI 在试点前已独立发现，并在试点期间修复。
· 拖延触发：当时监控在 agent「把控制权交回用户」时才触发。在 compaction 未监控期间，agent 只要持续行动，理论上可无限推迟被监控。评估方因权限未能查实是否已被真实利用。
· 监控可靠性：获悉当时监控报错率低于约 0.2%；试点中某 24 小时内过载丢弃为零。
· 可利用路径（细节多被删）：
· Codex agent 原则上可绕过沙箱与 Auto-review，做到主机用户能做的任意操作；
· 一种 exploit 可让「数百条」近期动作（含 exploit 本身）不被监控；
· 利用 agent 所见轨迹与监控所见序列化差异，构造可能让监控失败、从而不升级人工复核的输入；
· 两个可由客户端控制的 header 可为新 agent 关掉监控（设 header、起新实例的动作本身仍可能被抓到）；
· 两个被认为只读的未监控内部 agent 工具，理论上可用简单方式突破限制（未在实战中验证）。
· 正面核对：除少数例外，监控所见轨迹与 agent 所见基本一致；监控 prompt 覆盖 scheming、破坏监控、破坏、数据外泄、欺骗、提示注入等类别。
· OpenAI 事后称：所有影响生产防护栈的已识别漏洞已修补，并描述了后续覆盖范围的重大变更。METR / Redwood 未评估这些说法。

他们提出的设计理想（摘要）
未来监控应能扛住高度能干的内部 agent 的故意、持续攻击：难逃监控（未监控请求需显式批准；按 N 条消息 / N 分钟触发，而非等回合结束）；对「该监控的流量」做账本交叉核对；快速、权责清晰的事件响应与防篡改日志；定期对监控本身做控制评估与红队；agent 与监控强隔离，agent 行为不应能影响监控是否运行。