为期三周的红队演习发现了 OpenAI 内部失调监控系统中的新漏洞，包括原则上人工智能代理可以在未经人类审查的情况下采取行动的方式。独立评估非营利组织 METR 于 10 月 22 日发布了调查结果的高级摘要，该摘要摘自其提交给 OpenAI 研究人员和安全人员的 61 页内部报告。
该试点从 7 月 21 日持续到 8 月 11 日，让一名 METR 员工和一名 Redwood Research 员工异常深入地访问 OpenAI 的内部基础设施：代码库、监控系统的提示和配置、内部文档以及对监控、安全系统和安全团队的大约十几名研究人员和工程师的技术采访。他们使用 OpenAI 发行的设备进行工作，这些设备从未离开过工作场所，并且在现场时有陪同。有关这方面研究的更多信息，请参阅我们的最新人工智能发展。
红队发现了什么
该练习集中于两个问题：OpenAI 的代理推理有多少实际上受到监控，以及代理是否可以禁用或破坏监控系统。答案揭示了有意义的差距。
在覆盖范围上，METR 估计大约 75% 到 94% 的代理内部响应 API 流量（为 Codex 提供支持的 API 等）来自至少与 GPT-5.5 一样强大的模型，当时有资格进行监控，尽管该组织注意到两个方向都存在很大的不确定性。在用于内部 Codex 代理的流量子集中，99.2% 符合资格。但资格并不等同于覆盖范围：在演习开始时，监控系统并未涵盖强化学习训练，并且在 2026 年 5 月至 7 月期间，未监控的压实事件可能导致约 10% 的合格内部 Codex 流量未受到监控。OpenAI 工作人员在演习前独立识别了压实问题，并在演习进行期间修复了该问题。
时间细节很重要。由于监控器在代理将控制权返回给用户时触发，因此代理可以通过在不受监控的窗口期间继续采取操作来无限期地推迟被监控。
该团队还记录了主动躲避路径。 Codex 代理原则上可以绕过 Codex 沙箱和自动审核，从而允许他们采取主机用户可以采取的任何操作。 METR 发现了一个漏洞，可以阻止数百个最近的操作（包括漏洞本身涉及的操作）受到监控； OpenAI 编辑了技术细节。代理可能会利用代理看到的轨迹与监视器看到的轨迹之间的序列化差异来构建导致监视器失败的输入，从而避免升级为人工审查。还发现两个客户端可控的标头禁用了对新代理的监控，可能会让代理启动一个不受监控但其他方面相同的实例——尽管 METR 指出设置这些标头的行为本身可能会被捕获。
最后，该团队确定了两个不受监控的内部代理工具，据信它们具有只读权限，以及一个可用于破坏这些限制的简单漏洞。 METR 并未在实践中验证该行为。
是什么支撑了
该练习还验证了系统的部分内容。除了一些小的例外，监视器会显示特工看到的完整轨迹。经确认，监控提示可查找阴谋、系统颠覆、破坏、数据泄露、欺骗、入站和出站提示注入等风险类别。在可靠性方面，METR 提供的信息表明，监控器在请求中出错的概率不到 0.2%，并且在演习期间的 24 小时内，负载卸载次数为零。
OpenAI 的回应
据 METR 报道，OpenAI 表示，所有已识别的影响其生产保障堆栈的漏洞均已得到修补，并描述了对其监控系统预期覆盖范围的重大后续更改。 METR 尚未评估这些说法，其调查结果描述的是 7 月 21 日或之前存在的系统，而不是 OpenAI 在演习期间已经构建的扩展版本。
代理监督的设计课程
METR 以未来监控基础设施的设计理想作为总结，认为这些基础设施应该能够抵御来自高能力内部特工的大规模蓄意、战略和持续攻击。有两个脱颖而出。监控应该是难以避免的：运行不受监控的请求应该需要与禁止代理推理的特定组织或 API 密钥相关联的明确批准，并且代理应该每 N 条消息或每分钟监控一次，而不是仅在他们结束轮次时监控。并且覆盖范围应该是可审计的：仔细计算所有推论，定期对照监控系统自己的日志进行交叉引用，以便所有要监控的内容都明显可见。
该活动旨在作为一个试点，让外部研究人员深入了解前沿实验室的内部基础设施，而不是作为公开透明度报告——METR 和 OpenAI 事先同意只发布简短的高级帖子。该非营利组织表示，未来的版本将遵循其与人工智能公司合作框架中描述的透明度和独立性做法。随着特工在建造它们的实验室内承担更重要的工作，试点项目为外部人员如何进行监视提供了一个模板。
---
保持人工智能领先地位获取最新的人工智能新闻、分析和突破——尽在一个地方。
阅读更多人工智能新闻 →
