On August 10, OpenAI released a model trained to find zero-day vulnerabilities and write working exploit chains, and to stop saying no when someone asks it to. They call it GPT-5.6-Cyber. It is not available to you or me. It is available to people OpenAI has verified, through a program called Daybreak Red.

I want to skip past the part where everyone says this is terrifying, because the raw capability is the least interesting thing here. What OpenAI actually shipped, alongside the model, is a control set for handing a dangerous tool to specific people. That control set is the thing an auditor should read closely, because it is a near-perfect template for a question your own function has probably not scoped yet: who inside your organization can now reach offensive AI, and on whose authority.

Start with what changed, precisely, because the headline number is easy to misread.

OpenAI’s own figure is that GPT-5.6-Cyber completes 95 percent of requests involving exploit-chain development, authentication bypass, and privilege escalation, against 1.5 percent for its general model. Read the fine print on what that measures. It is an internal evaluation called the Advanced Cybersecurity Completion Rate, and it measures how often the model will respond, not how much more capable it became. The underlying capability was already there. OpenAI’s general model, Sol, was rated High for cybersecurity under their Preparedness Framework before any of this. What Daybreak Red changes is the refusal. The guardrail that used to say “I can’t help with that” is turned down for people who have been checked. OpenAI also says it used the model to find real flaws, including two previously unknown vulnerabilities in Chrome’s V8 engine that Google has since patched.

That distinction matters to an auditor, because a refusal guardrail is a control, and controls that get selectively removed for vetted users are exactly the kind of thing we test.

So look at how OpenAI decides who gets vetted. To reach GPT-5.6-Cyber, an organization or individual passes identity verification, agrees to approved-use restrictions, signs legal attestations, and accepts monitoring. From September 1, every individual Daybreak account has to use a hardware security key. OpenAI tells customers to run the model in isolated sandboxes with no path to production or the open internet, to define which systems are in scope, and to route the agent’s actions through a review step before anything executes.

Write that list out and it is not novel at all. Identity verification, scoped authorization, a signed acceptable-use agreement, strong authentication, environment isolation, and a monitored approval gate. That is the control set you would design for any privileged, dual-use capability. OpenAI built it because they are handing out something dangerous and they know their liability sits on the access boundary.

Here is the part that lands closer to home. Their controls stop at their perimeter. Once one of your people is approved, OpenAI governs that they were verified. Your organization governs what they do with the access, where they run it, and against whose systems. And the people most likely to request it are already inside your walls: your red team, your penetration testers, your vulnerability researchers, the security engineer who has spent a year frustrated that the safe models keep refusing legitimate work.

That is a privileged-access governance question wearing new clothes. We have spent much of the last year on non-human identity, on agents that hold access and act on their own. This is the mirror image. It is a very human access problem, about a person requesting a tool that produces working exploits, and whether anyone in your organization is tracking that the request happened, approved the use case, and constrained where the tool can point.

I have argued before that authorization has to become context-aware once you can no longer assume the thing holding access will behave predictably. This is the same argument aimed at a person and a subscription rather than an agent and an entitlement. The context that matters is the same: what work, on which systems, in what environment, with what oversight.

One more fact deserves attention, and I will keep my interpretation modest. SecurityWeek reports that the named Daybreak partner list includes EY, KPMG, and PwC, alongside the security vendors you would expect. I am not going to make that into something it is not. But it is worth knowing that some of the firms in the assurance and advisory business are themselves building on offensive AI capability. If your external provider runs a cyber practice, this is now part of their toolkit, and that is a fair thing to ask them about.

None of this is a finding. It is a scope. The condition that would turn it into a finding is one you can go and check: whether access to offensive AI tooling is authorized, recorded, and bounded, or whether it is happening on individual initiative with a corporate card and nobody in second or third line aware it exists.

If you run an audit function, here is what I would put on the list for this quarter.

  • Ask security whether anyone has applied for, or is using, gated offensive-AI access such as Daybreak Red, and who approved it. An empty answer is itself informative.
  • Test whether there is an approved-use scope on file for that access: which systems, which environments, and what is explicitly out of bounds.
  • Check that the tooling runs in isolated environments and cannot reach production or third-party systems the organization does not own or have permission to test.
  • Confirm the access is tied to a named, strongly authenticated identity rather than a shared account, and that removing it when someone leaves the team is part of the joiners, movers, and leavers process.

The model that writes exploits is going to keep getting better, and access to it is going to keep widening. That is not the part you control. What you control is whether, inside your own organization, that access is something you can see. Right now, for most functions, I suspect it is not, and the check to find out is a short one.