AI Blog

GPT-5.6-Cyber Is Gated Because It Refuses Less, Not Because It Knows More

OpenAI's offensive-security model loses to plain GPT-5.6 Sol on both evaluations that score the work product, and wins the one that scores whether it answers at all. Daybreak Red gates a refusal policy, not a capability — which makes patch latency, not model access, the number that should have moved on 10 August.

By Agentic AI Wiki 11 min read

OpenAI's new offensive-security model loses to the ordinary one on both evaluations that score the work product, and wins the single evaluation that scores whether it answers at all. That is the whole story: Daybreak Red gates a refusal policy, not a capability. Your patch latency is the number that should have moved on 10 August, not your model access.

What shipped

OpenAI released GPT-5.6-Cyber on 10 August 2026, built on GPT-5.6 Sol and trained to find zero-day vulnerabilities and build exploit chains. It is not on the API price list. Access runs through Daybreak Red, the upper tier of OpenAI's expanded Daybreak programme, and entry is controlled by identity verification, account-security requirements, monitoring, approved-use restrictions and legal attestations. From 1 September 2026, hardware security keys become mandatory on every individual Daybreak account across both the Blue and Red tiers.

The launch evidence is real work. OpenAI ran the model against V8, Chrome's JavaScript engine, and reported two previously unknown vulnerabilities that chain into memory corruption and a heap-sandbox escape; Google has patched one of them as CVE-2026-15903, rated CVSS 8.8. The company also reports more than 400 kernel privilege-escalation findings before launch.

PropertyGPT-5.6-CyberWhat it tells you
Base GPT-5.6 Sol, further trained on offensive-security work. Same family, same weights lineage. The delta is post-training, not a new pre-train.
Access Daybreak Red only — ID verification, attestations, approved use cases, monitoring, hardware keys from 1 September. The strongest access control OpenAI has shipped on a text model. It is an attribution mechanism.
Approved uses Proof-of-concept exploit development, exploit-chain validation, penetration testing, red teaming. All four are things a competent security team already does. None of them is new work.
Headline metric 95.0% on OpenAI's Advanced Cybersecurity Completion Rate, against 1.5% for standard Sol. A sixty-three-fold jump in a number that counts engagement, not correctness.
Advanced Cybersecurity Completion Rate, GPT-5.6-Cyber versus GPT-5.6 Sol Horizontal bar chart of OpenAI's reported Advanced Cybersecurity Completion Rate. GPT-5.6-Cyber answers 95.0 percent of advanced cyber prompts; standard GPT-5.6 Sol answers 1.5 percent. The metric counts prompts the model engages with, not prompts it solves correctly. Advanced Cybersecurity Completion Rate (%) GPT-5.6-Cyber 95.0 GPT-5.6 Sol 1.5 0 25 50 75 100 COUNTS PROMPTS THE MODEL ENGAGES WITH NOT PROMPTS IT SOLVES CORRECTLY
The gap everyone quoted. Read the axis label before you read the bars.

The specialised model loses the evaluations that grade output

OpenAI published two more results alongside the completion rate, and both go the other way. On its own Vulnerability Discovery and Report Writing evaluation, GPT-5.6-Cyber scores worse than plain Sol — OpenAI attributes this to Cyber producing shorter, less detailed vulnerability reports. On ExploitBench at the standard setting, which caps agents at 300 turns, Sol solves more tasks and does it on fewer tokens. Extend the cap to 600 turns and the gap between the two narrows.

