The defender’s window is closing

Defenders have a head start, but we have to act

OpenAI’s approach

The Defense Factory

Building continuous defense

Traditional cyber defenses alone are no longer sufficient

Agents can now conduct long-running cyber operations by abusing increasingly available open-weight models. In response, at OpenAI we’re building a Defense Factory. An automated defense operation to find, validate and fix vulnerabilities continuously.

Teams at Cloudflare(opens in a new window), Ramp(opens in a new window) and Google(opens in a new window) are also exploring this approach. Here, we share the architecture and processes behind our own Defense Factory, along with what we’ve learned from building it.

Latest frontier models are finding vulnerabilities already in production

In a recent security sprint, we used our latest cyber models to find, validate and fix vulnerabilities across OpenAI. We mobilized 250+ people and approached the work with the urgency of an incident response.

Five complete weeks of selected Urgent and High finding reports marked Done or Resolved, relative to the peak week. Recorded completion does not establish independently verified deployed remediation.P0/P1 remediationsP0/P1 remediations54631491535Weeks

Agents can now chain exploits

Agents retain what they learn across sessions to develop a detailed understanding of a system and connect weaknesses. Complex attacks that were previously unfeasible can now be pursued autonomously.

Illustrative attack chainOne path connects successive nodes through a maze. Each reached node enables the next, and earlier steps remain connected. This is a conceptual illustration, not a reconstruction of an incident.

Fleets of agents multiply the scale of attacks

Long-running agents running in fleets can exploit weaknesses on a larger scale and long before a human-in-the-loop security response can find and patch the same vulnerabilities.

Models and agents converge on speedWidely available models and Long-running agents are connected at the top. Two traces descend into Machine-speed exploitation, which fills from top to bottom as they arrive. The labels remain visible throughout.

Defenders have a head start, but we have to act

Defenders have two structural advantages. They can give agents direct access to their code and use frontier models to get a head start over attackers abusing broadly available open-weight models.

Cyber capability

Reach the frontier, then keep paceCyber capability increases upward; time moves to the right. Frontier and open-weight model capability keep accelerating. Defensive capability stays flat until continuous defense is implemented. It then rises in an S-curve: gradual progress, rapid improvement, then a smooth join with the frontier. The defense and frontier curves meet, then share one rising trajectory. The blue area between deployed defense and open-weight capability is the defender’s window. Keeping pace requires ongoing work. These are illustrative trajectories, not measured results or a forecast.

Time

  • Frontier
  • Defenders capability
  • Open-weight

Implement continuous defense

Defender’s window

This head start is the defender’s window.

A Defense Factory is a continuous, agent-first operation for finding and fixing vulnerabilities. It helps defenders keep pace as attackers abuse increasingly capable open-weight models to accelerate their operations. Agents use existing security and engineering tools, reusable skills define the workflows they follow and isolated, reproducible environments let agents investigate findings and prepare tested fixes for review. Teams progressively automate more of the process, reducing handoffs and shortening time from discovery to remediation.

Traditional security

Your existing tools, ideally accessible to agents through MCPs, CLIs or APIs.

Source control

GitHub · GitLab

Security tools

Snyk · Semgrep · Tenable

Issues & workflows

Jira · Linear · ServiceNow

Defense Factory

The glue between your existing tools, enabling agents to proactively find and fix vulnerabilities in a continuous workflow.

Development environment

Isolated, reproducible environments · Ona, Cloudflare, Modal

Agents
  • Codex Desktop
  • Codex CLI
  • Codex Security CLI
Security skills

Security scan · Triage finding · Fix finding

Custom skills

General-purpose models

Sol · Terra · Luna

Security models

Daybreak Blue · Daybreak Red

A Defense Factory needs to reproduce vulnerabilities and verify that fixes work. That requires reproducible and isolated development environments with the right code, dependencies, and services, supported by orchestration and access controls that let agents work safely at scale.

Control plane

