2026年7月21日至8月11日，METR和Redwood Research各派一名研究人员进入OpenAI内部，对编码智能体的失配监控做了为期三周的高权限试测。10月22日公开的结果里，有一个很实在的漏洞：某种利用方式可以让最近数百次操作不进入监控记录，利用行为本身也会被藏起来。细节已由OpenAI删节，外界既不能据此复现，也不能把它讲成已经发生的生产事故。[1]
参与者拿到了内部代码库、监控提示词和配置、文档，访谈了约十几位安全与工程人员；使用OpenAI提供的设备，并在现场接受陪同。这和让模型回答几道安全题不是同一种评测。评测范围却也很窄：主要是7月21日及以前的异步内部失配监控体系，不负责验证其后扩展过的系统。61页内部报告交给了OpenAI研究和安全人员，外部公众看到的是一篇高层摘要；另有一份38页删节版交给METR和Redwood管理层。[1]
覆盖率为什么不能只报一个百分数
报告估计，当时至少达到GPT-5.5能力的模型，经内部Responses API产生的Agent请求中，约75%—94%“有资格进入监控”；内部Codex Agent对应子集的数字是99.2%。这里的统计对象不同，不能把两个数字平均，也不能把“有资格”误写成“每次都被完整审查”。请求可能因为负载卸载、监控错误或实现缺陷而没有跑完整条监控流水线；OpenAI其他内部推理服务产生的编码流量也不在这一估计之内。[1]
更容易被忽略的是触发条件。METR估计，2026年5月至7月，未监控上下文压缩事件可能导致约一成符合条件的内部Codex流量没有被实际监控。该比例不确定，因为历史日志没有记下足够信息来准确还原压缩触发了多少次监控调用。OpenAI员工在外部试测开始之前已独立发现这一问题，并在试测期间修复。原先的触发点还依赖Agent把控制权交回用户：如果智能体一直继续执行动作，监控就可能一直等不到调用时刻。[1]
这类盲区很难靠“异常行为识别率高”来弥补。未送到监控器的调用，再强的检测模型也看不到。企业验收时需要把总推理调用量、应监控调用量、监控器实际收到的轨迹数、成功分析数和升级人工复核数分开计量。每个数字必须能通过独立流水日志对账。对账差异不能被一句“覆盖率99%”吞掉，还应记录请求来源、权限主体、工具、压缩和重试等事件。比如一条任务在第三十次工具调用后压缩上下文，随后继续执行四十次写操作；如果监控器只在“任务完成”时启动，运维面板上暂时看不到告警，不代表此期间的写操作没有风险。这个例子是企业验收场景，并非对OpenAI事故经过的复述。
覆盖率还要按时间切片，不能只给月底总值。假如周一的监控管线宕机一小时，月底按请求数平均也许仍然好看；恰好在那一小时执行的高权限批量任务却全无可查记录。验收人员应能从原始网关计数和监控接收计数独立计算每小时差额，对无法确认是否被分析的会话打上“监控状态未知”，而非把它归入“无异常”。一旦压缩或跨进程恢复使轨迹分段，还要核对分段前后的会话标识是否稳定，确认旧段不会因为任务未结束就永久留在队列里。前文的比例只属于METR试测时的特定内部流量，不能拿来当企业自身的目标覆盖率。[1]
监控器与被监控者不能共用一把钥匙
试测还找到一条理论上可让Codex绕过沙箱和Auto-Review、执行宿主用户所能执行的动作的路径。报告也提到两项客户端可控制的请求头，能令新启动的Agent实例不被同一监控系统记录，但设置请求头及新建实例的动作本身可能被原有监控捕获。另有两种原被认为只读的内部Agent工具，其沙箱权限限制可能被规避；研究人员明确表示没有验证实际可利用性。不能把这些不同成熟度的发现都写成“智能体已经获得管理员权限”。[1]
序列化差异则涉及另一种信任边界：Agent所见的执行轨迹和监控器接收的内容如果不一致，精心构造的输入可能让监控器处理失败，不再把轨迹交给人工复核。[1] 企业常把监控当作旁路插件，默认它读到的事件就是原始执行事实。值得专门测的是两者之间的转换：消息截断、工具输出编码、异常重试、跨服务追踪ID，任何一处丢字段都会改变审计结论。
权限问题也不能交给监控器兜底。监控发现高危操作之前，异步系统中的删除、转账、代码提交可能已经完成。OpenAI介绍的内部监控属于事后告警路线，并提出探索执行前的同步拦截；两种机制的承诺不能混写。[2]高风险工具应使用独立身份和最小权限，给写操作增加明确的授权门槛；把审批权或监控开关放在Agent可以修改的运行环境中，容易让防线和受检对象一起失效。日志要防篡改，但保留期、访问授权和敏感数据脱敏仍需遵守企业政策，不能因为“监控需要”就无限复制用户数据。
对不同动作应使用不同处置速度。读取公开文档可以事后抽查；读客户数据要有访问控制和留痕；生产写操作若不可撤回，最好在执行前由独立权限服务阻断或要求人工批准。异步监控适合发现较长时间尺度的偏离，不适合单独承担“一次危险调用也不能成功”的目标。预先定好高危工具清单、撤销凭证与中止任务的责任人，警报才不只是深夜群里的一条消息。这个分层是企业建议，不是声称OpenAI已经按这张清单实施。
修复声明仍待外部复测
OpenAI表示，所有影响生产防护栈的已识别漏洞已经修补；METR说自己没有评估这一声明，也没有验证其后扩大覆盖面的效果。报告没有显示这些漏洞曾被真实智能体利用。企业采购材料若引用此事，应把“当时发现的路径”“厂商自述的修复”“第三方已验证的证据”列在不同栏位，不能合并成一个“已解决”。[1]
OpenAI此前介绍内部编码Agent监控时称，监控器会检查对话、推理与工具轨迹，按严重级别告警，并由人处理；它同时承认，靠员工主动上报与监控器表现相比较，不能得出开放环境里漏报率的可靠估计。[2] 另一个有关研究环境防护的说明提到，正在扩大训练与评测中的监控，使用分阶段检测，并针对高严重度告警指定处理节奏；它描述的是后续方案，不能倒推7月试点所测的旧系统已经具有同样覆盖。[3]
这次合作的公开边界也要读清楚。METR说明，此次安排本来是深度接入的试点，不以提供全面公共透明度为目标；OpenAI有权删去其认定敏感的公开细节。METR在10月14日公布的一般工作原则中主张未来评估应披露范围、访问限制和删节对结论的影响。两份材料放在一起，给企业的启发是：外部团队只要进了机房，并不自动等于公众可以独立验证全部结论。[1][4]
企业怎么做一次像样的验收
先画边界。把Agent、推理服务、编排器、工具代理、监控器与审计存储放到一张数据流图上，标出哪些服务可修改告警配置、哪些身份可以开无监控任务。标记每个写操作最终依赖的宿主权限，尤其是代码仓库、生产数据库、云控制台、邮件和付款接口。如果编排器可以自行给子Agent换身份，先关掉这种自由度，再谈模型能不能“自觉”遵守政策。
再做对账和故障注入。选择一段可重放的非生产任务，记录全部推理事件，按会话和工具动作核对监控日志；故意制造上下文压缩、网络超时、轨迹超长、序列化失败和监控进程不可用，观察是否产生明确的未监控告警。检查队列堆积时是拒绝高风险执行，还是悄悄放行。验收报告至少写明覆盖分母、丢失区间、告警延迟、人工接手时限与补录机制，不用单一准确率代替这些数据。
最后请另一组人测试“监控会不会被绕开”：他们应被允许检查可配置请求头、子Agent继承权限、沙箱边界、只读工具的写入面、以及监控器看到的轨迹是否和Agent实际所见一致。生产上不应复用试验中发现的利用细节；先在隔离环境固定复现条件，再让负责人给出修复证据和回归结果。涉及隐私的内部轨迹按最小可见原则分级，外部评测合同则写明披露边界，避免采购方误以为拿到一页通报就是完成独立认证。
做红队测试时，给测试方的权限也要事先圈定：可接触哪一段日志、能否修改测试租户的配置、哪些发现允许公开到什么颗粒度。最有用的交付物未必是漏洞利用代码，而是可重复的失败条件和修复后再测的判定标准。例如测试中发现监控器遇到非法编码会报错，就列出输入类别、受影响服务版本、是否产生故障告警以及回放结果；不需要把真实用户数据或绕过细节塞进演示录像。若厂商只提交“已修复”声明，企业仍应在自己的隔离环境验证同类错误不会再静默放行。
今年3月METR对Anthropic内部监控的另一次高权限试测，也发现配置及子Agent调用相关的监控漏洞，且在当时发现模型本身仍有明显的攻击规划局限。[5] 两次试测的系统、授权范围和时间点不同，没法据此给两家公司排安全名次。不过，它们都提醒验收人员多问一句：监控系统的配置和采集路径是谁控制的？如果回答仍是“Agent运行的那套程序”，就该把监控放到另一个信任域，给绕行条件设置独立告警。
生产验收还需要安排回归日。今天修好上下文压缩漏采，明天更新编排框架或增加一类子Agent，采集分母可能又变了。让配置变更触发同一套对账测试，告警阈值跟着实测负载调整；涉及高权限工具的新流程，在拿到采集和人工接管证据前不要默认放行。
还有一个常被漏掉的值班问题：谁有权暂停Agent，暂停之后已经排队的工具调用怎么办？演练时让测试任务在运行中触发监控故障，按预定步骤切断后续写权限，再检查队列里是否还有请求继续出站。给每个事件留一个能连接用户请求、模型会话、工具结果和人工处置的标识；如果事后只能看到告警摘要，却查不到最终哪个权限主体完成了写入，所谓“完整回放”便无从谈起。修复验收结束后再恢复权限，并保存恢复批准记录。这些动作比在供应商页面勾选“支持审计日志”更能反映实际控制力。验收报告最后应写出尚未覆盖的任务类型和有效期限；如果测试只跑了一个代码仓库，就不要让结论自动延伸到财务系统或全公司的Agent。
来源
[1] METR / Redwood Research，《Red-Teaming OpenAI’s Internal Agent Monitoring Systems》，2026-10-22，https://metr.org/blog/2026-10-22-red-teaming-openai-agent-monitoring/
[2] OpenAI，《How we monitor internal coding agents for misalignment》，页面无可核验发布日期，https://openai.com/index/how-we-monitor-internal-coding-agents-misalignment/
[3] OpenAI，《Pacing model development in an era of cyber-critical capabilities》，页面无可核验发布日期，https://openai.com/index/pacing-model-development-cyber-capabilities/
[4] METR，《Our approach to working with AI companies》，2026-10-14，https://metr.org/blog/2026-10-14-our-approach-to-risk-assessment/
[5] METR，《Red-Teaming Anthropic’s Internal Agent Monitoring Systems》，页面结构化发布日期2026-03-26（URL路径为03-25；文内注明2026年5月增补结果），https://metr.org/blog/2026-03-25-red-teaming-anthropic-agent-monitoring/
配图为概念示意。