Which model wins each of OpenAI's three reported cyber evaluations Three columns for the Advanced Cybersecurity Completion Rate, the Vulnerability Discovery and Report Writing evaluation, and ExploitBench at the standard 300-turn setting. Compared across what each measures, which model wins, and what that implies. GPT-5.6-Cyber wins only the completion-rate metric; standard GPT-5.6 Sol wins the two evaluations that score work product. MEASURES WINNER IMPLIES Advanced Cyber Completion Rate Vuln. Discovery & Report Writing ExploitBench (300 turns) Whether the model engages at all. Quality of the finding and the write-up. Tasks solved inside a fixed turn budget. GPT-5.6-Cyber, 95.0 vs 1.5. GPT-5.6 Sol — Cyber writes shorter. GPT-5.6 Sol, on fewer tokens. A policy delta. Not a skill delta. The base model already has the capability. Raise the budget to 600 and the gap narrows. THE ONLY EVAL THE SPECIALISED MODEL WINS IS THE ONE THAT SCORES WILLINGNESS
One column scores willingness. The other two score work, and the general model takes both.

Put those three results next to each other and the shape is unambiguous. The specialised model is not better at security research. It is more willing to do security research, and it is slightly worse at writing up what it finds. The 95.0 figure and the ExploitBench loss are not in tension — they are measuring different variables that a single word, "cyber", has been quietly covering for.

Completion rate is a policy metric wearing a capability metric's clothes

A completion rate answers the question did the model engage with the prompt. It says nothing about whether the answer was right, exploitable, or even coherent. A model that responds to every prompt with a confident wrong answer scores 100%. That is not a hypothetical criticism of OpenAI's metric — it is the definition of the metric, and OpenAI's own vulnerability-discovery number is the evidence that the two come apart in practice.

This generalises well past this launch. Any evaluation scored on answered / total is measuring the refusal boundary, and refusal boundaries are set by post-training and system prompts — the cheapest, most frequently changed part of a deployed model. If a vendor reports a large jump on a metric of that shape, the null hypothesis is a policy change, and the burden is on the number to prove otherwise. See reading benchmarks for the general habit, and refusals & capability gating for why "the model can't do that" is almost never the true statement.

The 600-turn detail is the tell

The most informative sentence in the whole release is the one about turn budgets. If the specialised model's advantage evaporates when you give the general model twice as many turns, then what the specialised model saves is attempts, not ability. Refusals cost turns: a model that declines, hedges, or needs to be re-framed burns the budget on negotiation rather than analysis. Remove the refusals and the same underlying competence finishes sooner.

Which layer the Daybreak Red gate actually sits on A three-layer stack. The bottom layer is the shared GPT-5.6 base capability, identical for both models. The middle layer is the refusal policy, the only layer that differs between GPT-5.6 Sol and GPT-5.6-Cyber. The top layer is the Daybreak Red access gate, which controls who reaches the permissive policy. Arrows show that an attacker with a longer turn budget reaches the same capability through the standard model without passing the gate. LAYER 3 — ACCESS Anyone with an API key No vetting. No attestation. Daybreak Red ID check, attestations, monitoring, keys. LAYER 2 — REFUSAL POLICY (THE ONLY LAYER THAT DIFFERS) GPT-5.6 Sol Declines most dual-use cyber prompts. Completion rate 1.5%. GPT-5.6-Cyber Trained to decline far less. Completion rate 95.0%. LAYER 1 — CAPABILITY (IDENTICAL) Shared GPT-5.6 base weights Sol wins the two evaluations that score the work product. The specialised model does not add skill. +300 TURNS GATING LAYER 3 DOES NOT MOVE LAYER 1 — IT ONLY DECIDES WHO GETS THE SHORTCUT THROUGH LAYER 2
Vetting sits on the top layer. The bottom layer is the same in both columns and always was.

What this does and does not change for defenders

The tempting reading of 10 August is that a new offensive capability entered the world and defenders should respond to it. The evidence points somewhere less comfortable: the capability was already in the model your organisation has been paying twenty dollars a month for, and it was reachable by anyone patient enough to spend turns. What changed on 10 August is that OpenAI made the shortcut official, priced it in paperwork, and published the numbers proving the shortcut is only a shortcut.