Scales execution environments and centralizes policies and secrets.

Data plane

Isolated, ephemeral environments to validate findings.

Containers

Developer systems

Provide the tools agents need to operate.

State & workflows

Keep track of what you protect, what agents find, and what needs fixing.

Security & audit

Monitor agents running cyber models to help ensure safe execution and secure access to sensitive context and data.

Inside the private network, developer systems and state stores sit alongside a control plane and a data plane. The control plane contains workload orchestration, policy enforcement, and a credential proxy. The data plane contains development environments with development containers, environment identities, and host monitoring. Each development container holds an agent harness, skills, and the application. Security and audit provide oversight across the system through host activity, infrastructure security, and agent audit. The boxes show components and boundaries.

How the Defense Factory augments traditional security

Scroll horizontally to see what the Factory adds.

WorkCommon bottleneckWhat the Defense Factory gives you
DiscoveryFindings wait for investigation.
Findings trigger automatic investigations.
TriageDuplicates obscure priorities.
Duplicates merged. Exploitability tested.
OwnershipFindings wait for an owner.
Every finding has a verified owner.
RemediationEngineers repeat investigations.
Tested patches reach reviewers with evidence.
VerificationMerged fixes go unverified.
Deployed fixes are independently retested.

As new model capabilities let us examine our systems more deeply, we increased the pace and scale of our security work. We called an internal code red and brought together Security, Applied, and Research in a coordinated sprint across hundreds of systems.

people mobilized
250+
service areas covered
100+

“We are strengthening our defenses with the urgency of an incident. This is an all-hands effort that takes precedence over everything except critical business operations. We will carry that same urgency beyond the sprint as we continue to test and strengthen our defenses.”

— Thibault Sottiaux, Head of Core Products & Platform, OpenAI

The sprint was the starting point for our Defense Factory. We’re building towards a continuous defensive loop to map our systems, find and validate vulnerabilities, assign owners, verify fixes and improve the system with every run.

The defensive loop

  1. 01

    Inventory

    Map, link, update

  2. 02

    Discovery

    Scan, analyze, import

  3. 03

    Dynamic validation

    Reproduce, test, confirm

  4. 04

    Ownership assignment

    Identify, route, follow up

  5. 05

    Verified remediation

    Patch, deploy, verify

Learn, Adapt, and Increase Autonomy

SECURITY.mdShared context

SECURITY.md represents shared system context, not another step in the loop. Inventory, discovery, dynamic validation, ownership assignment, and verified remediation each read the existing context and contribute what they learn. Each pass reuses the system map, ownership, investigation evidence, and checks already established, so later passes can focus on changes and unresolved risks instead of starting over. People review consequential changes and independently verify deployed fixes. The pulse illustrates a context contribution, not measured progress or savings.

What we learned building the defensive loop

Defensive loops need the right development environments

Reproducible development environments are the foundation of an autonomous defensive loop. Agents need isolated environments that can be provisioned automatically at scale, with the services, dependencies, and configuration needed to reproduce vulnerabilities and test fixes. Those environments must be ephemeral, newly created for each run and discarded with their state afterward, so one run does not contaminate the next.

Autonomy must be built incrementally from manual steps

