图片：METAL
摘要
- OpenAI 表示，公司内部拉响红色警报，投入250多人，在100多个服务领域中查找、验证并修复漏洞，开展了一次安全冲刺。
- 公司公布了具体数字：首日处理紧急和高优先级问题53件，发现项中37%为重复，19.5%在运行时得到复现，动态验证后误报率为0.81%，责任人分派接受率为90.6%，回滚率为0.53%。
- 随着基于广泛流通的开放权重模型的智能体已能把多个漏洞串联起来发起自主攻击，公司主张防守方必须在留给自己的时间窗口关闭之前行动。
开发 ChatGPT 的 OpenAI 表示，公司内部拉响红色警报，对自家全部系统开展了一次彻底排查的安全冲刺。投入人力超过250人，覆盖范围超过100个服务领域。公司把这次工作所用的参考架构和执行顺序以 Defense Factory 之名公开。这是一份连竞争对手都能看清它如何重建自身安全体系的文件。
公司之所以着急，是因为攻击一方的条件变了。OpenAI 解释说，使用广泛流通的开放权重模型的智能体，如今已能执行跨越长时间的网络作业。智能体若把会话之间学到的东西保留下来，就能细致掌握系统结构，并把彼此独立的漏洞串联起来。过去因为太费人力而难以尝试的连环攻击，现在可以自主运转。
不过公司主张，防守一方仍有时间。谈到防守方的结构性优势时，OpenAI 写道，防守方"可以让智能体直接访问自己的代码，并借助前沿模型抢在利用广泛流通的开放权重模型的攻击者之前"。能把整套代码全部敞开的只有防守方，能最先用上最新模型的也只有防守方。公司把这段时间差称为留给防守方的窗口，并明确表示，若不立即行动，窗口就会关闭。
这次冲刺是按真出了事故的方式推进的。安全、应用和研究团队被集中到一起，数百个系统同时铺开。OpenAI 核心产品与平台负责人 Tibo Sottiaux 说，公司正"以应对事故时同样的紧迫感强化防御体系"。他补充说，这项工作的优先级高于除核心业务运营之外的其他所有事务，冲刺结束后也会保持同样的紧迫感。仅首日就处理了紧急或高优先级问题53件。
METAL 通读的这份公开文件，把不顺利之处的数字也一并写了出来。起初严重程度分类的范畴过宽，结果会随着交给智能体的指令而摇摆。公司为评估标准和提示词标注版本，并记录下审阅者期待的优先级及其判断依据之后，才转入批量处理。这个过程中确认发现项中有37%为重复，在去重效果改善之前，责任人分派被完全暂停。
验证阶段的数字更为具体。在搭建出智能体可以真正运行代码的隔离环境之后，发现项中有19.5%在运行时得到复现，经过这道动态验证后的误报率为0.81%。找到归属团队并转交后被接受的比例升至90.6%。编写补丁的也不是人而是 Codex，部署后被回滚的修复占0.53%。
公司承认的局限也一并写明。搭建隔离环境这件事本身就是验证的瓶颈，因此只能从少数可重复运行的服务入手。合并的补丁与实际部署到全部服务器上的修复之间存在差异，这一点是后来才发现的；由于尚未确定如何计入部署延迟，自动重开功能处于关闭状态。自主权也不是一次性交出去的，而是从小批量加人工审阅开始，随着信任积累才逐步放宽。
从法律的视角看，这份文件最重要的部分不是性能数字，而是控制结构。OpenAI 表示，它把智能体能够做到的范围与实际获准更改的范围分开管理。审计痕迹也内置于设计之中，主机活动、基础设施安全和智能体审计各自留存记录。事故发生后要能回溯谁在何时批准了什么，责任归属才理得清，而这份设计是在组织设计层面先行解决这一要求，而非依赖工具。
这次发布同时也是 OpenAI 近来主推的防御业务的内部记录。METAL 曾报道过该公司决定向资源不足的防御机构提供价值10亿美元的 Daybreak 使用权一事，而这份文件更接近于把那套工具先对准自家公司的结果。公开材料中提到，Cloudflare、Ramp 和谷歌的团队也在探索同样的做法。公司预告，关于技能与安全工作流的技术博客文章即将发布。
概括来说，OpenAI 对自家系统开展了事故级别的安全冲刺，并把由此得出的数字连同失败一起写进了参考架构对外公开。它提出的主张是把防御从一次性检查变成持续运转的循环，循环的大部分由智能体驱动，而边界与例外由人把握。接下来有两件事值得看。预告的技术博客文章究竟会公开多少技能与工作流，以及照此做法推进的组织能否得出相近的误报率与回滚率。
评论