METR 红队测试发现 OpenAI 监控系统存在漏洞

METR与 Redwood Research 于 2026 年 10 月 22 日发布了一份试点项目的公开说明。在该项目中，两家机构各派出一名员工，在深入接触 OpenAI 内部基础设施的情况下，用三周时间对该公司的内部失准监控系统进行压力测试。评估人员报告称，他们发现了该系统存在的一些新型漏洞，这些漏洞存在于截至 2026 年 7 月 21 日（含当日）的系统中。

该项目于 2026 年 7 月 21 日至 8 月 11 日开展，主要着眼于估算有多少智能体推理活动受到监控，以及智能体是否有可能关闭或破坏监控系统。项目成果是一份长达 61 页的内部报告，已分享给 OpenAI 的研究人员和安全人员；OpenAI 删节后的 38 页版本则分享给了 METR 和 Redwood Research 的领导团队。

在严格约束下深入接触内部系统

两名评估人员能够访问 OpenAI 的内部代码库、失准监控器的提示词和配置详情，以及内部文档；他们还对监控、安全系统和安全团队中的约十几名研究人员与工程师进行了技术访谈。为获得这种程度的访问权限，他们使用 OpenAI 配发、不得带离办公场所的设备，并在现场工作期间有人陪同。

METR、Redwood Research 和 OpenAI 将该项目设计为一项试点，旨在让外部研究人员深入接触内部基础设施，而非借此实现对 OpenAI 监控系统的充分公开透明；各方事先同意，只发布一篇相对简短、概述性较强的公开文章。OpenAI 有权按照其单方面判断，从公开版本中删去任何被认定为机密或其他敏感信息的内容。调查结果描述的是截至 7 月 21 日（含当日）接受评估的历史系统，并未评估当时正在进行的改动；METR 指出，OpenAI 在项目期间正在扩展其监控系统。

监控覆盖缺口及绕过监控的途径

METR 估计，在项目开展时，来自能力至少与 GPT-5.5 相当的模型、经由内部 Responses API 产生的智能体流量中，约有 75–94% 符合监控条件；同时，METR 承认这一估计存在相当大的不确定性，实际比例可能高于或低于该范围。Responses API 也为 Codex 等产品提供支持；在这部分流量中，评估人员估计，供内部 Codex 智能体使用的流量有 99.2% 符合监控条件。他们表示，由于访问权限和时间限制，无法估算他们所知的其他内部智能体编码流量规模，例如运行在 OpenAI 内部研究推理服务上的智能体所产生的流量。

一些调查结果涉及监控覆盖方面的缺口。项目开始时，监控系统尚未覆盖强化学习训练任务，不过评估人员获悉，3 月至 6 月期间，有一部分强化学习训练展开过程曾接受失准监控。METR 估计，由于未监控压缩事件，2026 年 5 月至 7 月期间，符合监控条件的内部 Codex 流量中可能约有 10% 未受到监控。OpenAI 员工在项目开始前已独立发现这一缺口，并在项目期间予以修复。由于系统只有在智能体将控制权交还给用户时才会触发，智能体只要在这段时间内持续行动，就可能无限期推迟接受监控；受访问权限限制，评估人员无法确认是否有智能体在实际中这样做过。此外，评估人员看到的信息显示，在项目开展时，监控器处理请求出错的比例低于 0.2%，且在一个 24 小时的时段内记录到零次负载丢弃。

评估人员还找到了智能体能够彻底规避监控的途径。他们发现了一种方法，理论上 Codex 智能体可以借此绕过 Codex 沙箱和 Auto-Review，从而执行宿主用户能够执行的任何操作；他们还发现了一项利用手法，其细节已被 OpenAI 删去，该手法会使数百项近期操作不受监控，其中包括实施该利用手法本身所涉及的操作。他们发现，智能体很可能可以利用智能体与监控器对轨迹进行序列化的方式差异，构造出导致监控器失效的输入，从而避免升级至人工审核。他们还发现了两个可由客户端控制、能够为新智能体关闭监控系统的请求头。这可能使智能体启动一个原本相同但不受监控的实例，不过，设置这些请求头并创建实例的行为本身也可能被监控系统捕获。此外，他们发现了两个未受监控的内部智能体工具，这些工具据信仅具有只读权限，但简单的利用手法就可能破坏其限制，使其能够在沙箱环境中执行任意操作；评估人员并未在实际中验证或测试这种行为。

除发现这些漏洞外，评估人员还确认，除少数例外情况外，监控系统看到的完整行动轨迹与智能体看到的一致；他们也验证了监控器的提示词会检查多种风险类别，包括谋划、监控系统遭到破坏、蓄意破坏、数据外泄、欺骗，以及输入和输出提示注入。评估结束后，OpenAI 表示，所有影响其生产环境安全防护体系的已发现漏洞均已修补，并介绍了此后对监控系统预期覆盖范围所作的重大调整。METR 表示尚未评估这些说法。

OpenAI 对监控系统的描述

OpenAI 在一篇2026年3月19日发布的文章中公开介绍了受测系统。文章称，该低延迟系统由 GPT-5.4 Thinking 在最高推理力度下驱动，会在智能体交互结束后的 30 分钟内进行审查，并记录和分析智能体的思维链与操作，为每次交互分类、判定严重程度，并将异常情况提交人工审查。OpenAI 表示，该系统部署于所有标准的内部编码智能体环境中，可查看完整对话历史，包括用户、开发者和助手发送的所有消息，以及工具调用和输出。

OpenAI 的文章列出了系统监控的行为类别，包括规避限制、欺骗、隐瞒不确定性、奖励作弊、未经授权的数据传输、破坏性操作，以及输入和输出提示注入；文章还报告称，截至 2026 年 3 月 17 日，未发现任何沙袋行为、蓄意破坏或谋划的真阳性案例。OpenAI 表示，在运行的五个月中，该系统监控了数千万条内部智能体编码行动轨迹，将约 1,000 段严重程度中等的对话升级提交人工审查，其中许多来自有意开展的内部红队测试；而触发最高严重程度级别的真实对话数量为零。该公司还表示，监控器标记了员工通过内部渠道独立报告的每一次交互。

OpenAI 在文章中指出，这种方法的关键在于可监控性；如果没有专门的控制评估和红队测试，就无法有把握地量化开放式真实场景流量中的漏报率。文章将监控描述为纵深防御体系中的一层。OpenAI 所述的路线图包括开展控制评估、制定监控器和人工审查人员可接受的可靠性与延迟标准，以及逐步扩展到同步拦截，即评估模型操作并在执行前予以阻止。

未来监控系统的设计原则

根据这些发现，评估人员提出了监控与控制系统的设计原则。他们写道，在他们看来，未来的监控基础设施应当能够抵御组织内部高能力智能体蓄意、持续发起的攻击；这类攻击可能经过战略性部署，并以大规模方式展开。五项原则要求：让智能体难以逃避监控；确保所有本应受到监控的流量确实得到监控；快速、可靠地响应事件；主动对监控系统开展红队测试；并确保智能体与其监控器之间保持隔离。文中提到的具体做法包括：每隔固定数量的消息或固定时长监控智能体，而非等其结束一轮操作后再监控；维护已知的所有规避监控方式清单；保存防篡改且可搜索的日志；以及在与工具调用执行环境相隔离的环境中运行智能体框架。

METR 表示，此次评估在很大程度上得益于广泛的访问权限，以及 OpenAI 员工提供的大量后勤和技术支持。METR 还表示，在未来版本的评估中，预计会遵循其《与人工智能公司合作的方法》文件中所述的透明度和独立性最佳实践，以提升面向公众的透明度。