OpenAI Plans New Security Sprint With Cathedral | Zeniteq
Loading
Loading article
Zeniteq is now available on mobile for iPhone, iPad and Apple Watch.Download nowLearn more
OpenAI Plans New Security Sprint With Cathedral
The planned collaboration builds on a Codex-assisted effort that put a quarter of OpenAI’s product engineers on finding and fixing security weaknesses.
OpenAI has announced a new internal security sprint in collaboration with researchers from Cathedral to test and harden its model defenses. This initiative builds on a previous effort where OpenAI utilized its Codex model to investigate, reproduce, and patch vulnerabilities.
While OpenAI provided no start date or specific results for the upcoming collaboration, it noted the previous sprint involved 25% of its product engineers. Additionally, the company is increasing its bug bounty program, with maximum rewards for critical findings reaching up to $172,000.
OpenAI is planning another internal security sprint, this time bringing Cathedral researchers alongside its own teams to test the company’s defenses with OpenAI models. The company announced the collaboration on November 2, 2026, but gave no start or completion date and reported no results from the upcoming effort.
This is a security implementation event, not a model launch. The announcement describes outside researchers joining an internal defensive workflow. Its most useful detail concerns the previous sprint: OpenAI says it dedicated 25% of its product engineers to finding and fixing weaknesses, using Codex to investigate findings, reproduce vulnerabilities in isolated environments, and prepare patches for review.
That sequence gives other security teams something concrete to examine. The practical question is how to organize the work between a suspected vulnerability and a fix that actually reaches the affected systems.
What Cathedral Adds to the Next Sprint
Cathedral’s researchers will use OpenAI models alongside company teams to challenge OpenAI’s defenses. OpenAI describes the partner’s contribution as different expertise and approaches to finding weaknesses, without specifying the systems in scope or a particular model version.
In the announcement, Cathedral CEO and co-founder Gavin Kliger describes the collaboration as an effort to “find weaknesses, test fixes and strengthen this approach to continuous defense.” That is the partner’s stated goal, not a measured outcome from the new sprint. OpenAI’s announcement provides the account of the planned collaboration.
The organizational change matters: outside researchers will work alongside the teams responsible for the systems being tested. That arrangement could shorten the handoff from discovering a problem to understanding its implementation, although OpenAI has not yet published results demonstrating that benefit.
The staffing commitment from the previous sprint is also worth reading precisely. OpenAI assigned a quarter of its product engineers, not a quarter of its entire workforce. It describes a substantial engineering allocation, but gives no basis for calculating the sprint’s cost or its effect on other product work.
The Previous Sprint’s Find-Reproduce-Patch Loop
OpenAI’s description establishes three connected uses for Codex. Each produces a different kind of evidence, and each needs a different completion check.
Like this article (0 likes)
Save article
Investigate a finding
Engineers used Codex to investigate reported weaknesses. The announcement does not describe the prompts, tools, repository permissions, or triage rules involved.
For another team adapting this process, a useful investigation record would explain the suspected failure, the affected component, and the conditions required to trigger it. Those are practical recommendations, not a published OpenAI checklist. They help turn a model-generated suspicion into a claim an engineer can assess.
Reproduce the vulnerability in isolation
OpenAI says engineers reproduced vulnerabilities in isolated environments. This is the point where a plausible code-level explanation can become observable behavior under controlled conditions.
Isolation also establishes a boundary around testing. A reproduction environment should let a team examine the issue without unnecessarily exposing production data or disrupting live services. The exact controls depend on the system; OpenAI’s announcement does not describe its sandbox architecture.
A successful reproduction has value beyond confirming the initial report. It gives reviewers a concrete failure to check again after a patch.
Prepare a patch for review
Codex then helped prepare patches for review. That wording preserves an important checkpoint: generating a change and accepting it are separate actions.
A useful patch review would examine both whether the change blocks the demonstrated failure and whether it breaks legitimate behavior. Deployment verification comes afterward. OpenAI’s short announcement describes patch preparation, without specifying the complete approval and release process.
My view is that the sequence is more transferable than the 25% staffing figure. Teams can adapt an investigate-reproduce-review workflow to their size. Copying OpenAI’s allocation without knowing their own validation capacity could simply create a larger queue of unconfirmed findings.
What the Reported Sprint Numbers Actually Show
More detailed figures appear in Codex Insider’s November 3 report, which summarizes OpenAI’s separate Defense Factory write-up. These are company-reported process figures relayed by a secondary source, not independent measurements.
Reported figure
What it helps explain
53 urgent or high-priority issues closed on the first day
The sprint produced an immediate volume of issue closures
37% of findings identified as duplicates
Consolidating repeated reports was a substantial part of triage
19.5% of findings reproduced at runtime
Runtime reproduction covered a reported subset of findings
0.81% false-positive rate after validation
The low reported rate applies after a validation step
The duplicate figure is especially useful operationally. A system that generates many reports can still waste engineering time if several describe the same underlying weakness. Teams need a way to consolidate findings before assigning repeated investigation and patching work.
The false-positive figure needs its condition attached: after validation. It should not become a claim that raw model output was 99.19% accurate. The summary does not provide enough methodological detail to calculate that.
Likewise, the runtime-reproduction percentage does not explain the outcome of every remaining finding. Some issues may require other forms of validation, but the available account does not establish that breakdown. These figures describe parts of OpenAI’s workflow; they are insufficient for a like-for-like comparison with another security program.
Three Bottlenecks Other Teams Should Plan For
Codex Insider’s summary of the Defense Factory write-up also reports three constraints: environment setup limited validation, severity labels varied with agent instructions, and merged patches did not always mean fixes had reached the fleet.
Those details are more useful for planning than an isolated count of closed issues.
Environment setup can become the limiting step
The report says environment setup became the constraint on validation. Finding suspicious code and recreating the conditions needed to exercise it are different tasks.
For a team adopting this workflow, that suggests preparing test fixtures, dependency versions, configuration, and safe test credentials before expanding the volume of automated investigation. These are examples of what reproducibility can require, not disclosed details of OpenAI’s setup.
I’d prioritize reliable reproduction environments before adding a larger agent pool. The reasoning is straightforward: if validation is already the bottleneck, generating more candidates increases the backlog without necessarily increasing the rate of confirmed fixes.
Severity needs a stable rubric
Early severity labels were reportedly too broad and changed with the instructions given to agents. That makes prioritization sensitive to how the task is framed.
A practical response is to separate technical evidence from the priority decision. A report should explain the affected asset, required access, expected impact, and reproduction status. A consistent rubric can then determine urgency.
That approach makes disagreements inspectable. Reviewers can identify whether they disagree about what happened, what an attacker would need, or how much damage the issue could cause.
A merged patch still needs deployment verification
The reported gap between merged patches and actual fleet deployment is the most consequential completion detail. A change can be accepted into a repository while affected services continue running older code.
According to Codex Insider, OpenAI kept automatic reopening of issues disabled while working out how to account for deployment delays. That illustrates why a recheck needs deployment context: detecting vulnerable behavior immediately after a merge may indicate an incomplete rollout, a failed fix, or something else requiring investigation.
A reusable workflow should therefore distinguish:
A finding accepted as valid.
A patch reviewed and merged.
A fix deployed to the affected systems.
A follow-up check confirming the expected behavior.
These are suggested tracking states derived from the reported deployment gap, not OpenAI’s published issue-status labels.
Bigger Bug Bounties Expand the Intake
OpenAI also announced improvements to its Security Bug Bounty program, saying it was more than quadrupling rewards for critical findings.
Madrobot’s November 3 report gives a more detailed breakdown for core products including ChatGPT, Codex, and the API Platform:
Critical-finding category
Reported maximum reward
Standard critical finding in a core product
$30,000
Exceptional critical finding, before bonuses
$100,000
Exceptional critical finding, with applicable bonuses
$172,000
Those are ceilings, not guaranteed payouts. The report describes bonuses tied to reliable proofs of concept, repeat-researcher participation, and priority campaigns.
The bounty changes complement the sprint by encouraging outside submissions. They also reinforce the need for triage capacity: a larger intake is useful only if the organization can validate findings, consolidate duplicates, assign ownership, and carry fixes through deployment.
The Reusable Lesson Is How the Work Gets Completed
OpenAI presents the sprint as part of continuous defense using its most capable models. The published account supports a concrete implementation pattern, but it does not quantify the new collaboration’s effectiveness, overall return on investment, or improvement over a comparable non-AI security effort.
Security teams can still take a practical lesson from it: measure progress across the full workflow. Count confirmed findings, track time spent establishing reproductions, separate reviewed patches from deployed fixes, and check whether affected systems are actually protected.
The Cathedral collaboration will eventually provide another opportunity to assess that process. For now, the strongest contribution is the description of where model-assisted work meets ordinary engineering constraints: reproducible environments, consistent prioritization, review, and deployment.
Frequently Asked Questions
3 questions
1
When will the Cathedral security sprint start?
OpenAI has not announced a start or completion date. Its November 2 announcement describes a planned collaboration and contains no results from the upcoming sprint.
2
Is OpenAI launching a new model for the sprint?
The announcement does not launch a model or specify a model version. It says Cathedral researchers will use OpenAI models alongside company teams.
3
Does a merged security patch mean the issue is resolved?
A merge confirms that a code change was accepted, but affected systems still need the fix deployed. The prior sprint’s reported deployment gap shows why rollout and follow-up verification need separate checks.
