OpenAI 将 250 人安全冲刺转化为持续运行的 AI 防御工厂
OpenAI 表示，其网络安全模型帮助修复了数百个系统中的漏洞，并由此启动了一项持续运行的基于智能体的防御计划。
文章目录 · 11
OpenAI 表示，公司动员了超过 250 名员工，利用 Codex 和专用网络安全模型支持漏洞发现、分级处置、修复和验证，从其数百个系统中发现并修复漏洞。该公司现已公布从这次内部安全冲刺中发展而来的架构和运行流程，并将由此形成的系统称为其“防御工厂”。
此次披露包含了异常具体的运行结果。OpenAI 表示，团队在冲刺首日关闭了 53 个紧急或高优先级问题；将发现结果分派给责任方时，接受率达到 90.6%；37% 的发现结果被归类为重复项；动态验证后的误报率降至 0.81%。
这些数据描述的是一项内部防御计划，而非已披露的外部入侵事件。OpenAI 尚未说明受影响的服务，未公布漏洞总数或严重程度分布，也未提供每项报告比率背后的分母和测量周期。因此，其结果无法根据已发布材料独立复现。这次披露的重要性在于其运行模式：安全工作正被重组为持续运行的智能体工作流，而不是一系列定期扫描和人工交接。
一、安全冲刺覆盖超过 100 个服务领域
OpenAI 将最初的工作描述为一次内部“红色警报”，汇集了其安全、应用和研究组织。超过 250 人参与其中，工作覆盖了超过 100 个服务领域，涉及数百个系统。
这次冲刺开始时，OpenAI 尚未拥有这些系统的完整地图。Codex 协助建立资产清单，团队则将已有安全发现结果导入共享待办列表。服务归属数据、部署配置、云端记录、源代码和暴露端点被逐步关联，以便智能体确定每项发现结果应交由哪个团队处理。
OpenAI 报告称，这一过程带来了 90.6% 的责任归属接受率。人工审查人员持续处理模糊案例，而紧急修复工作在清单尚未完成时便已推进。这种并行方式使团队得以在首日关闭 53 个紧急或高优先级问题。
智能体还依据严重性标准对发现结果进行评估。OpenAI 表示，早期分类并不一致，并且对提供给模型的指令较为敏感。该公司对此采取的措施包括对提示词和标准进行版本管理，增加可重复的评估，记录审查人员预期的优先级及其推理，并保留人工抽查。
去重也成为另一项明确关卡。OpenAI 曾暂时暂停自动分派，直到该流程得到改进，最终确定其检查的发现结果中有 37% 为重复项。这一点很重要，因为一个仅仅生成更多报告的智能体系统，可能会增加安全工程师的负担，却无法降低风险。
动态验证用于将可复现的漏洞与静态分析噪声区分开来。智能体获得了部分选定服务的可运行版本，并尝试在受控环境中复现疑似问题。OpenAI 报告称，此阶段后的误报率为 0.81%，但未披露经验证样本的规模或构成。
二、防御工厂采用五阶段智能体循环
防御工厂并非被描述为单一模型或漏洞扫描器。它是一种参考架构，将现有源代码控制系统、安全扫描器、问题跟踪器、开发环境、公司特定上下文和 AI 智能体连接起来。
其工作流包含五个循环往复的阶段：清单、发现、动态验证、责任归属分派和经验证的修复。
清单智能体协调云资源、部署配置、源代码、暴露端点和服务归属记录。随后，发现智能体将该清单与威胁模型、安全政策、源代码以及从 Snyk 或 Wiz 等工具导入的发现结果结合起来。输出结果仍是候选漏洞池，而不是已确认缺陷清单。
在动态验证期间，智能体检查相关代码，并尝试在可运行的应用程序中复现每个候选项。OpenAI 的规范指出，仅靠静态追踪并不足够：经验证的漏洞必须包含复现证据。被证伪和结论不明确的发现结果仍会附在记录中，而在跟踪器中创建问题则需要批准。
责任归属智能体将经验证的发现结果与资产清单、代码所有者文件、提交历史、内部通信和问题跟踪器关联起来。OpenAI 将分派与确认区分开来，避免将自动路由的工单视为已被接受的工作。
在最后阶段，Codex 准备补丁，并在可复现环境中检查其行为。经过人工审查和获授权部署后，一项独立检查会重新测试生产环境中的修复。已合并的拉取请求或已移动的工单不被视为修复证据；验证失败或结论不明确会使问题保持开放状态。
共享的 SECURITY.md 文件在各个周期之间承载系统特定知识。每次运行都可以复用映射关系、归属信息、调查证据和先前验证检查，而无需重新构建这些上下文。该公司表示，具有重大影响的变更仍会接受人工审查，已部署的修复也会被独立验证。
三、隔离与访问控制是安全边界的一部分
OpenAI 的架构将控制平面与数据平面分离。控制平面负责工作负载编排、政策执行和凭证访问。数据平面则提供隔离的开发环境，智能体可在其中运行应用程序、复现漏洞并测试补丁。
这些环境旨在实现短暂性：每次运行均从一个新环境开始，其状态随后会被丢弃。这降低了一项调查污染另一项调查的风险，也使重复验证更加可靠。
该架构还将源代码控制、密钥存储、制品注册表和模型端点置于组织的私有网络内。资产清单和发现结果数据库保存工作流状态，而主机监控、基础设施安全和智能体审计系统则监督整个管道中的活动。
OpenAI 表示，公司以渐进方式提高自主性。它先从小批量和人工审查开始，随后在结果变得更可靠后移除了重复性的人工步骤。授予智能体的权限与其可执行的分析工作量彼此分离。
这种区分在修复期间尤其重要。OpenAI 表示，智能体生成了此次冲刺中的每一个补丁，并将修复描述为“100% 基于 Codex”，但人员仍负责具有重大影响的审查和获授权部署。报告的修复回滚率为 0.53%，但该公司尚未公布该百分比所代表的补丁原始数量。
后续检查还发现，修复已合并与修复抵达所有已部署系统之间存在差距。OpenAI 扩大了部署后验证，但在最初阶段保持自动重新开启功能禁用，同时研究如何区分修复失败与正常的部署延迟。
四、可迁移的成果是验证管道，而非人数规模
OpenAI 的核心主张是，防御方可以在攻击者获得可比访问能力之前，利用私有代码、部署上下文、归属记录和更强的前沿模型。其防御工厂旨在将这一优势转化为发现与经验证修复之间更短的周期。
Cloudflare 也曾单独描述过一种类似的多智能体漏洞工具链。其管道为侦察、搜寻、对抗性验证、去重、依赖追踪和补丁准备分别使用不同智能体。它要求生成的修复在进入生产环境前获得人工批准，并将可复现测试视为一道关卡，而非信任模型的书面评估。
这一独立实现支持了底层工作流模式，同时也说明了其成本。Cloudflare 表示，大规模扫描可能需要数小时、需要由 50 到 200 名工作者组成的资源池，并将运行瓶颈从发现缺陷转移到审查和安全部署修复。持续的智能体活动并不会消除对应用所有者、可靠测试环境、发布工程或安全判断的需求。
对于考虑采用 OpenAI 设计的组织而言，最具体的改变是流程上的。候选发现结果必须先去重并复现，才能送达工程师；责任归属必须与当前运行记录绑定；补丁必须通过回归检查；修复必须在部署后得到验证。缺少这些关卡时，增加智能体可能只会加速报告产出，而非减少漏洞。
对底层模型的访问也并不统一。OpenAI 发布的架构列出了包括 Astra、Sol、Terra 和 Luna 在内的通用模型，以及 Daybreak Blue 和 Daybreak Red 安全模型。更宽松的网络安全能力通过 Daybreak 向经过验证的防御方提供，同时配有更严格的身份验证、范围控制、监控和监督。
因此，已发布材料是一种参考架构和内部案例研究，而不是任何组织都能立即复现 OpenAI 结果的证据。OpenAI 提供了性能指标和工作流细节，但没有提供足够的漏洞级数据，无法将其系统与传统安全计划进行比较，或独立评估检测覆盖范围。
常见问题
OpenAI 是否在应对已确认的外部入侵事件？
不是。OpenAI 将这项工作描述为一次内部安全冲刺，并未表示防御工厂公告涉及新的外部入侵。
防御工厂的作用是什么？
它将资产清单、漏洞发现、运行时验证、责任归属路由、补丁生成和部署后验证连接为一个循环运行、由智能体辅助的工作流。
AI 智能体是否未经人工批准就部署修复？
OpenAI 表示，Codex 生成了补丁，但具有重大影响的变更仍须接受人工审查和部署授权。随后，生产环境修复会被独立重新测试。
OpenAI 发现了多少漏洞？
OpenAI 尚未公布总数。它报告称首日关闭了 53 个紧急或高优先级问题，但未披露发现结果的完整数量或严重程度分布。
任何组织都能使用相同的网络安全模型吗？
并非自动可以。OpenAI 引导获授权的防御方通过 Daybreak 申请，在该平台上，对能力更强或限制更少的网络安全工具的访问取决于验证、范围控制和监督。
参考来源
Share
分享这篇文章
