0.81% 假阳性率背后的五段闭环：OpenAI Defense Factory 架构拆解 (2026)

OpenAI 在 2026 年 9 月发布了关于内部安全自动化架构的系统性报告《The Defense Factory: Building continuous defense》，系统阐述了如何利用智能体构建全天候运转的持续安全防御体系。面对攻击者滥用具备长程执行能力的开源模型所发起的自动化攻击，OpenAI 提出防御方应当依托自身对全量代码与环境的白盒访问权，配合前沿模型构建主动防御流水线，牢牢守住“防御者时间窗口”。1 2

这项实践源于 OpenAI 内部发起的一场代号为紧急响应级别的跨部门安全冲刺。安全团队协同应用工程团队与研究团队，动员了超过 250 名工程师，在数百套服务系统中集中部署了由智能体主导的闭环防御实验。通过对系统资产测绘、漏洞扫描、动态复现、权属路由及验证式修复五个环节的重构，OpenAI 验证了自动化网络防御在超大规模企业级系统中的可行性与具体工程约束。1 3

为什么传统安全流水线接不住长程智能体

传统的应用安全流程（AppSec）长期存在数个结构性堵点。常规静态代码分析工具（如 Snyk、Semgrep）会持续扫描代码并产生海量候选告警；这些告警通常缺乏真实的运行时上下文，大量重复项混杂在低置信度结果中，迫使安全分析师在排查误报上耗费绝大部分精力。随后，告警需要人工寻找责任团队并录入工单系统，常常因组织架构变动或服务归属模糊而遭遇推诿搁置。最后，即使工程师修复了漏洞，修复代码也鲜少在线上生产镜像中获得独立的复现式回归测试。1 4

在攻击者开始调用具备工具调用与长程推理能力的大模型之后，这一静态、低频的人工流转模式受到了严峻挑战。自主智能体能够在多次交互中保留系统理解，自主串联散落在不同微服务中的轻微配置缺陷，拼装成复杂的利用链。由集群驱动的自动化渗透动作在执行速度与覆盖范围上，均已大幅超越人类安全团队的逐项工单响应周期。1 5

OpenAI 指出，面对这种机器速度的外部威胁，防御方拥有两项天然的不对称优势：

白盒访问特权：防御方可以授权智能体直接读取全量内部代码、依赖图谱、部署配置与生产监控数据，而外部攻击者通常只能依赖有限的黑盒嗅探。
前沿模型算力红利：防御方能够调用最尖端的基础模型与专门训练的安全模型，在推理深度与漏洞理解上保持对广泛流通的开源模型的代际领先。

这种由内部特权与前沿模型构成的领先期，构成了 OpenAI 所定义的“防御者时间窗口”。Defense Factory 正是为了将这两项结构性优势转化为工程化常态流水线而设计的系统架构。1 2

控制面与数据面：如何给防御智能体搭安全沙箱

让智能体进入核心生产代码库进行动态测试与补丁生成，面临着极高的安全与可用性风险。如果智能体直接在共享测试集群中运行攻击载荷，极易引发服务中断、环境状态污染甚至凭据外泄。

OpenAI 在私有网络中设立了明确分离的双平面架构，在赋予智能体充分执行自由的同时保持强隔离防护：

控制面（Control Plane）：负责跨系统的编排调度与边界防御。核心组件包括工作负载编排引擎（workload orchestration）、策略执行模块（policy enforcement）以及凭据代理（credential proxy）。智能体无法直接读取原始秘钥或云凭据，一切对外部 API、内部工单与代码仓库的调用均由凭据代理依据预设策略进行中继与权限阻断。
数据面（Data Plane）：为智能体提供瞬时（ephemeral）、完全可复现的隔离开发环境（development environments）。OpenAI 结合 Ona、Cloudflare 及 Modal 等技术构建了动态容器池。每个开发容器内部封装了三大核心模块：
- 智能体运行框架（Agent Harness）：负责加载模型上下文并管理执行生命周期。
- 安全技能插件（Security Skills）：包含漏洞扫描、分类判定、补丁生成等标准化可复用工作流。
- 目标应用程序（Application）：包含待测服务的真实代码、运行依赖与微服务模拟环境。
全局安全与审计体系（Security & Audit）：贯穿于主机活动记录（host activity）、基础设施安全策略及智能体操作审计日志，确保每个智能体在容器内部执行的每一条 Bash 命令与网络调用均具备完整追溯证据。

