AI SecurityOpenAIBug BountyCodexVulnerability Management

OpenAI's Security Sprint: Measure Fixes, Not Promises

Yoni Fraimorice

3/11/2026

A security team can find more bugs, pay larger rewards, and merge more patches while users remain exposed.

The missing step is simple: did the fix reach every affected system, and did someone check that the attack no longer works?

On November 2, OpenAI announced a planned security sprint with Cathedral and larger bug-bounty rewards. Both could help. Neither announcement, by itself, proves that security has improved.

As of November 3, the useful question is not how many reports the next sprint will produce. It is whether outside researchers and AI-assisted testing will shorten exposure and stop the same weaknesses returning.

What changed, and what is still a plan

Cathedral researchers will work alongside OpenAI's teams, using OpenAI models to challenge its defenses. This is a commitment to future work, not a published result from a completed Cathedral sprint.

The bounty update is more concrete. OpenAI says it has more than quadrupled the midpoint of reward ranges for medium, high, and critical findings on average. That is not a promise to quadruple every payout.

Critical vulnerabilities in core products such as ChatGPT, Codex, and the API Platform can earn up to $30,000. Exceptional critical findings remain eligible for up to $100,000 before bonuses, or about $172,000 with bonuses.

The published exceptional example is $100,000 multiplied by quality, campaign, and loyalty bonuses, reaching $171,925. OpenAI explicitly calls its scenarios and historical awards illustrative. This is not evidence that someone received that payment.

Pending awards will use the new ranges. Awards made in the preceding 30 days can receive a top-up where the new base and loyalty awards would pay more. Researchers should check the current Bugcrowd program for scope and terms; a larger reward is not permission to test any system.

What the earlier sprint actually supports

There is relevant prior work, but it belongs in a different evidence bucket.

OpenAI says its previous sprint used 25% of its product engineers. Its Defense Factory account reports more than 250 people across over 100 service areas, with 53 urgent or high-priority issues closed on day one.

The company also reports that 37% of findings were duplicates, 19.5% were reproduced at runtime, the false-positive rate after dynamic validation was 0.81%, and the rolled-back fix rate was 0.53%.

These are OpenAI's reported operational results, not an independent audit or a controlled demonstration of AI's added value. Runtime reproduction is not the same as remediation. The remaining findings cannot simply be called false positives; some tests may lack a working environment.

Most importantly, OpenAI says follow-up checks found a gap between merged patches and fixes deployed across its fleet.

That admission gives us the right finish line.

Start the clock at the report, not the patch

Here is the scorecard I would request. These are proposed measures, not results OpenAI has published for the new sprint.

Question	Measure
Are researchers heard quickly?	Time from submission to meaningful response and to validation, including rejected reports.
Does protection arrive sooner?	Time from first report to deployed, independently verified remediation for each confirmed issue. Report median and 90th percentile by severity.
What is still exposed?	Count and age of unresolved confirmed issues, including overdue critical findings.
Do fixes hold?	Reopened issues and failed retests divided by fixes checked, with counts and observation periods.
Does the weakness return?	New confirmed issues with the same root cause within 30, 60, and 90 days, relative to tracked root-cause fixes.
Is AI reducing work?	Human investigation and review hours, model cost, and total cost per unique, verified fix.

Keep the original report timestamp when merging duplicates. Track temporary mitigation separately from a permanent fix. Report deployment coverage: protecting one region does not close an issue affecting five.

Do not calculate speed only from closed issues. That hides the hardest bugs. Publish the unresolved backlog alongside completion times, and show sample sizes so a small set of easy fixes cannot stand in for the whole program.

Separate more searching from better security

Higher rewards may bring more researchers. AI may examine more code. Both can increase the number of discovered vulnerabilities even while defenses improve.

Fewer reports could instead mean less testing or frustrated researchers. Raw counts cannot settle the question.

For outside research, track unique, validated high-impact findings that internal work had not already identified. Record whether each report led to verified remediation. Separate community reports, Cathedral work, internal AI-assisted findings, and overlapping discoveries.

For AI's contribution, compare similar services and severity levels under the same validation rules. Record model versions, test coverage, researcher effort, and staffing.

Where safe, randomly assign comparable investigation tasks to AI-assisted or existing workflows. Have reviewers judge the evidence without knowing which produced it. Never delay an urgent fix to preserve an experiment.

A before-and-after chart is useful, but a sprint that adds hundreds of engineers cannot attribute every improvement to the model. Compare against a baseline and explain changes in staffing, scope, and release activity.

A lasting fix addresses the shared cause

Imagine a researcher discovers that a read-only project member can upload a file. This is a hypothetical workflow example, not a newly disclosed OpenAI vulnerability.

An AI assistant prepares a patch for the upload endpoint. The test passes. The ticket closes.

But does the import endpoint use the same permission check? What about another API version? If they share a broken authorization rule, one endpoint patch leaves the cause alive.

A stronger response fixes the shared rule, checks sibling routes, and adds a regression test that fails on the old behavior. After authorized deployment, a separate verifier repeats the check with controlled accounts and synthetic data, while confirming that permitted uploads still work.

A duplicate report describes an already known issue. A recurrence is a weakness that appears again after its cause was supposedly fixed. Keep those categories separate.

Reward useful evidence, then publish outcomes

OpenAI's quality bonuses could make reports easier to reproduce. Loyalty bonuses could support sustained research. But neither replaces clear scope, safe-harbor terms, timely communication, or a fair process for disputed severity and duplicates.

A useful follow-up would publish aggregate results after 30, 60, and 90 days: verified fixes, unresolved exposure, recurring causes, researcher response times, and human effort. Sensitive exploit details can wait for coordinated disclosure.

The next sprint deserves credit for its intent. The earlier sprint provides useful, self-reported lessons.

The stronger claim must wait for evidence: less time exposed, fewer returning weaknesses, and fixes checked where users actually depend on them.

Sources

Hero photo: Engineers Clean JWST Secondary Reflector with Carbon Dioxide Snow, photographed by Chris Gunn, NASA/Goddard, January 22, 2015. Public domain in the United States as identified on the source page; see NASA's media usage guidelines. Resized from 4546 x 2989 to 1920 x 1262 pixels and JPEG-compressed. Archival, illustrative photograph of engineers cleaning a telescope test mirror, not OpenAI or Cathedral personnel or evidence of the sprint. No endorsement is implied.