OpenAI Turns a 250-Person Security Sprint Into a Continuous AI Defense Factory

OpenAI says it mobilized more than 250 employees to find and fix vulnerabilities across hundreds of its systems, using Codex and specialized cyber models to support discovery, triage, remediation, and verification. The company has now published the architecture and operating process that grew out of that internal security sprint, calling the resulting system its “Defense Factory.”

The disclosure contains unusually specific operational results. OpenAI says teams closed 53 urgent or high-priority issues on the sprint’s first day, achieved a 90.6% acceptance rate when routing findings to owners, classified 37% of findings as duplicates, and reduced the false-positive rate after dynamic validation to 0.81%.

Those figures describe an internal defensive program, not a disclosed external breach. OpenAI has not identified the affected services, published the total number or severity distribution of vulnerabilities, or provided the denominators and measurement periods behind every reported rate. Its results therefore cannot be independently reproduced from the published material. The importance of the disclosure lies instead in the operating model: security work is being reorganized as a persistent agent workflow rather than a succession of periodic scans and human handoffs.

1. The Security Sprint Covered More Than 100 Service Areas

OpenAI describes the original effort as an internal “code red” that brought together its Security, Applied, and Research organizations. More than 250 people participated, and the work covered over 100 service areas encompassing hundreds of systems.

The sprint began before OpenAI had a complete map of those systems. Codex helped assemble an asset inventory while teams imported existing security findings into a shared backlog. Service ownership data, deployment configuration, cloud records, source code, and exposed endpoints were progressively connected so agents could determine which team should receive each finding.

OpenAI reports that this process produced a 90.6% accepted-ownership rate. Human reviewers continued to resolve ambiguous cases, while urgent fixes proceeded before the inventory was complete. That parallel approach allowed teams to close 53 urgent or high-priority issues during the first day.

Agents also assessed findings against a severity rubric. OpenAI says early classifications were inconsistent and sensitive to the instructions supplied to the models. The company responded by versioning its prompts and rubric, adding repeatable evaluations, recording reviewers’ expected priorities and reasoning, and retaining human spot checks.

Deduplication became another explicit gate. OpenAI temporarily paused automated routing until that process improved, eventually determining that 37% of the findings it examined were duplicates. This matters because an agent system that merely generates more reports can increase the burden on security engineers without reducing risk.

Dynamic validation was used to separate reproducible vulnerabilities from static-analysis noise. Agents received runnable versions of selected services and attempted to reproduce suspected problems inside controlled environments. OpenAI reports a 0.81% false-positive rate after this stage, although it does not disclose the size or composition of the validated sample.

2. Defense Factory Uses a Five-Stage Agent Loop

The Defense Factory is not presented as a single model or vulnerability scanner. It is a reference architecture that connects existing source-control systems, security scanners, issue trackers, development environments, company-specific context, and AI agents.

Its workflow has five recurring stages: inventory, discovery, dynamic validation, ownership assignment, and verified remediation.

Inventory agents reconcile cloud resources, deployment configuration, source code, exposed endpoints, and service-ownership records. Discovery agents then combine that inventory with threat models, security policy, source code, and findings imported from tools such as Snyk or Wiz. The output remains a pool of candidate vulnerabilities rather than a list of confirmed defects.

During dynamic validation, agents inspect the relevant code and try to reproduce each candidate in a runnable application. OpenAI’s specification says static tracing alone is insufficient: a validated vulnerability must include reproduction evidence. Disproven and inconclusive findings remain attached to the record, while creation of an issue in the tracker requires approval.

Ownership agents connect validated findings with asset inventories, code-owner files, commit history, internal communications, and issue trackers. OpenAI distinguishes assignment from acknowledgment, preventing an automatically routed ticket from being treated as accepted work.

In the final stage, Codex prepares a patch and checks its behavior in a reproducible environment. After human review and authorized deployment, a separate check retests the production fix. A merged pull request or a moved ticket is not considered proof of remediation; failed or inconclusive verification keeps the issue open.

Shared SECURITY.md files carry system-specific knowledge between cycles. Each pass can reuse mappings, ownership information, investigation evidence, and previous verification checks instead of reconstructing that context. The company says consequential changes still receive human review and deployed fixes are independently verified.

3. Isolation and Access Controls Are Part of the Security Boundary

