When a security team asks for reduced-refusal access to a cyber model, the approval usually lands with someone unprepared to grant it. The team wants a purpose-trained model for vulnerability research and exploit development — one that, on the vendor's own internal evaluation, completes almost every advanced dual-use cyber request it receives. The approver has to decide whether refusal behavior is a lever the organization can purchase, and whether this team should be allowed to pull it.
That decision is harder than it looks.
The Tier is the Lever
Until recently, refusal behaved like a fixed property of a model. You deployed a frontier model with its default safeguards, and you got predictable refusal behavior. OpenAI now ships the same underlying model as three different products: default public access, Daybreak Blue for approved defensive security work, and Daybreak Red for authorized vulnerability research and exploit validation. The refusal behavior you get depends on which tier you purchase.
On OpenAI's internal Advanced Cybersecurity Completion Rate evaluation — which measures how often models respond to requests involving exploit-chain development, authentication bypass, and privilege escalation — GPT‑5.6‑Cyber completes 95.0% of advanced dual-use cyber requests, compared with 1.5% for GPT‑5.6 Sol under default safeguards, 2.0% for the same model under Daybreak Blue, and 57.3% for the earlier GPT‑5.5‑Cyber . All of these numbers are vendor-reported, drawn from an internal evaluation no third party has replicated. [1]
That is the difference a tier makes: a purchased policy choice, not an inherent capability gap. The public benchmarks that justified adopting the model in the first place do not describe the behavior any gated tier delivers. The completion rate that matters is the rate on the tier your team will actually deploy. A rate published for default public access tells you nothing about behavior under Blue-class safeguards or Red-class reduced-refusal mode.
What the Vendor Has Shown and What It Hasn't
OpenAI's evidence comes from internal evaluations. The completion rates are vendor-reported; no independent party has replicated them. That is context, not a verdict — vendors measure their own models partly because independent evaluation is slow and expensive. But a buyer should know the difference between internal marketing and internal honesty.
The strongest honesty signal in the announcement is a disclosed tradeoff. On OpenAI's internal Vulnerability Discovery and Report Writing evaluation, the cyber model performs worse than the general-purpose model it was built from. OpenAI believes the reduced-refusal model sometimes produces shorter, less detailed vulnerability reports. That is exactly the kind of finding a vendor could have buried; instead it sits in the announcement itself. [1]
OpenAI has also disclosed real-world use. The company used the cyber model to investigate V8, the JavaScript engine behind Chrome, and uncovered two previously unknown vulnerabilities that could be chained to corrupt memory and escape the V8 heap sandbox. OpenAI's researchers validated the findings and reported them to Google through coordinated disclosure; Google fixed the flaw and assigned it a CVE identifier. [1]
What the vendor has not disclosed is how reduced-refusal behavior changes misuse risk in practice. Reuters reporting from May, a month after the launch of Anthropic's Mythos cyber model, found cybersecurity experts describing fears of turbocharged hacking as overstated: the bottleneck was validating and fixing flaws, not finding more of them, though access limits tied to computing demands were expected to fall. That context tempers the urgency framing. A reduced-refusal model accelerates discovery; the constraint in most security programs is remediation. [3]
Control Surfaces and Authorization Boundaries
Refusal reduction is not the only policy lever. OpenAI's access controls for both Daybreak tiers include identity verification, account security, monitoring, approved-use restrictions, and legal attestations. All individual Daybreak accounts must adopt hardware security keys beginning September 1, 2026 . [1] These controls are the real control surface. Before approving any team's access to a gated tier, map them against your own authorization boundaries and internal governance.
If your team works through a Daybreak Cyber Partner — a security consultancy or vendor embedding the model into its own products and engagements — the boundary question is different. The partner holds the model access; it is not transferred directly to your team. Per-engagement safeguards can include identity verification, defined testing scopes, logging, monitoring, and human oversight, and the partner helps define the boundaries of each engagement, from vulnerability discovery and validation to red teaming, penetration testing, incident response, and remediation. You do not inherit the vendor's controls directly; you negotiate the partner's controls around the engagement scope. [2]
A good procurement review starts with a tier-to-need assessment. Does the team actually need Red-class reduced-refusal access, or does Blue-class safeguarded access cover the intended workflows? Most defensive security work runs on Blue. Red is a separate, higher-risk grant, and it deserves its own authorization decision.
The Operating Consequence
Here is the concrete step that prevents the decision from slipping through without sight. Before any team receives gated reduced-refusal access to a model, the approving security leader re-runs the relevant workflow evaluation on that exact tier — not the public benchmark, not a vendor presentation, but the team's actual workflows on the tier it will use. Record the tier, its access controls, and the evaluation results in the procurement record. Gate Red-class access behind a separate authorization decision, distinct from any approval for Blue-class access.
The benchmark that justified the purchase describes a model configuration the team will never run. The decision should rest on the tier you actually deploy.