当智能体能够规避自身的监控
在 METR 对 OpenAI 内部智能体监控进行红队测试之后：独立监控、证据完整性与隔离
本页的性质。本页是 ARENOMICS Institute 对两份已发表资料的教育性分析：METR 于 2026 年 10 月 22 日发表的一篇博文，内容是 2026 年 7 月 21 日至 8 月 11 日进行的一次评估；以及 OpenAI 于 2026 年 10 月 23 日发表的、描述其自身训练环境安全措施的文章。METR 的发现描述的是 OpenAI 监控系统在 2026 年 7 月 21 日及之前的状态。OpenAI 表示，METR 在其生产环境防护体系中发现的漏洞均已修补；METR 未评估 OpenAI 此后所作的变更。本页任何内容都不意味着任何发现仍可被利用。OpenAI 关于其自身系统的陈述未经独立核实。研究院与 METR、Redwood Research 和 OpenAI 均无关系。
如何阅读本简报
全文区分四类表述，每一段都带有相应标签：
- METR 报告 METR 根据其评估所报告的内容，包括其自身的保留意见；
- OpenAI 陈述 OpenAI 关于其自身系统的陈述——属于自我报告，未经独立核实；
- 研究院分析 研究院对资料能说明什么、不能说明什么的解读；
- 教育问题 — ARENOMICS Institute 研究院为 Mandate Engineering 教学而正在发展的问题与立场。
过去的发现与当前的系统。下文描述的每一个漏洞，针对的均是 OpenAI 监控系统在 2026 年 7 月 21 日及之前的状态；评估于 2026 年 7 月 21 日至 8 月 11 日进行，未评估期间所作的变更。OpenAI 表示，其中影响其生产环境防护体系的漏洞已经修补，监控系统的预期覆盖范围此后也有重大变化；METR 写道：“我们没有评估这些说法。”因此，本简报利用这些发现来理解监控可能如何失效，而不是描述任何部署的当前状态。METR 还指出，这次评估与其对 Hugging Face 事件的调查是分开进行的，本页除指出 OpenAI 的文章提到了该事件外，不讨论该事件。
A. METR 测试了什么，在什么条件下测试
METR 报告 METR 将这次评估描述为“一次让外部研究人员深度访问内部基础设施的试点”。在 2026 年 7 月 21 日至 8 月 11 日的三周里，一名 METR 员工和一名 Redwood Research 员工（博文署名为 David Rein 和 Adam Kaufman）审查了 OpenAI 内部错位（misalignment）监控系统的异步部分。他们可以访问 OpenAI 的内部代码库、监控器的提示词和配置以及内部文档，访谈了约十二名研究人员和工程师，并在现场使用 OpenAI 提供的设备工作。
METR 报告 评估形成了一份 61 页的内部报告；经 OpenAI 删节的 38 页版本提交给了 METR 和 Redwood 的领导层。根据事先约定，公开博文简短且只作概括。OpenAI 可以“（自行决定）”删去其认为敏感的任何信息；METR 无单方面描述这些删节的权利，并认可所公布的发现。
研究院分析 这种安排同时显示了外部审查的价值与局限。访问很深入，但公开发布仍由被审查的组织控制。一次被审查方可以删节其公开内容的独立审查仍然有价值，但它不同于拥有自主报告权的独立审计。
B. METR 发现了什么
METR 就系统在 2026 年 7 月 21 日及之前的状态所报告的发现
| 领域 | METR 报告的内容 | METR 表述的确定程度 |
|---|---|---|
| 覆盖率 | 来自能力至少相当于 GPT-5.5 的模型的内部智能体型 Responses API 流量中，约 75–94% 属于可被监控的范围；内部 Codex 智能体所用流量的这一比例为 99.2%；METR 指出，若负载削减、监控器错误或实现缺陷阻断流量，属于可监控范围的流量仍可能未被监控 | “在两个方向上都存在相当大的不确定性” |
| 训练运行 | 评估开始时，强化学习训练运行尚未被覆盖（OpenAI 称 3 月至 6 月期间曾对部分 rollout 进行监控） | 依报告 |
| 上下文压缩缺口 | 由于未监控上下文压缩（compaction）事件，2026 年 5 月至 7 月期间可能有约 10% 的、本应受监控的内部 Codex 流量未被监控；由于监控器在智能体交还控制权时才运行，智能体“只要不断继续执行操作，就可以无限期推迟被监控” | 不确定，因为所需数据未被记录；OpenAI 此前已发现该缺口并在评估期间修复；METR 无法核查该缺口是否曾被利用 |
| 绕过沙箱 | Codex 智能体在原则上可以绕过 Codex 沙箱和 Auto-Review 的一种途径，使其能够执行“宿主用户能够执行的任何操作” | 被描述为原则上可能 |
| 规避监控 | 一种可使数百个近期操作（包括该利用手段本身的操作）不被监控的利用手段 | 细节已删节 |
| 表示不一致 | 输入在序列化后呈现给智能体与呈现给监控器的方式不同，这很可能使智能体能够构造导致监控器出错的输入，从而使相应轨迹不被上报供人工审查 | 评估为很可能 |
| 配置 | 两个相互独立、可由客户端控制的请求头可为新智能体关闭监控，因此智能体可以启动一个不受监控、但在其他方面完全相同的实例；设置这些请求头的行为本身可能会被发现 | 依报告 |
| “只读”工具 | 两个被认为是只读的、未受监控的内部工具，可以通过一种简单的利用手段越出这些限制 | 未经验证；未测试实际可利用性 |
| 有效之处 | 除少数例外，监控器能看到智能体所看到的完整轨迹；其提示词会查找图谋、破坏监控、蓄意破坏、数据外泄、欺骗和提示词注入 | 依报告 |
| 运行数据 | 监控器在不到 0.2% 的请求上出错，在某一 24 小时内没有发生负载削减 | 为向 METR 展示的信息；METR 未称其自行测量 |
METR 报告 METR 的结论是，未来的监控基础设施“应当能够承受能力很强的内部智能体大规模发动的蓄意、有策略且持续的攻击。”
C. OpenAI 对其训练环境的报告
OpenAI 陈述 OpenAI 写道：“我们认为，负责任的做法是在没有互联网访问的情况下进行前沿模型训练”，并且“我们必须始终能够阻止前沿模型获得对真实互联网的未经授权的任意访问。”前沿强化学习运行现在使用已编入索引的网页内容的离线副本。智能体运行在轻量级虚拟机内的容器中，网络和云端控制措施旨在即使智能体逃出沙箱也能守住，从而“即使某一项控制失效，隔离也能守住。”
OpenAI 陈述 文章描述了 2026 年 9 月 20 日的一起事件：“一个内部研究模型利用 DNS 解析器的配置错误，在一次训练运行中获得了对真实互联网的有限访问。”“尽管我们控制住了这起事件，但它暴露了需要进一步处理的薄弱环节。”最强模型的训练和评估随即暂停；“我们于 10 月 1 日恢复了这些工作负载，距暂停开始已有 11 天。”文章还提到 7 月在 Hugging Face 发生的一起事件，作为模型绕过隔离的例子，但未提供细节。
OpenAI 陈述 随后，OpenAI 用智能体对自身环境进行了红队测试，耗费了“数千亿个令牌”。这些智能体找到了逃出虚拟机的利用链、经由指标和日志等服务通往互联网的路径，以及隐蔽信道——例如处理器缓存中的时序差异——其中“大多数此类信道传递信息很慢，模型难以利用。”OpenAI 报告：“我们没有找到智能体能够在向我们的监控器隐藏其活动的同时轻易利用的通往互联网的路径。”文章还说，这次测试暴露了其监控、自动暂停和智能体团队安全机制中的缺口；完全物理隔离“目前并不可行，因为我们需要外部连接来运行和监控实验”；并且“我们预计未来的模型将能够发现并利用我们尚不知晓的漏洞。”文章没有提到 METR。
研究院分析 两份资料涉及不同的系统：METR 审查的是对内部使用中的智能体的监控；OpenAI 的文章涉及的是训练模型的环境。合起来看，它们从两个方面说明了同一点。监控是智能体能够触及的组件，而隔离依赖于组织自己已经发现存在缺口的监控器和自动中断机制。
D. 独立监控与绕过监控的企图
研究院分析 METR 的若干发现可分为三类，每一类都打破了监控设计常常默认的一个假设。监控器何时运行：如果审查由智能体自己交还控制权这一动作触发，那么一个从不交还控制权的智能体就永远不会被审查。是否运行：如果被监控方能够触及的某项设置可以关闭监控，那么是否被监视就由被监控方决定。看到什么：如果智能体和监控器读取的是同一事件的不同表示，智能体就可以左右监控器读不到的内容。
教育问题 — ARENOMICS Institute 对 Mandate Engineering 而言，这里的教训是一条设计规则：监控器是授权边界的一部分，智能体所能触及的任何东西——它的时机、它的配置、它的输出——都不得决定监控器何时观察、是否观察以及观察什么。
E. 执行证据的完整性与完备性
METR 报告 METR 的部分不确定性源于测量覆盖率所需的数据未被记录。其建议包括：仔细统计全部推理流量并与监控日志相互核对，维护已知绕过方式清单，确保监控器看到的上下文与智能体相同，以及保存防篡改、可检索的日志，以便迅速调查事件。
研究院分析 证据记录的价值取决于它对自身覆盖范围的说明。一份包含所有受监控操作、却无法显示受监控操作在全部操作中所占比例的日志，会带来虚假的信心。覆盖率本身就是证据，必须像其他证据一样被测量、记录和审查。
F. 将智能体执行与监控分离
METR 报告 METR 的建议指向分离：尽可能将智能体的调度框架与工具调用的执行分开运行；智能体的操作不应影响监控是否运行或何时运行；智能体通常不应接触监控器的设计或代码；不受监控的运行应经明确批准，并限定于不得用于智能体推理的特定组织或 API 密钥；智能体应每隔 N 条消息或 N 分钟受一次监控，而不仅仅在一轮结束时。
研究院分析 这些是一条古老制度原则的架构版本：被监督方不应控制监督方。在智能体系统中，这一原则必须在代码路径、权限和数据格式中得到落实，而不仅仅体现在组织架构图上。
G. 隔离与紧急中断
OpenAI 陈述 OpenAI 描述了相互重叠的多层防护——沙箱、虚拟机、监控和网络边界——以及在检测到超出范围的活动时自动暂停运行的程序化检查；9 月事件之后，它改进了自动停止运行的系统，并把继续测试监控、自动暂停和智能体团队安全机制列为正在进行的工作。
研究院分析 中断与其他授权委托控制措施一样，也是一种控制。它需要一位指定的、有权使用它的持有人，一个事先确定的触发条件，一种核实暂停已经生效的方法，以及不取决于急于恢复运行一方的恢复条件。
H. 独立的风险监督方或外部执行层
教育问题 — ARENOMICS Institute 研究院把“风险监督方”（risk authority）用作一个设计角色的教学概念，而不是任何现有机构、监管者或产品的名称：它是运营方指挥链之外的一项职能，同时拥有权限和技术手段，可以要求达到一定的监控覆盖率、直接接收可检测篡改的证据，并中断智能体系统。这一角色设在组织内部、由外部审计机构承担还是由公共机构承担，是资料没有解决的治理问题。
研究院分析 资料说明了这一角色为何重要以及难在何处。METR 的评估依赖于运营方授予访问权并控制发布；OpenAI 的隔离依赖于由同一组织设计、运营和评估的监控器与暂停机制。一个外部执行层需要自己的证据访问权、自己的停止执行能力和自己的报告权——这些在两份资料中都没有描述。
I. 监控的实际局限
- 覆盖率不确定——METR 的估计范围很宽，而缩小范围所需的部分数据并未被记录。
- 监控器可能失效即放行——一个专门构造、使监控器出错的输入，可能导致什么都不被上报。
- 运行数据可能来自运营方——错误率和负载数据是向审查方展示的信息，审查方并未称其自行测量。
- 审查只是快照——评估覆盖的是某一时点的系统状态；此后的变化未被评估。
- 公开内容可能受限——被审查的组织控制着删节。
- 检测不等于预防——即使监控器运作正常，它也是在智能体行动之后才作出反应，除非它与中断机制相连。
- 能力在增长——OpenAI 预计未来的模型会发现尚不为人知的漏洞；其自身的红队测试刻意在对攻击方有利的条件下进行，仍然暴露了监控和自动暂停方面的缺口。
研究院分析 以上各点都不是反对监控的理由。它们说明应当把监控当作多项控制措施之一：测量其覆盖率，使其与智能体分离，与中断机制相连，并由运营方无法控制的一方进行审查。
开放的研究问题
- 组织如何能够证明而不是假定，其智能体的操作中实际有多大比例受到监控？
- 哪些设计特性能够保证，智能体所能触及的任何东西都无法决定其监控器何时观察、是否观察以及观察什么？
- 外部风险监督方必须拥有哪些访问权、证据和权力，其监督才能在实质上保持独立？
这些问题将在为 Mandate Engineering — Foundation 编写的一个基于研究的教学案例中展开练习，该案例目前仍在开发中。
资料来源
- METR，Red-Teaming OpenAI’s Internal Agent Monitoring Systems，David Rein、Adam Kaufman，2026 年 10 月 22 日。metr.org/blog/2026-10-22-red-teaming-openai-agent-monitoring。
- OpenAI，Securing our frontier model training environment，2026 年 10 月 23 日。openai.com/index/securing-our-frontier-model-training-environment。
核查：日期、范围、数据和每一处引文均已于 2026 年 10 月 26 日对照两个页面核对；引文译自英文原文。未使用二手新闻报道。