OpenAI's Defense Factory Deploys AI Agents to Patch Hundreds of Security Flaws

OpenAI has published a detailed writeup of how it ran an internal security sprint using its own frontier models to find, validate, and patch vulnerabilities across hundreds of systems, along with a reference architecture other teams can copy. The Defense Factory is framed as a continuous loop where AI agents inventory code, discover bugs, reproduce them in isolated environments, assign owners, ship patches, and then verify the fixes actually deployed.

Attackers running fleets of long-running agents on open-weight models are compressing the time between vulnerability disclosure and mass exploitation. OpenAI argues defenders still have two structural advantages, direct access to their own code and access to frontier models, but that head start (what the company calls the defender's window) is closing fast.

Inside the sprint

OpenAI used its latest cyber models to find, validate, and fix vulnerabilities across the company, mobilizing more than 250 people and approaching the work with the urgency of an incident response. The effort spanned over 100 service areas and was jointly run by the Security, Applied, and Research teams.

A few concrete numbers came out of it:

• Accepted ownership assignment after agent routing hit 90.6%.
• 53 urgent or high priority issues were closed on the first day, before the inventory was even complete.
• 37% of findings were identified as duplicates after deduplication improved.
• 19.5% of findings were reproduced at runtime, with a false-positive rate of 0.81% after dynamic validation.
• Remediation was 100% Codex-based, with agents generating patches while routing and priorities were tuned.
• Rolled-back fix rate landed at 0.53%.

The loop, in five stages

The Defense Factory is built around a repeatable loop that each pass improves on rather than restarting. The stages are inventory, discovery, dynamic validation, ownership assignment, and verified remediation, with a shared SECURITY.md acting as persistent context that every stage reads from and writes back to.

Several design choices push back on how most security programs work today:

1. Findings trigger automatic investigations instead of sitting in a backlog waiting for a human triager.
2. Every finding gets a verified owner, resolved by agents against code owners, commit history, and asset inventory.
3. Patches arrive with evidence, meaning the agent has already reproduced the bug and tested the fix in an isolated environment before a human reviews the PR.
4. Deployed fixes are independently retested, closing the common gap where a merged patch never actually rolls out fleet-wide.

Under the hood

The reference design splits into a control plane (workload orchestration, policy enforcement, credential proxy) and a data plane made of ephemeral, isolated development containers where agents actually run. Environments are newly created for each run and discarded with their state afterward, so one run does not contaminate the next.

Inside each container sits an agent harness, a set of security skills, and the target application with its real dependencies. Agents plug into existing tools through MCPs, CLIs, or APIs: GitHub or GitLab for source, Snyk/Semgrep/Tenable/Wiz for scanning, Jira or Linear for tickets. The models doing the work are a mix of general-purpose (Sol, Terra, Luna, and what OpenAI calls GPT-5.6) and specialized cyber models branded Daybreak Blue (defensive scanning) and Daybreak Red (triage and validation).

What you can grab today

Three things are shipping alongside the writeup:

• A briefing deck and playbook to make the internal case and pick a first workflow.
• A Codex Security plugin with skills for scanning repos, validating findings, and preparing patches.
• An application for gated access to the Daybreak cyber models, restricted to authorized defensive work.

Where it works and where it stumbles

The strongest results came from tightly scoped work: dedup, routing, and patch generation on services that had clean, reproducible environments. Environment setup became a constraint on validation, so the team started with selected services that could be run repeatedly, then worked through missing dependencies and configuration differences. If your services need heavy scaffolding to boot, the loop stalls.

Early triage was noisy too. Codex assessed batches of findings against a severity rubric, but early severity labels were too broad and classifications varied with the instructions agents received. The team fixed it by versioning the rubric, adding evaluations, and recording reviewers' expected priorities as ground truth, a pattern anyone building agentic workflows will recognize.

One important caveat on the headline numbers: OpenAI explicitly notes that recorded completion in the sprint does not establish independently verified deployed remediation. Reported "done" is different from "patched in production," which is exactly the gap the verified-remediation stage exists to close.

Why this matters beyond OpenAI

The post name-checks parallel efforts at Cloudflare, Ramp, and Google's Chrome security team, all converging on the same idea: security programs need to run at agent speed because the offensive side already does. The interesting shift is architectural. Rather than buying another SAST tool, teams are being asked to invest in reproducible dev environments, agent orchestration, and shared context files so that a fleet of agents can operate on their codebase safely and continuously.

If you already have Codex in your workflow, the Security plugin is the low-friction entry point. If you don't, the playbook is a blueprint for wiring agents into the tools you already run, one workflow at a time, without betting the entire security org on autonomy from day one.