We started with small batches and human review, then removed repeated manual steps as the results earned trust. We expanded how much work agents could do separately from what they were allowed to change. People shifted toward setting boundaries, handling exceptions, and checking outcomes as agents took on more of the routine work.

  • Inventoried systems while fixes began

    We began by mapping our systems. Codex helped build the inventory while we gathered existing findings into a shared backlog. Early ownership lookup still depended on people finding the right team. We turned service and ownership information into reusable inputs so agents could label and route batches of issues, with people handling ambiguous cases. That improved our accepted ownership assignments to 90.6%. In parallel, teams tackled urgent issues even before the inventory and ownership model were complete. We closed out 53 urgent or high priority issues across our systems on the first day.

    Accepted ownership after routing
    90.6%
  • Built and refined agent triage

    Codex assessed batches of findings against a severity rubric and added service and owner context. Early severity labels were too broad, and classifications varied with the instructions agents received. We versioned the rubric and prompts, added repeatable evaluations, and recorded reviewers’ expected priorities and reasoning. Human spot-checks helped refine priorities and catch weak or duplicate reports. We also paused routing until deduplication improved, progressing from a small, reviewed batch to repeated runs, identifying 37% of findings as duplicate issues.

    of findings identified as duplicates
    37%
  • Made runtime validation repeatable

    Building isolated environments for agents to run code, assess severity, and filter false positives was a key step in separating signal from noise. But environment setup became a constraint on validation, so we started with selected services we could run repeatedly. We worked through missing dependencies and configuration differences so we could distinguish a finding that did not reproduce from a test that could not run properly. With those improvements, 19.5% of findings were reproduced at runtime, and the false-positive rate after dynamic validation was 0.81%.

    false-positive rate after dynamic validation
    0.81%
  • Introduced patch automation and built reusable workflows

    Remediation was 100% Codex-based, with agents generating patches while we improved routing and priorities. We gave agents reproducible development environments to reproduce issues and test proposed patches against running services, checking both the security fix and its effects on normal behavior. We captured lessons in SECURITY.md files and reusable skills, and expanded agent-run scanning and triage alongside automated fix checks. Follow-up checks exposed a gap between merged patches and fixes deployed across the fleet. After a small trial, we expanded verification and posted comments on confirmed fixes, while keeping automatic reopening off as we worked out how to account for deployment delays.

    rolled-back fix rate
    0.53%

Technical blog post coming soon

Inventory

Agents reconcile cloud records, deployment configuration, and service ownership data into an asset inventory. They connect exposed endpoints to code and owners, preserving evidence and gaps so discovery starts with a clearer scope.

Scroll horizontally to explore the diagram.

Cloud and asset records, Source and deployment config, and Service and owner data enter the reproducible development environment together. Codex uses a proposed Build and update inventory skill and the existing service attribution reference to produce an Asset inventory. The same inventory is the first input to Discovery. Inventory writes and refresh scheduling must be configured by the calling workflow.

Inputs

Agent workflow

Reproducible development environment

Outputs

  • Third-party platforms
  • Artifacts
  • OpenAI products
  • Skills / plugins
  • Environments

Make continuous defense a priority

Brief your team, start with one workflow and incrementally build towards a Defense Factory. We’ll continue to publish what we are learning at OpenAI along with practical workflows, tools, and guidance.

  1. Brief your team

    Use the briefing deck to make the case for a Defense Factory, set direction, and agree on a first workflow.

  2. Apply for cyber models

    Apply to Daybreak for access to OpenAI’s advanced cyber models for authorized defensive work.

  3. Run one workflow

    Use the skills in the Codex Security plugin to find vulnerabilities, validate findings, and prepare fixes.

Already an OpenAI customer? Talk to your account team about your architecture.

Further reading

The Hugging Face incident

The Black Hat talk behind the Hugging Face incident reconstruction.

(opens in a new window)
  1. Agent intrusion: the technical timelineHugging Face’s forensic account of the intrusion, including the attack path, investigation, and defensive changes.(opens in a new window)
  2. Hugging Face model evaluation security incidentOpenAI’s account of the model-evaluation incident, its response with Hugging Face, and changes to evaluation safeguards.(opens in a new window)
  3. Defender’s windowWhy defenders have a limited window to act, and how organizations can use AI to strengthen cyber defenses.(opens in a new window)
  4. Expanding Daybreak as the cyber defense window narrowsHow Daybreak expands access to advanced cyber models and helps defenders put them to work with appropriate safeguards.(opens in a new window)
  5. Codex Security pluginA guide to installing the Codex Security plugin, scanning a repository, and reviewing security findings.(opens in a new window)