7 月 21 日至 8 月 11 日的三周里，METR 和 Redwood Research 各一名员工开展了一项高权限试点测试，对 OpenAI 的内部未对齐行为监测系统进行压力测试。¹ 本次测试的成果是一份 61 页的内部报告，提供给了 OpenAI 的研究人员和安全人员。² 报告主要推算智能体推理中有多少比例受到监测，并考察智能体在原理上能否禁用或破坏监测系统。本次测试考察的是 7 月 21 日及此前的内部未对齐行为监测系统，并没有评估测试开展时正在进行的改动。

本次测试获准深入访问内部系统。METR 和 Redwood 的两名员工可以查看 OpenAI 的内部代码库、未对齐行为监测器的提示词和配置详情，以及内部文档，还与监测团队、安全系统团队和安全团队的约十来名研究人员和工程师开展了技术访谈。为获得这种程度的访问权限，他们使用 OpenAI 配发的设备开展工作，设备始终留在办公场所内，两人在现场工作时也有人陪同。

METR、Redwood Research 和 OpenAI 设计本次测试，是为了试行向外部研究人员开放深入访问内部基础设施的权限，而非向公众充分公开 OpenAI 监测系统的相关信息。³ 因此，我们事先与 OpenAI 约定，只发表一篇较短的文章，概括介绍这项工作。在今后开展此类测试时，我们预计会遵循《我们与 AI 公司合作的方式》介绍的透明度和独立性最佳实践，让公众能更充分地了解相关信息。

METR 和 Redwood 的两名员工在 7 月 21 日及此前的异步内部未对齐行为监测系统中发现了若干新漏洞。需要说明的是，OpenAI 在本次测试期间也在扩展其监测系统。这些发现描述的是我们评估过的 7 月 21 日及此前的历史系统，而不是扩展后系统目前的覆盖范围；本次测试并未确定后者。以下是本次测试部分发现的摘要示例：

• Responses API 为 Codex 等提供支持。⁴ 就能力至少达到 GPT-5.5 水平的模型通过该 API 产生的内部智能体流量而言，我们推算，测试当时约有 75–94% 符合监测条件。⁵ 不过，这一数值在两个方向上都有很大的不确定性。我们还推算，在用于内部 Codex 智能体的 Responses API 流量中，99.2% 符合监测条件。
• 我们获悉，3 月至 6 月期间，部分强化学习（RL）训练轨迹接受了未对齐行为监测；不过，测试开始时，强化学习训练任务并不在监测系统的覆盖范围内。
• 我们推算，2026 年 5 月至 7 月期间，未对上下文压缩事件进行监测，很可能导致约 10% 符合监测条件的内部 Codex 流量未受监测；不过，具体比例仍有很大不确定性，因为本次测试开展时，历史日志中缺少必要的信息，无法据此确定监测器的调用中有多大比例是由上下文压缩触发的。OpenAI 员工在测试开始前就已独立发现了这个问题，并在测试期间予以修复。
• 测试时，监测系统会在智能体把控制权交还用户时触发。因此，在上下文压缩事件不受监测的那段时间里，智能体只要不断采取行动，就可以无限期推迟接受监测。⁶
• 我们看到了有关监测系统出错率和负载卸载（load shedding）率的信息。从这些信息来看，测试当时，监测器出错的请求占比不到 0.2%；在测试期间的某一个 24 小时时段内，负载卸载次数为零。
• 我们发现了一种方法，Codex 智能体在原理上可以借此绕过 Codex 的沙箱机制和 Auto-Review，从而执行宿主机用户能够执行的任何操作。
• 我们还发现了一种漏洞利用方法，它能使近期数百个操作（包括该漏洞利用本身所涉及的操作）不受监控 [漏洞利用细节已由 OpenAI 删隐]。
• 智能体看到的运行轨迹与监测器看到的运行轨迹，在序列化方式上有差异。我们发现，智能体很可能可以利用这种差异，构造输入让监测器出错，导致相应运行轨迹不会被提交人工审查。
• 我们发现了两个相互独立、可由客户端控制的请求头，它们都能禁用针对新智能体的监测。这可能让智能体启动一个不受监测、但其他方面完全相同的新实例。不过，设置这些请求头、创建新智能体实例的行为，仍可能被监测系统发现。
• 我们发现了两种不受监测的内部智能体工具，它们原本被认为只有只读权限。我们找到了一种简单的漏洞利用方法，可能用来突破这些限制，在各自的沙箱环境内执行任意操作。我们没有验证这种行为、没有测试该漏洞在实践中能否利用。
• 我们已经核实：除少数影响较小的例外，监测系统看到的是智能体所见的完整运行轨迹。
• 我们验证了监测系统的提示词会查找暗中谋划、颠覆监测系统、蓄意破坏、数据外泄、欺骗以及入站和出站提示注入等多类风险。

测试结束后，OpenAI 表示，我们发现的漏洞中，凡是影响其生产环境安全防护体系的，都已修复。OpenAI 还介绍了后续对其监测系统预期覆盖范围所作的重大调整。我们没有核实这些说法。

根据这些发现，我们提出了一些监测和控制系统在设计上应追求的目标，概述如下。总体而言，我们认为，未来的监测基础设施应能抵御内部高能力智能体大规模、有策略且持续发起的蓄意攻击。

• 提高规避监测的难度。 要发出不受监测的请求，应当先得到明确批准，才能使用指定的一组组织账户／API 密钥；这组组织账户／API 密钥不得用于智能体推理。应每隔 N 条消息或 N 分钟监测智能体一次，而不是等到智能体结束回合才监测。
• 确保应受监测的流量确实受到监测。 详细记录全部推理活动及其中受到监测的部分，定期把这些日志与监测系统自身的日志直接交叉核对，确保所有应受监测的流量确实受到监测。持续维护一份清单，列出所有已知的绕过监测的方法。确保监测器与智能体看到相同的上下文。
• 快速、可靠地响应事件。 明确事件响应由谁负责，并保持相关指引清晰，以减少主观性。尽可能多地保留推理流量和监测器流量的日志，确保日志防篡改、便于检索。
• 主动对监测系统开展红队测试。 定期开展控制评测，查找监测系统中可利用的程序缺陷，并建立评估策略性串通的方法。
• 确保智能体与监测器相互隔离。 应尽可能让智能体运行框架所处的环境，与执行工具调用的环境相隔离。智能体采取的操作，不应影响监测系统是否运行、何时运行。通常，不应允许智能体访问监测系统的设计或代码。

上述深入访问权限，加上 OpenAI 员工在后勤和技术方面的大力支持，为本次测试提供了重要帮助。