AI, in your work.

What OpenAI has announced

OpenAI introduced GPT-6 Cyber on November 5 for vulnerability research, initially through the API and Codex for selected Daybreak Red customers. The company reports 48.5% on ExploitGym, compared with 32.1% for GPT-5.6 Cyber. OpenAI announcement.

In a separate evaluation of exploitation of out-of-scope services, it reports avoiding that behavior in 99.93% of tests without deployment safety instructions and 100% with them. These are vendor-reported results under evaluation conditions.

What those percentages measure

The system card describes ExploitGym as a test of exploiting a specified vulnerability: success requires obtaining a success signal and confirming that the intended flaw was used. Honeypot adds an auxiliary service whose exploitation is outside the authorized scope. The observed 100% applies to that test. System card, sections 4.1 and 7.0.5.

Nexo's interpretation: these percentages cannot predict how many flaws the agent will find in an enterprise connector or guarantee that it will always respect its boundaries. Assessing a project requires evidence collected against its specific configuration.

Availability and conditions of use

As of our check, GPT-6 Cyber requires specific approval in addition to Daybreak Red. The ordinary Red application route is limited to approved business and enterprise organizations; individual applications do not include it. A purchase or contract does not guarantee access. The guide restricts Daybreak to authorized internal use, without resale or access for external users, and does not automatically grant Zero Data Retention. Access guide.

The model page lists standard short-context rates of $20 per million input tokens, $2 for cached input and $100 per million output tokens. These are API consumption prices, not a fixed quote for a security review. GPT-6 Cyber model and pricing.

When budgeting a pilot, Nexo proposes also accounting for repeated runs, environment preparation and findings review. Approval to access the model and permission to examine the project's systems should be settled separately.

What to require in the deliverable

Nexo's editorial assessment: acceptance criteria should be agreed before running the test. A useful report should distinguish what was verified, what remains unresolved and what was outside the work. We propose the following checklist for technical leads:

Synthetic example: a Business Central connector

Imagine reviewing an integration connector's custom code. The team prepares a test copy with fictional data and simulated services. It authorizes examination of the connector's permission and error handling, explicitly excluding production, real accounts and third-party services.

If the agent flags a potentially missing permission check, the deliverable should identify the affected version, preconditions and a reproducible test within the authorized environment. If it cannot reproduce the issue, the report should retain it as an unresolved hypothesis rather than present it as a confirmed vulnerability.

This is an editorial example: it describes neither a GPT-6 Cyber run nor a known Business Central flaw. Acceptance would depend on evidence and human review. A test with no findings would also be insufficient to conclude that the entire system is free of vulnerabilities.