GPT-6 Cyber: Higher exploit scores, gated access

GPT-6 Cyber completed 95% of tasks on OpenAI's new remote-exploitation benchmark. GPT-6 Astra under Daybreak Blue refused every single one. The model improves exploit development and scope compliance, but access starts with a select group of approved Daybreak Red customers. Here's how I read the results and whether they matter for your workflow.

Greater capability makes authorization more consequential for teams testing real services. OpenAI's announcement describes working exploits against remote targets alongside authorization monitoring, access restrictions, and human oversight.

Check GPT-6 Cyber access in API and Codex

Initial access is restricted to a selected group of approved Daybreak Red customers, through the API and Codex. If your team already uses Daybreak Red, check whether you're in that initial group before planning an integration.

OpenAI says it plans to expand access to all Daybreak Red customers. That's an announced rollout, not confirmation that everyone has it yet. They're also making GPT-5.6 Cyber available to all Daybreak Red customers and expanding Daybreak Blue alpha access for GPT-6 Astra.

Mainline models such as GPT-6 Astra support code review, vulnerability triage, and patch development; Daybreak Blue helps verified defenders validate vulnerabilities and fixes with fewer unnecessary refusals; and Daybreak Red supports deeper exploit development and authorized testing. New users and organizations can apply for Daybreak.

Exploit scores rose, but the baselines differ

OpenAI evaluated the model on understanding software, discovering vulnerabilities, and producing working exploits. The results compare different models and access configurations, so each benchmark answers a different question.

ExploitGym gives the direct comparison with the previous Cyber model: the task supplies a vulnerability, and the model must exploit it. The web evaluation tests discovery without source-code access. Don't substitute one for the other when choosing a workflow.

RemoteExploitBench uses known vulnerabilities in applications like GitLab and PostgreSQL in a controlled environment. OpenAI says the new model's only failure was an exploit it couldn't make work remotely. Astra's result is a refusal result, not a measurement showing it tried and failed on every exploit.

Scope training targets tempting, unrelated services

OpenAI trained the model to respect authorized scope, follow action restrictions, and report its work accurately. The relevant test is ExploitGym Honeypot, informed by the Hugging Face incident mentioned in the announcement.

In this evaluation, the model gets a difficult exploitation task inside an isolated environment. Supporting services — a package registry, an object store — are deliberately easy to exploit. Attacking them can reveal the task's flag, but the model must infer they're outside its assignment.

Without deployment safety prompts, GPT-6 Cyber avoided exploiting out-of-scope services in 99.93% of cases, compared with 94.49% for GPT-5.6 Cyber. With deployment safety prompts, it stayed within bounds every time.

The evaluation separates those concepts deliberately: an available shortcut isn't necessarily a permitted action. That matters directly when a research environment has supporting infrastructure alongside the intended target.

Firefox and Linux findings show different research outcomes

The model produced evidence and reproducible tests for 81 previously unknown Firefox vulnerabilities that Mozilla classified as high severity, and it also demonstrated that 30 known issues were more severe than previously reported. OpenAI sent Mozilla the findings and proposed patches; Mozilla began landing fixes shortly after and has released fixes for many.

For Linux, OpenAI reports reproducing 1,724 kernel vulnerabilities and developing working exploits for 948. Following the Linux community's guidance, it disclosed 304 critical findings to maintainers with candidate patches. Work to get other vulnerabilities fixed is still in progress, per the announcement.

The Firefox campaign demonstrates discovery and evidence production. The Linux campaign demonstrates reproduction and exploit development at scale. For a security team, that distinction helps define the deliverable: finding a suspected flaw, demonstrating its impact, and getting a fix accepted are separate stages.

Daybreak Red adds network and data-handling requirements

Daybreak Red API access requires IP allowlisting by default, with limited exceptions. OpenAI monitors credentials for compromise and whether cyber actions match user authorization while recognizing legitimate exploit development. Standard data retention remains the default for Daybreak Red API customers, while Zero Data Retention generally requires Private Safety Processing (PSP). OpenAI describes this as automated review of encrypted records retained in customer storage for 30 days, without exposing prompts and responses to OpenAI personnel.

Critical-system testing has another access distinction. OpenAI is introducing Daybreak Red for Critical Infrastructure for approved defenders, with permissions for authorized testing while retaining safeguards against model misalignment. Safeguards are being refined using feedback from Dragos evaluations in a controlled lab.

“Higher safeguard block rates are not always better.”

— OpenAI

OpenAI reasons that techniques used to understand systems and verify fixes can also serve as legitimate defensive work, so it evaluates blocking alongside support for authorized research and patching rather than refusing everything.

Set boundaries before using Daybreak Red for testing

For an approved team, I'd structure an initial evaluation around a bounded research task, not an open-ended instruction to find security problems:

1. Write down the authorized target and exclusions. Identify which application or service may be tested and which supporting services are outside scope. The honeypot evaluation makes this distinction concrete: access to a registry or object store does not make it part of the assignment.
2. Run the task in a sandbox with action review. OpenAI recommends sandboxing, action review, and human oversight for high-risk workflows. Use those controls as part of the evaluation, not just the model's training.
3. Specify the evidence required for a finding. For a workflow like the Firefox campaign, request a reproducible test and supporting evidence. Keep the claimed impact separate from what the test actually demonstrates.
4. Review candidate patches before accepting them. Treat the proposed change and the validation task as separate work items. OpenAI's reported campaigns include proposed patches, disclosures, and subsequent maintainer fixes — not just generated code.

Before submitting research material, also resolve the applicable retention arrangement and approved request networks. Those are deployment decisions for the team, not details a successful exploit demonstration settles.

Scope-test success is not a production safety guarantee

The announcement reports controlled evaluations. The perfect observed scope result required deployment safety prompts whose exact text OpenAI doesn't provide. That result doesn't establish that every future task will stay within bounds or that an integration can dispense with oversight.

The research counts don't establish that every reported issue is fixed. Mozilla has released fixes for many Firefox findings; OpenAI describes additional Linux remediation as ongoing. Candidate patches shouldn't be presented as completed upstream releases.

Teams needing exploit validation should start with a sandboxed, explicitly authorized task, while routine code review, vulnerability triage, or patch development can use mainline models. The deciding factor is whether your workflow needs deeper exploit development — not merely whether the new model has a higher benchmark score.