OpenAI’s architecture separates a control plane from a data plane. The control plane manages workload orchestration, policy enforcement, and access to credentials. The data plane supplies isolated development environments in which agents can run applications, reproduce vulnerabilities, and test patches.

Those environments are intended to be ephemeral: each run starts from a new environment, and its state is discarded afterward. This reduces the risk that one investigation contaminates another and makes repeated validation more reliable.

The architecture also places source control, secret storage, artifact registries, and model endpoints inside the organization’s private network. Asset inventories and findings databases preserve workflow state, while host monitoring, infrastructure security, and agent audit systems supervise activity across the pipeline.

OpenAI says it increased autonomy incrementally. It began with small batches and human review, then removed recurring manual steps after the results became more dependable. The permissions granted to an agent were kept separate from the amount of analytical work it could perform.

That distinction is especially important during remediation. OpenAI says agents generated every patch in the sprint, describing remediation as “100% Codex-based,” but people remained responsible for consequential review and authorized deployment. The reported rolled-back-fix rate was 0.53%, though the company has not published the raw number of patches represented by that percentage.

Follow-up checks also found a gap between fixes being merged and reaching all deployed systems. OpenAI expanded post-deployment verification but initially left automatic reopening disabled while it worked out how to distinguish failed remediation from normal deployment delays.

4. The Transferable Result Is the Validation Pipeline, Not the Headcount

OpenAI’s central claim is that defenders can use private code, deployment context, ownership records, and stronger frontier models before attackers gain comparable access. Its Defense Factory is designed to turn that advantage into shorter cycles between discovery and verified remediation.

Cloudflare has separately described a comparable multi-agent vulnerability harness. Its pipeline uses distinct agents for reconnaissance, hunting, adversarial validation, deduplication, dependency tracing, and patch preparation. It requires human approval before a generated fix can reach production and treats reproducible tests as a gate rather than trusting a model’s written assessment.

That independent implementation supports the underlying workflow pattern while also illustrating its costs. Cloudflare says large scans can take hours, require pools of 50 to 200 workers, and move the operational bottleneck from finding defects to reviewing and safely deploying fixes. Continuous agent activity does not eliminate the need for application owners, reliable test environments, release engineering, or security judgment.

For organizations considering OpenAI’s design, the most concrete change is procedural. Candidate findings must be deduplicated and reproduced before reaching engineers; ownership must be tied to current operational records; patches must pass regression checks; and remediation must be verified after deployment. Without those gates, adding agents risks accelerating report production rather than vulnerability reduction.

Access to the underlying models is also not uniform. OpenAI’s published architecture names general-purpose models including Astra, Sol, Terra, and Luna, alongside the Daybreak Blue and Daybreak Red security models. More permissive cyber capabilities are offered through Daybreak to verified defenders, with stronger identity verification, scope controls, monitoring, and oversight.

The published material is therefore a reference architecture and internal case study, not evidence that any organization can reproduce OpenAI’s results immediately. OpenAI has provided performance indicators and workflow details, but not enough vulnerability-level data to compare its system with conventional security programs or independently evaluate detection coverage.

Frequently Asked Questions

Was OpenAI responding to a confirmed external breach?

No. OpenAI describes the work as an internal security sprint and does not say that the Defense Factory announcement concerns a new external intrusion.

What does the Defense Factory do?

It connects asset inventory, vulnerability discovery, runtime validation, ownership routing, patch generation, and post-deployment verification in a recurring agent-assisted workflow.

Did AI agents deploy fixes without human approval?

OpenAI says Codex generated the patches, but consequential changes remained subject to human review and deployment authorization. Production fixes were then independently retested.

How many vulnerabilities did OpenAI find?

OpenAI has not published a total. It reports closing 53 urgent or high-priority issues on the first day, but does not disclose the complete number or severity distribution of findings.

Can any organization use the same cyber models?

Not automatically. OpenAI directs authorized defenders to apply through Daybreak, where access to more capable or permissive cyber tools depends on verification, scope controls, and oversight.

Sources

• Original OpenAI post on X
• OpenAI: Defense Factory
• OpenAI: Daybreak
• OpenAI: Trusted Access for the Next Era of Cyber Defense
• Cloudflare: Build Your Own Vulnerability Harness