OpenAI mobilized 250 people to hunt its own vulnerabilities

The urgency comes from a change on the attacking side. OpenAI explained that agents running on widely available open-weight models can now carry out cyber operations that stretch over long periods. When an agent keeps what it learned between sessions, it can build a detailed picture of a system's structure and stitch separate vulnerabilities together. Chained attacks that used to be too laborious to attempt now run on their own.

The company's argument is that defenders still have time left. Writing about the structural advantages on the defending side, OpenAI said defenders "can give agents direct access to their own code, and use frontier models to stay ahead of attackers exploiting broadly available open-weight models." Only defenders can open an entire codebase to an agent, and only defenders get the newest models first. The company calls that gap the defender's window, and says flatly that it closes unless organizations move now.

The sprint was run as though a real incident were under way. Security, Applied and Research teams were brought together and hundreds of systems were tackled at once. Tibo Sottiaux, who leads core product and platform at OpenAI, said the company is "hardening our defenses with the same urgency we bring to responding to an incident." He added that the work outranks every other task except core business operations, and that the same urgency will be sustained after the sprint ends. On the first day alone, 53 urgent or high-priority issues were closed.

The public document METAL read in full also carries numbers from the parts that did not go smoothly. At the start the severity categories were too broad, so results shifted depending on the instructions handed to the agents. Only after the company versioned its rating criteria and prompts, and recorded the priorities reviewers expected along with the reasoning behind them, did it move to batch processing. Along the way 37% of findings turned out to be duplicates, and routing to owners was halted entirely until deduplication improved.

The validation numbers are more specific. After building isolated environments where agents could actually execute code, 19.5% of findings reproduced at runtime, and the false-positive rate after that dynamic validation was 0.81%. The share of routed findings accepted by the owning team rose to 90.6%. Patches were written by Codex rather than by people, and 0.53% of fixes were rolled back after deployment.

The company also sets out the limits it ran into. Standing up the isolated environments was itself the bottleneck in validation, so it had to start with the handful of services that could be run repeatably. It found late that merged patches and the fixes actually deployed across the fleet did not always match, and with no decision yet on how to account for deployment lag, automatic reopening is switched off. Autonomy was not handed over in one go either. It began with small batches and human review, and widened only as far as trust allowed.

Read with a lawyer's eye, the most important part of this document is not the performance figures but the control structure. OpenAI said it managed the range of what agents were able to do separately from the range of what they were permitted to change. Audit trails are built into the design as well, with host activity, infrastructure security and agent auditing each recorded separately. Establishing who approved what, and when, is what settles responsibility after an incident, and this design answers that requirement at the organizational layer before reaching for tooling.

The announcement is also an inside account of the defense business OpenAI has been pushing lately. METAL reported on the company's decision to offer $1 billion worth of Daybreak access to under-resourced defenders, and this document reads more like the result of pointing that tooling at itself first. The published material notes that teams at Cloudflare, Ramp and Google are exploring the same approach. The company has trailed a technical blog post on its skills and security workflows as coming soon.

In short, OpenAI ran an incident-grade security sprint against its own systems and published the resulting numbers, failures included, as a reference architecture. The proposal is to turn defense from a one-off audit into a loop that keeps running, with agents driving most of the loop while people hold the boundaries and the exceptions. Two things are worth watching. How much of its skills and workflows the promised technical blog post actually discloses, and whether organizations copying the approach land on similar false-positive and rollback rates.