That has three concrete consequences.

  • Do not model Daybreak Red as a containment boundary. An adversary who was going to use a frontier model for vulnerability research was never going to apply for it. They will use the ungated model with a longer turn budget, an open-weights model with no policy layer at all, or a jailbreak — all three of which were available before this launch and remain available after it.
  • Do model it as an attribution boundary. Identity verification, legal attestations, approved-use declarations, monitoring and mandatory hardware keys are a genuine control — just not a preventative one. They make legitimate use traceable and give OpenAI a revocable handle on every account. That is worth having, and it is worth naming honestly instead of overselling.
  • Move the number that actually protects you. OpenAI framed the expansion around a narrowing defence window, and on that framing they are right. If discovery gets cheaper for everyone symmetrically, the variable under your control is the time between a patch existing and a patch being deployed. A team that ships CVE-2026-15903 to production in four hours is in a different risk class from one that ships it in four weeks, and nothing about model access changes that ordering.

The asymmetry that does favour defenders

There is one real defensive advantage in this release, and it is not the model. It is that a vetted, monitored, attested channel is available to defenders and structurally unattractive to attackers — so the population using GPT-5.6-Cyber through Daybreak Red skews heavily toward people who will report what they find. The Chrome findings are the proof: two V8 bugs went to Google and got patched rather than to a broker and got sold. That is a real gain, and it comes from the programme design, not from the weights.

Whether to apply

If you are…Apply?Because
A product security team doing your own exploit validation Yes Fewer refusals on legitimate dual-use prompts is a genuine workflow improvement, and you can attest to authorised scope truthfully.
A pentest or red-team consultancy Yes, with scope discipline The attestations bind you to approved use across every client engagement. Your authorisation paperwork now has a second audience.
A blue team doing triage, detection and IR Probably not yet The lower Daybreak tier covers defensive work, and Sol writes better reports anyway. Spend the effort on security-operations agents instead.
Building an autonomous scanning agent No Approved-use restrictions and monitoring do not fit an unattended loop, and the failure mode of an unsupervised exploit-development agent is an incident you caused. Read sandbox & isolation patterns first.

If you do not get in, you have lost very little. The published evaluations say the general model matches or beats the specialised one on work product once you stop counting refusals — and running your own harness against your own codebase, with your own turn budget, will tell you more than either leaderboard. That is the argument in reading agent benchmarks critically, applied to a launch that happens to prove it.

FAQ

Is GPT-5.6-Cyber more capable at hacking than GPT-5.6 Sol?

Not on OpenAI's own published evidence. Sol scores higher on the Vulnerability Discovery and Report Writing evaluation and solves more ExploitBench tasks at the standard 300-turn budget, using fewer tokens. GPT-5.6-Cyber's advantage is that it declines far less often, which is a policy difference rather than a skill difference.

What is the difference between Daybreak Blue and Daybreak Red?

Blue is the broader defensive tier; Red is the higher-access tier that unlocks GPT-5.6-Cyber for advanced authorised workflows such as proof-of-concept exploit development, exploit-chain validation, penetration testing and red teaming. Both tiers require hardware security keys on individual accounts from 1 September 2026.

Does this launch make my organisation more likely to be attacked?

Not directly. The underlying capability shipped with the general model, and an attacker can reach it with a longer turn budget or an open-weights model that has no refusal layer to begin with. The gate changes who has a convenient path, not who has a possible one.

What should we actually change in response?

Patch latency and asset inventory, not model policy. If vulnerability discovery is getting cheaper on both sides, the defender's controllable variable is the interval between a fix existing and a fix being deployed. Measuring that interval is a better use of a week than debating access tiers.

Which Chrome vulnerabilities did it find?

Two previously unknown V8 flaws that chain into memory corruption and a heap-sandbox escape. Google patched one as CVE-2026-15903, a high-severity issue rated CVSS 8.8; the second had not been publicly identified at the time of the announcement.

Further reading

On this wiki:

Sources: