OpenAI has introduced GPT-6 Cyber for authorized security research. Initial API and Codex access is limited to selected, approved Daybreak Red customers; wider Red access is planned. This is a restricted rollout. Launch announcement.
For security teams, the first decision is which work deserves a controlled trial and what evidence would justify using the results. A more capable research assistant still needs a clear path from a finding to a reviewed, tested fix.
Read the results in context
OpenAI reports 48.5% on ExploitGym versus 32.1% for GPT-5.6 Cyber, testing exploitation of specified vulnerabilities. These vendor evaluations describe controlled tasks, not a success rate for your systems. Reported benchmark.
The November 5 system card classifies the model's cybersecurity capability as Critical under OpenAI's Preparedness Framework. It also records limitations: Cyber was less likely than Astra to stop in a warning test where stopping was appropriate. Measurement details can change, so scores across older cards are not automatically comparable.
Read that designation as a model-capability assessment, not a vulnerability severity assigned to your infrastructure. A good score is a reason to investigate a tool; it does not establish that a particular finding is correct or that an unattended workflow is safe.
Access and data handling need review
The card describes identity verification and organizational requirements including SSO, MFA, managed devices and least-privilege access. API customers using Zero Data Retention generally require Private Safety Processing. Access safeguards.
Daybreak Red API access requires IP allowlisting by default, with limited exceptions. Network-access requirement.
OpenAI's PSP documentation describes encrypted safety records in customer-controlled storage, retained for at least 30 days, and automated review in a protected runtime that disables human access. Limited safety signals and operational metadata can leave that runtime. Enabling PSP applies its policy to all API traffic in that project, not just models requiring it.
Define what a useful pilot must deliver
These are suggested acceptance checks, not hands-on test results:
- Write the decision first. Identify the maintainer who will accept or reject a finding. Agree on the evidence they need before accumulating a large queue of reports.
- Keep a reproducible record. Attach the affected revision, test conditions, observed result and unresolved assumptions. Keep confidential material in the approved reporting channel.
- Separate discovery from completion. Track a reported issue, a confirmed issue, a candidate fix and a validated fix as different states. A patch proposal does not close the ticket.
- Review the data flow. Ask the responsible team to sign off on the actual project configuration and retention responsibilities before sending proprietary code or investigation material.
Judge a pilot by the quality of decisions it enables and the work needed to validate its output, not just the number of findings. Record failures and inconclusive results alongside successes.