每个运行环境在任务启动时按需即时创建，并在测试结束后连同其内部状态彻底销毁。这种瞬时隔离机制从根本上杜绝了不同漏洞复现过程之间的相互污染，为后续的动态验证提供了确定性的物理基石。1

五段防御闭环：从资产测绘到验证式修复

Defense Factory 的核心执行逻辑由一个被称为“防御循环（The Defensive Loop）”的五阶段流水线驱动。五个环节依托代码库根目录下的 SECURITY.md 作为共享系统上下文，实现全链路的增量学习。1

1. 资产测绘（Inventory）

输入：云资产记录、源码部署配置、微服务归属元数据。
动作：Codex 智能体利用“构建与更新资产清单”技能，遍历组织内部所有云上资源，自动将公开暴露的网络端点与底层 Git 仓库、构建清单以及具体工程团队关联起来。
输出：结构化的高精资产清单（Asset inventory）。该清单直接作为后续漏洞扫描的唯一作用域，消除未纳入监控的影子资产。

2. 漏洞发现（Discovery）

输入：资产清单、最新源代码、威胁建模规范及组织安全策略。
动作：智能体加载 Codex Security 扫描插件与攻击路径分析器，沿网络拓扑和代码依赖链主动探测潜在薄弱环节，同时导入外部已知缺陷报告。
输出：候选漏洞池（Candidate vulnerabilities）。此阶段保持高召回率，将所有可疑线索汇聚于统一待办池。

3. 动态验证（Dynamic Validation）

输入：候选漏洞列表与可运行的应用测试容器。
动作：这是区分 Defense Factory 与传统代码扫描的决定性环节。智能体拒绝单纯依据静态调用图做出判断，必须在隔离环境中尝试编写 PoC 脚本并复现漏洞。只有能够在运行时确切观测到安全异常的案例，才会被标记为“已验证漏洞（Validated vulnerability）”；无法复现或缺乏充分证据的结果将直接打上标记退回，并执行跨仓库去重。
输出：附带确定性复现日志与攻击载荷记录的已验证漏洞档案。

4. 权属定界（Ownership Assignment）

输入：已验证漏洞档案、即时通信系统（Slack / Microsoft Teams）、组织架构归属数据库及工单追踪系统（Jira / Linear）。
动作：智能体调用归属判定与标签分配技能，结合代码提交历史、模块负责人记录与组织拓扑，精准计算受影响服务的第一责任团队，并自动创建结构化工单。
输出：指派给具体责任人的正式缺陷工单。OpenAI 在设计规范中明确强调：指派不等于确认认领（Assignment is not acknowledgment），系统仍保留人工干预机制以应对模糊职责。

5. 验证式修复（Verified Remediation）

输入：责任工单、漏洞复现凭证与目标仓库贡献指南。
动作：智能体自动生成修复代码补丁，并在容器环境中执行双向验证：一方面验证原有的漏洞利用脚本彻底失效，另一方面运行业务既有全套单元测试与集成测试，确保正常系统行为不受损害。
输出：附带完整测试凭证的 Pull Request。经人类安全工程师审核并授权部署至生产后，独立的验证插件会在生产环境中重新执行验证测试，形成闭环。

在这套闭环中，SECURITY.md 扮演了全局记忆载体的角色。每个阶段在运行前均会读取系统现存的拓扑结构与排查历史；任务完成后，新发现的依赖关系、责任映射与验证脚本会自动追加写回该文件。后续轮次的扫描即可直接跳过已确证的安全面，专注于增量变更与未竟风险。1

内部安全冲刺的数据切片：0.81% 假阳性率从何而来

在验证该架构的实际威力时，OpenAI 采取了高烈度的实战推演模式。在一次内部代码红色警报（Code Red）级别的安全冲刺中，团队集中调度了防御工厂的全部模型与智能体组件，覆盖了内部 100 多个核心服务领域。1

整个架构的模型底座形成了清晰的分层协作：

安全专用模型：依托 OpenAI 设立的 Daybreak 信任访问项目，调用了经过专项攻防对齐训练的 Daybreak Blue（专注于防御加固与补丁构建）与 Daybreak Red（专注于攻击路径模拟与利用链验证）。1 6
通用基础模型：调度 Astra、Sol、Terra 及 Luna 等通用前沿大模型，分别承接复杂上下文语义分析、大规模代码重构与基础逻辑检查。
交互载体：由 Codex Desktop、Codex CLI 与 Codex Security CLI 组装成不同执行形态的自动化智能体。

这场内部实战产出了数项具备高度工程参考价值的量化指标：

评估维度	核心量化指标	指标背景与工程含义
首日攻坚成效	闭环 53 个高危漏洞	在资产测绘尚未完全收尾时，智能体便在第一天协助工程团队快速清除了 53 个高危与紧急缺陷。
补丁生成自动化	100% 由 Codex 驱动	冲刺期间所有提交的代码修补补丁均由 Codex 智能体端到端自动编写生成。
工单权属接受率	90.6% 认领率	智能体路由后的工单在责任团队端的接受认可率达到 90.6%，大幅缓解了传统安全团队“报了漏洞无人认”的困局。
告警智能去重	37% 识别为重复缺陷	智能体在分类阶段自动识别出 37% 的跨组件重复报告，避免工程团队就同一底层隐患重复劳动。
运行时动态复现率	19.5% 成功复现	静态检出的候选漏洞中，只有 19.5% 在隔离容器内成功构造出了真实利用 PoC。
验证后假阳性率	降至 0.81%	引入容器内 PoC 动态验证后，推送到工程师手头的缺陷误报率由传统工具的高位骤降至 0.81%。
生产补丁回滚率	仅 0.53%	经过智能体在隔离环境的双向功能回归检验后，合并上线的补丁回滚率控制在 0.53% 的极低水平。

从数据对比中可以看出，0.81% 假阳性率的核心秘密恰恰在于 19.5% 的动态复现门槛。传统安全工具之所以误报泛滥，是因为静态分析无法感知代码上下文中的防护边界与实际部署参数；Defense Factory 强制要求在真实运行的容器中跑通 PoC，一举过滤掉了 80% 以上无法真正被利用的“纸面缺陷”。这直接保证了交付给业务团队的工单具备极高信噪比，从而带动权属接受率跃升至 90.6%。1 7

落地门槛与工程边界：三个尚未彻底解决的卡点

尽管 OpenAI 展示了这套自动化工厂在内部冲刺中的高效表现，但技术报告也直言不讳地指出了当前体系依然存在的现实边界。对于计划跟进该方向的企业而言，必须看清以下三个关键工程卡点：

1. 瞬时环境的搭建能力是动态验证的真正天花板

动态验证的前提是能够在数秒内自动启动包含完整数据库、依赖包和微服务拓扑的干净容器。在实际运行中，环境准备成为了整个闭环中最容易受阻的瓶颈环节。工程师必须花费大量精力区分“到底是漏洞本身无法被复现，还是环境依赖缺失导致测试脚本没能正确跑通”。对于架构庞大、遗留资产沉重且缺乏容器化基础设施的企业，构建稳定、廉价的瞬时环境成本甚至可能超过大模型调用的 API 成本。

2. 权属指派不等同于组织确认认领

虽然智能体能够凭借代码提交历史与依赖拓扑将 90.6% 的漏洞准确路由至对应服务团队，但这仅仅解决了“该谁管”的问题。工单进入业务团队的待办队列后，排期、修复意愿与业务上线窗口依然受到组织治理与人力资源优先级的强力约束。安全工厂能够加快证据提交，却无法自动消除跨部门沟通的协作摩擦。

3. 代码合入与全量生效存在显著时滞

在补丁流转阶段，智能体生成的 PR 被合入主干代码之后，往往需要经历灰度发布、全量发布甚至多地域滚动更新等复杂周期。OpenAI 团队在实践中发现，许多通过自动验证的补丁在合入后仍需等待发布流水线完成灰度与多地域滚动，线上生效普遍存在时间差。如果智能体在 PR 合并后立即自动关闭漏洞工单，或者在检测到延迟时过激地重新打开工单，都会对团队造成干扰。为此，团队最终选择关闭了自动重新打开（automatic reopening）逻辑，转为仅在确认修复后由智能体发表复测评论，待部署生命周期追踪完善后再逐步放开全自动托管。

持续防御的演进脉络

Defense Factory 的公开，标志着大模型在网络安全领域的应用正从单点的“辅助审计 Copilot”向系统级的“自主流水线（Autonomous Pipeline）”演变。

其实践表明：决定安全智能体实战上限的关键，在于企业是否愿意为了智能体的自主执行彻底重构内部基础设施。只有当隔离环境可以像调用函数一样随意生成、权限控制能够细化到单次请求的凭据代理、代码仓库拥有统一的机器可读契约（SECURITY.md）时，前沿模型的安全潜力才能真正转化为压倒外部攻击者的系统性屏障。1 2