外部评估揭示 OpenAI 智能体监控缺口

AI 智能体的操作经过监控，不代表每次操作都能被监控捕获。METR 和 Redwood Research 对 OpenAI 内部系统的一次试点评估发现，有漏洞可让智能体的数百次操作逃过监控；研究人员还发现了 Codex 绕过安全限制、获得与用户相同完整操作权限的潜在途径。

这条消息最该关注的，是监控遗漏与权限越界这两类问题。OpenAI 表示，影响实际运行系统安全防护的漏洞已经修复，但两家机构尚未核实修复效果。对使用 AI 编程工具的开发者来说，这个区别直接影响我们该信任哪一层防护。

逃过监控和获得完整权限，是两件事

据 IT之家 10 月 23 日转述路透社的报道，METR 和 Redwood Research 于当地时间 22 日介绍了此次评估。评估在 7 月 21 日至 8 月 11 日进行，对象是 7 月 21 日及之前的监控系统。

报道披露了两类发现。

一类是监控系统中的漏洞，其中一项可被 AI 智能体利用，使数百次操作逃过监控。它说明监控存在覆盖缺口，但报道没有给出操作总数、具体操作内容和绕过方式，因此无法计算漏检比例，也无法判断这些操作分别会造成什么后果。

另一类涉及 Codex：研究人员发现了绕过安全限制的潜在途径，可能使其获得与用户相同的完整操作权限。这里的关键词是「潜在途径」。报道没有交代触发条件，也没说这一问题是否已经在实际运行环境中造成权限越界。

监控能否发现操作，与系统是否允许操作，需要分别验证。

开发者可以把它理解为两道检查：一道决定智能体能做什么，另一道观察它做了什么。报道没有说明两个发现之间存在怎样的技术联系，不能把它们拼成一条已经完整复现的攻击链。

外部研究员看到了内部，但公开结论仍有边界

这次评估的价值，在于研究人员能够深入访问内部基础设施。

METR 和 Redwood Research 各派出一名研究员，可以查阅 OpenAI 的内部代码和文档，并与部分技术人员交流。相较于只通过产品界面测试，这种「嵌入式」评估有机会检查实现层面的防护，而不只是观察模型回答是否合规。

访问同时受到严格限制：两人在现场始终有人陪同，使用 OpenAI 提供的设备，设备不得带离办公场所。这些安排对应着 AI 企业的一项顾虑：外部人员获得内部访问权后，专有信息可能泄露给竞争对手。

两家机构最终提交了完整的 61 页内部报告，但只公开结果概要，并允许 OpenAI 删除敏感内容。此次它们无权自行公开被删减部分的具体信息，也表示希望未来评估更透明。

因此，公众能够知道「发现了什么类型的问题」，却无法依据报道独立复现、判断漏洞严重程度或检查修复。原文没有代码、模型版本、API 或配置参数，不能据此推导出一套针对当前 Codex 的复现步骤。

我的判断

这次评估支持一个务实判断：让外部研究人员接触内部实现，确实可能发现内部防护遗漏。报道给出了漏洞发现作为证据，但没有与其他评估方式的对照数据，无法进一步证明这种方式效率更高，或已经足以覆盖主要风险。

修复状态也要分清来源。OpenAI 告知两家机构，影响实际运行系统安全防护的漏洞均已修复；两家机构尚未核实修复是否有效。因此，现有信息支持「厂商报告已修复」，还不能写成「第三方确认问题已解决」。

时间边界同样关键。评估针对 7 月 21 日及之前的系统，OpenAI 在评估期间也在扩展系统。这是一段特定时期的检查结果，不能直接当作当前产品的安全结论。

对普通团队，更实际的取舍是把执行权限、操作记录和事后复核分别做好。行为监控有助于发现异常，权限限制则决定异常发生时能触及多大范围。不过，这是从报道引出的工程建议，原文没有提供不同防护方案的效果比较。

能拿来做什么

• 给 AI 编程智能体配置权限时，先列清任务实际需要的操作，避免因为开发者账号拥有某项权限，就默认智能体也应获得同样权限。
• 如果团队正在建设智能体监控，可以增加一类检查：把实际执行记录与监控捕获记录逐项核对，验证是否存在操作已经发生、监控却没有捕获的情况。
• 阅读安全修复公告时，分别记录问题发现时间、评估对象和修复验证方；对这次事件，应明确区分 OpenAI 的修复声明与尚未完成的第三方核实。