When the Model Is Allowed to Think About the Exploit, Who Authorizes the Action?

OpenAI could have led its August 10, 2026 Daybreak announcement with the refusal rate. Reporting since has mostly done exactly that: a purpose trained model, GPT-5.6-Cyber, that answers a striking share of advanced cybersecurity requests a general purpose model would decline. That number is real and worth stating plainly. It is also not the sentence in OpenAI's announcement I keep rereading.

The sentence I keep rereading is about Codex. In the same announcement, OpenAI says it is strongly encouraging Daybreak customers who use Codex to move from full access mode to auto review mode. Put those two decisions next to each other and something becomes visible that a launch post about a less restrictive model would normally hide: OpenAI intentionally loosened what the model will discuss for trusted defenders, and in the same document, pushed harder on an independent check for what the resulting agent is allowed to actually do.

OpenAI intentionally made some cyber refusals lower

Daybreak is OpenAI's program for extending frontier AI capability to vetted cybersecurity defenders. On August 10, 2026, OpenAI restructured it into two named access tiers. Daybreak Blue gives approved defenders access to frontier general purpose models, including GPT-5.6 Sol, with safeguards tailored to authorized defensive work, and OpenAI describes it as removing certain system level cyber guardrails that can interfere with legitimate defensive workflows such as vulnerability discovery, secure code review, malware analysis, incident response and patch validation. That is a specific, bounded claim. It is not a claim that all safeguards are removed, and this article does not treat it as one.

Daybreak Red sits above Blue, for a smaller set of approved teams that can justify access to specialized cyber models, including GPT-5.6-Cyber. OpenAI describes GPT-5.6-Cyber as purpose trained for advanced cybersecurity work and designed to reduce refusals for some higher risk dual use cyber tasks: exploit validation, vulnerability research and exploit chain development that a general purpose model, working under general purpose safeguards, would more often decline. OpenAI reports that GPT-5.6-Cyber completes 95 percent of requests on its Advanced Cybersecurity Completion Rate evaluation, against 1.5 percent for GPT-5.6 Sol. That is OpenAI's own evaluation result, on OpenAI's own benchmark, and it belongs in this article as exactly that: a company reported figure, not an independently audited one. Under OpenAI's Preparedness Framework, GPT-5.6-Cyber is reported as reaching the High threshold, not the Critical one.

None of this is difficult to understand as a business decision. A defender trying to validate whether a disclosed vulnerability is actually exploitable, or trying to reproduce an attacker's exploit chain to write a detection rule, is doing legitimate work that a cautious general purpose model is built to be suspicious of. The same request that looks like an attack in isolation looks like defensive due diligence with the right context and the right account behind it. OpenAI's answer is not to make every model less cautious. It is to build a separate model, gate it behind a smaller and more vetted population, and accept fewer refusals only inside that gate. Reduced refusals for a specific model, in a specific tier, for a specific population, is a materially different claim than removed safeguards, and the distinction is the one worth holding onto through the rest of this piece.

That does not mean Codex gets unrestricted action authority

This is where the Codex language matters. OpenAI says it is strongly encouraging Daybreak customers who use Codex to move from full access mode to auto review mode, and that it is doing so through app defaults and interface changes rather than by withdrawing full access mode outright. Read that phrasing precisely, because it is easy to round up into something stronger than what OpenAI says. It is not a statement that every Daybreak user is required to run auto review today. It is a statement about where OpenAI is steering behavior, through defaults, not through a mandate applied to every existing account.

What auto review actually does, as OpenAI describes it, is narrower and more useful than the phrase suggests on its own. Auto review evaluates actions that require elevated permissions before they execute. It can block requests that pose a significant risk of destructive behavior. Neither of those is a claim that auto review blocks all dangerous actions or that it guarantees safe execution, and this article is not going to make either claim on OpenAI's behalf. What OpenAI is describing is a check inserted at a specific point in the pipeline, between a Codex agent deciding to do something that needs elevated permission and that action actually running, that can say no to some fraction of the riskiest ones. Full access mode, by contrast, is the mode where that check is not in the path. OpenAI's own product engineering reflects the same posture: safer default behavior has been built specifically for cyber specialty models, so that selecting one of them steers an active session toward reviewed, on request permissions rather than leaving a prior, more permissive setting in place unexamined.

Put the two halves of the announcement together and the shape is not subtle. Access to a model that will discuss more of a dual use cyber task got easier, for a smaller and more vetted group. Access to unreviewed execution of the actions that model's output could feed into got harder to reach by default, for that same group, in the same announcement. OpenAI moved in both directions at once, on purpose, and did not describe that as a contradiction. It should not read as one here either.

Thinking about an exploit and executing one are different control decisions

This is the part of Daybreak worth sitting with longer than a launch post usually earns. A model that has been permitted, for a vetted defender, to reason in detail about how a given exploit chain works has answered a content question. It has not answered, and cannot by itself answer, whether the agent wrapped around that model should be allowed to run the corresponding command against a specific target, in a specific environment, at this specific moment.

Those used to be functionally the same decision, because the refusal was doing both jobs. If the model would not describe the technique, the agent could not act on it either, by construction. Daybreak is a case where OpenAI deliberately separated the two, for a defined population, because the refusal was the wrong tool for legitimate defensive work and a coarse one for it besides. Once the refusal stops being the thing standing between reasoning and action, something else has to do the job the refusal used to do by accident. That is what auto review, and the guidance sitting next to it, is for. Not because OpenAI says so in those terms. OpenAI does not use the phrase execution authority anywhere in its own materials, as far as this article's research found. It is Moona Intelligence's reading of what the architecture is actually doing: OpenAI built a model level door that opens more easily for defenders it trusts, and an execution level check that it is pushing customers toward specifically because that door opens more easily now.

OpenAI defines scope outside the model too

Auto review is not the only control OpenAI names. Its published guidance for organizations building on Daybreak recommends defining which systems and actions are authorized through scoped permission profiles, sandboxing and isolating security workflows away from production systems and the open internet, monitoring agent actions, and adding further monitoring and human oversight for higher risk work. OpenAI is also requiring hardware security keys on all individual Daybreak accounts starting September 1, 2026, which is an identity control rather than an execution control but belongs in the same picture: OpenAI is tightening who can reach the gate at the same time it is loosening what happens once someone legitimate is standing in front of it.

Read that guidance for what it actually is. It is OpenAI's own recommendation to its customers, not a statutory requirement, and not a claim that following it eliminates risk. What it establishes is that OpenAI does not treat the model's refusal behavior as the only place scope gets defined. Permission profiles, sandboxing and monitoring are all controls that sit outside the model entirely. They would still matter even if GPT-5.6-Cyber refused nothing at all, and they would still matter if it refused everything, because they answer a question the model's willingness to respond was never actually equipped to answer: what is this specific deployment authorized to touch.

This is why a prompt was never going to carry the whole safety boundary

Moona Intelligence has written about this shape before, from other angles, and it is worth being precise about how this piece is not a repeat of any of them. Claude Code's auto mode is about who decides that a human needs to be interrupted at all, a classifier taking over a judgment call that used to sit with a person clicking approve. Daybreak's auto review is a narrower, more specific thing: a check on actions that require elevated permission, positioned deliberately opposite a model that has been made more willing to reason about the operations those actions might carry out. AWS's healthcare reference architecture distinguishes technical permission to call a submission tool from authorization to submit a specific consequential decision, inside a single access control layer. Daybreak's separation runs one level up from that: model level content and capability safeguards on one side, execution level authorization of the resulting agent action on the other. IBM's autonomous security agents, built partly on OpenAI's own frontier models, raise what happens once a defensive agent has the authority to remediate a live environment at machine speed. Daybreak is upstream of that question. It is about what happens before remediation, at the point where a model is first permitted to reason about the operation that a later agent might go on to execute.

What connects all of them, and what this piece adds a genuinely new instance of rather than restates, is the argument made at length in agent authority at execution: an instruction, or in this case a model's willingness to answer, is written or granted in advance, by someone who cannot fully anticipate what a specific agent will do with it in a specific environment. It cannot carry the whole safety boundary by itself. A separate, execution time decision is what applies when the agent actually arrives at a consequential action, regardless of how it got there. Daybreak makes that argument unusually legible, because OpenAI is not hiding the two layers behind one another. It named a model that refuses less. It named, in the same breath, a review step for the actions that model's reasoning could feed into. The same distinction made in instructions are not authorization, that what an agent was told is not the same as what it is authorized to do, applies here one layer earlier: what a model is permitted to discuss is not the same as what the agent built on top of it is authorized to execute.

What OpenAI has not fully specified

Some things this research looked for and did not find publicly enumerated, and it is worth naming the gap rather than filling it with an assumption.

• OpenAI does not publish, as far as this research found, a complete list of what auto review blocks by default versus what it is willing to let through, the way Anthropic's Claude Code documentation enumerates a specific block list for auto mode. OpenAI's description of significant risk of destructive behavior is a category, not an enumerated rule set.
• OpenAI's timeline for auto review becoming a stronger default, beyond app defaults and interface changes as of the August 10, 2026 announcement, is not fully specified in what this research located.
• Whether Daybreak Red engagements involving GPT-5.6-Cyber are required to route through auto review, or whether that is left to the customer's own configuration the way it is for Codex generally, is not something this research could confirm with the sourcing available.

None of those gaps change the shape of the argument. They are exactly the kind of detail that separates what OpenAI has said from what a reader might assume it implied, and this piece would rather leave them open than guess.

A second case, arriving from the other side of the keyboard

Everything above concerns a defender's tooling: a cyber model OpenAI built to help vetted teams find and fix vulnerabilities faster, with an execution level check sitting next to it. On August 26, 2026, BreachLock announced Breach360, an agentic autonomous penetration testing product it says became available immediately through the BreachLock Unified Platform, built on the Adversarial Exposure Validation architecture BreachLock has been developing since 2025. The direction of the work is the opposite of Daybreak's. Breach360 is not a model a defender queries. It is an agent BreachLock's own material describes as capable of autonomously running an offensive engagement, reconnaissance, enumeration, exploitation and lateral movement, against a customer's own web and network attack surface, inside a scope that customer configured. Moona Intelligence reads it as a second, independently arrived at instance of the argument this record has already made about Daybreak: permission to reason about an offensive technique, or in Breach360's case to actually run one, is not by itself the same decision as authorizing a specific, more consequential action the resulting agent goes on to discover it could take.

What the engagement's ordinary authority already covers

BreachLock's own product material for Adversarial Exposure Validation states that the agent autonomously moves through reconnaissance, enumeration, exploitation and lateral movement, and separately describes it as chaining individual weaknesses into full attack paths, testing business logic and pivoting between systems the way a senior penetration tester would. Breach360's own launch material describes the same behavior in more concrete, visible terms: an operator can watch Breach360 execute multi step attack scenarios in real time and follow every step of the kill chain as it happens, from reconnaissance to exploitation. Read plainly, that is BreachLock describing its own product as already authorized, inside a configured engagement, to reach as far as exploitation of the target it was pointed at, without asking again at every step along the way. This article treats that as the baseline authority the engagement itself grants: an operator turns Breach360 on against a defined target because reconnaissance, enumeration and exploitation of that target are exactly the work the engagement was created to do.

Where BreachLock's own documentation draws a second line

What the same documentation does not say is that this ordinary authority extends automatically to whatever the agent discovers next. BreachLock's Adversarial Exposure Validation product page states it directly: when AEV identifies an exploitable path that could result in lateral movement or privilege escalation, it asks for explicit approval before proceeding. Read that sentence for exactly what it commits to. The trigger is not exploitation in general. It is the discovery of a path that would extend the engagement into a new host, through lateral movement, or into a higher privilege level, through privilege escalation. BreachLock's Breach360 launch material describes the same behavior from the operator's side, and consistently pairs two controls rather than one: full control to approve or deny lateral movement, and a kill switch available at any point in the engagement. That is the phrasing this article found repeated across BreachLock's own material for Breach360 specifically. A looser paraphrase, that an operator can approve or deny lateral movement and exploitation before AEV proceeds, also turned up in this article's research, but not as language this article could confirm sits on BreachLock's own product page in that form, and this article is not treating a looser secondary phrasing as equivalent to BreachLock's own more precise, repeated statement where the two do not fully agree. What this article treats as established, because BreachLock's own product material says it directly and repeatedly, is the narrower claim: a newly discovered path toward lateral movement or privilege escalation is the trigger for a fresh approval. What this article does not treat as established is that every act of exploitation inside the originally scoped target independently requires that same fresh approval, because BreachLock's own material describes ordinary exploitation as work the engagement already authorizes.

Scope selection is a configuration input. Whether it is also an enforced runtime boundary is not established here

BreachLock's own material says an operator can select a target by IP, domain, hostname, application or API endpoint, choose which threat groups to emulate, set testing intensity from stealthy and quiet through extreme and rapid, set a severity threshold, select specific TTPs mapped to MITRE ATT&CK, and schedule an engagement as one time or recurring. Those are real, specific configuration dimensions, and this article treats them as exactly that: inputs an operator sets when standing up an engagement. What this article did not find documented anywhere in BreachLock's own material is the separate, more consequential claim that a specific execution component, an orchestration runtime, an execution engine or a target connector, independently re-checks a proposed action against that configured scope at the moment the action is attempted, as distinct from the scope the engagement was launched with. A target list an operator configured is strong evidence of what the engagement was set up to cover. It is not, on the evidence available here, itself proof of where or how the autonomous execution system enforces that boundary once the agent is running. This article records that enforcement point as undocumented rather than assuming the interface's scope selector doubles as the runtime's own boundary check.

Company scale, a training corpus and Breach360 adoption are three different numbers

BreachLock describes its penetration testing business as serving more than 1,200 customers across more than 20 countries, and describes the agentic AI behind Breach360 and AEV as trained on more than 40,000 real world penetration testing engagements. Both figures are real, and both describe something other than how many organizations are actually running Breach360 today. The figure above 1,200 is BreachLock's company wide customer count across its full portfolio, penetration testing as a service, attack surface management and autonomous testing together, not a Breach360 specific deployment count. The figure above 40,000 describes the intelligence BreachLock's agentic AI was trained on, a claim about training data, not about how many organizations have since put Breach360 into production. This article found no published figure, from BreachLock or from independent reporting, for how many organizations are actually running Breach360 specifically, and records Breach360's own active adoption as undocumented rather than inferring it from either of the two much larger numbers BreachLock does publish.

The Authority Provenance ledger for Breach360

Several distinct actors sit inside this architecture, and this article does not collapse them into one generic user. The BreachLock tenant, the customer organization whose contract covers the engagement, is not necessarily the same actor as the security administrator who configures a specific Breach360 engagement inside that tenant. Neither is necessarily the same actor as whichever person receives and acts on a lateral movement or privilege escalation approval request. None of those three is the Breach360 agent itself, the autonomous technical principal actually running reconnaissance, enumeration and exploitation, and none of them is BreachLock the platform operator. None of them, in turn, is necessarily the owner of the target asset being tested, when that owner is a separate party from the BreachLock customer: a third party vendor, a cloud provider, or a business unit that did not itself configure the engagement.

Authority grantor. Layered, not singular, on the evidence this article could verify. The BreachLock tenant relationship establishes which organization holds a Breach360 license at all. A security administrator inside that tenant configures a specific engagement, its scope, TTPs, intensity and schedule. A human approver, who this article could not confirm is always the same person as the engagement's configurer, decides whether a discovered lateral movement or privilege escalation path may proceed. None of those three is documented, anywhere this article could verify, as itself constituting proof that the configuring party held the organizational or legal entitlement to authorize offensive testing against the specific target selected.

Mandate or basis. The configured engagement is strong evidence of immediate technical mandate: an administrator with a Breach360 license pointed the agent at a target and it began work. Whether that administrator was legally or organizationally entitled to authorize exploitation of that specific target is a separate question, and this article did not find BreachLock's public material describing a technical mechanism, comparable to a domain verification step or a signed authorization to test attestation, that independently confirms asset ownership before a target may be configured. BreachLock's marketing for its human led penetration testing service describes its own experts as confirming the assets a customer wants tested before an engagement begins, which is a real control on that separate, human led service. This article found no equivalent statement, for Breach360 or AEV specifically, describing an enforced ownership or authorization to test verification step ahead of autonomous exploitation. This article records upstream authority to test the selected target as undocumented and external to what BreachLock's own material establishes, rather than inferring it from the fact that a target was successfully configured.

Delegated scope. Documented as configuration: target selection by IP, domain, hostname, application or API endpoint, threat group emulation, testing intensity, severity threshold, TTP selection and scheduling. This article keeps that configuration layer separate from a claim about per action approval, because BreachLock's own material describes them as different things: scope is set once, when the engagement is planned, and approval is asked for again, specifically, when the agent discovers a path toward lateral movement or privilege escalation.

Explicit limits. Attributed to the specific behavior BreachLock's own material actually describes, not pooled into one generic guardrail. Ordinary reconnaissance, enumeration and exploitation of the configured target is authorized by the engagement itself, on BreachLock's own description of what Breach360 already does without asking again. A newly discovered path toward lateral movement or privilege escalation is documented as requiring a separate, explicit approval before the agent may proceed. A kill switch is documented as available to the operator at any point during the engagement. This article did not find BreachLock's material stating that every operation class shares one identical policy, and does not describe the limits that way.

Inherited permissions or assumptions. Undocumented. BreachLock's own material describes Breach360 as deploying agentlessly, without hardware or complex setup, and this article's research did not surface a public description of whether the agent operates with network credentials, test accounts, cloud credentials, scanner identities or other customer provided authority supplied at engagement configuration, as distinct from access the agent establishes for itself during reconnaissance and exploitation. Where BreachLock's material is silent on that mechanism, this article records it as unknown rather than assuming a specific credentialing model.

Authority escalation. This is the dimension BreachLock's own material addresses most directly, and the one this article treats as its central finding. BreachLock's architecture distinguishes an action already inside the engagement's autonomous authority, reconnaissance, enumeration and exploitation of the configured target, from a newly discovered action that would expand reach or consequence, a new host reached through lateral movement, or a higher privilege level reached through privilege escalation, and documents the second category as requiring a fresh, explicit human decision the first category does not. That is a real, product level implementation of the distinction this record has argued for Daybreak from the model side: the mandate that authorized the engagement does not, on BreachLock's own account of its own product, automatically authorize every more consequential path the agent discovers while carrying it out.

Challenge authority. BreachLock's material documents that an approval request exists and that an operator can approve or deny it. This article did not find BreachLock's public material specifying who receives that request inside a customer organization, whether the engagement's own configurer can approve it themselves or whether a separate operator must, whether approval is synchronous or can wait indefinitely, whether a denial stops only the specific discovered path or halts the entire engagement, or exactly what information a reviewer sees when deciding: the specific host, credential, command and expected effect, as opposed to a higher level description of the path. This article records those mechanics as undocumented rather than assuming the more protective reading.

Approval enforcement point and binding. BreachLock's material proves the behavior exists, an operator is asked and can say no, and proves the product surfaces it in the interface. It does not, on anything this article could verify, name the specific technical component, an orchestration runtime, an execution engine or a target connector, that actually blocks the action until approval exists, and it does not state whether a granted approval binds to the exact target, host, technique, command and expected effect the agent proposed, or to a broader category the agent could vary within once approved. This article records the enforcement location as undocumented, and does not treat the product's own attack path visualization, real and detailed as it is, as proof of a specific binding it did not find separately documented.

Revocation or modification. A kill switch is documented as available to the operator at any point. What this article did not find documented is the kill switch's precise effect: whether it halts the agent's active loop, prevents only new commands from being issued, terminates an already established session, or reaches an action already mid execution when the operator activates it. This article represents the kill switch as a control that lets an operator stop further autonomous execution, because that is what BreachLock's material actually states, and does not extend that into a claim about cancelling an action already in flight, because BreachLock's material does not say that.

Recovery. Undocumented as a generic mechanism. BreachLock's material describes real time attack path visualization, live screenshots and proof of exploitability as what the platform produces during and after an engagement. It does not describe, anywhere this article could verify, a generic Breach360 specific mechanism for reversing effects an autonomous engagement produced: accounts the agent created, sessions it opened, privileges it escalated or state it modified during lateral movement. This article does not infer a cleanup mechanism from the fact that traditional human led penetration testing engagements typically include one, and records recovery as operation specific and undocumented for Breach360's autonomous path.

Evidence. Strong for exploitability, weaker for the authorization decision itself. BreachLock documents real time attack path visualization, live screenshots, proof of exploitability and audit ready reports mapped to compliance frameworks including SOC 2, PCI DSS, ISO 27001 and HIPAA. That is genuine evidence that a given path was exploitable and that the engagement produced a specific technical result. It is a different thing from evidence that the underlying data model stores the authorization decision itself: who requested the escalation, who approved or denied it, when, and what specific action that decision then bound. This article found the first kind of evidence well documented and did not find the second kind documented at all, and keeps the two separate rather than letting a visualized attack path stand in for a stored authorization record.

Provenance evidence quality. Uneven across layers, in the same shape this article has now found in every comparable architecture Moona Intelligence has reviewed. BreachLock's own material is specific and repeated on the existence of the lateral movement and privilege escalation approval gate, the kill switch, and the scope configuration dimensions, corroborated across independently phrased search passes this session ran against BreachLock's own product and launch material after this session's network egress policy blocked direct access to breachlock.com and businesswire.com. It is undocumented, on the same research, on the mandate layer, whether the configuring administrator was entitled to authorize testing against the selected target; on the exact binding between an approval and the action it authorizes; on the specific component that enforces that approval before execution; and on what a kill switch or a revoked approval does to an action already under way. Strong evidence at the engagement and approval trigger layers does not convert into evidence at the mandate, binding or in flight enforcement layers, and this article does not let it.

Who authorized it to actually do it

Everyone is going to keep talking about OpenAI giving trusted defenders a cyber model that refuses less. That is a real change and a defensible one, aimed at a real problem: legitimate defensive work that a cautious general purpose model was never well built to distinguish from an attack. What I think actually matters sits one step further along. Once refusal was no longer supposed to be the main control, OpenAI had to put a control somewhere else, and it did: a review step before elevated actions execute, permission profiles that define what is authorized, sandboxing that keeps agent workflows away from production and the open internet, and monitoring for the higher risk work that gets through.

If a model is allowed to explain exactly how an operation would work, the safety question that is left is not whether it should have been allowed to explain it. That is the question Daybreak Blue and Red were built to answer differently for a vetted population, and OpenAI is explicit about the scope of that answer. The question that remains, for every action the resulting agent might go on to take, is simpler to see once the refusal has stepped out of the way: who authorized it to actually do it.

Where this sits against Daybreak, and against the rest of Moona's coverage

Daybreak and Breach360 arrive at the same distinction from opposite directions. OpenAI built a model that answers more cybersecurity questions for a vetted population, and paired it with an execution level review for the Codex agent that might act on those answers. BreachLock built an agent that already runs offensive techniques autonomously, reconnaissance, enumeration and exploitation, and paired it with a second, explicit approval gate for the specific discovered actions, lateral movement and privilege escalation, that would extend the agent's reach beyond what the engagement already covers. One record is about a company deliberately loosening what a model will discuss. The other is about a company that never gated discussion in the first place, because its product performs the action rather than describing it, and that instead gates the moment the agent's own discovery would take it further than the engagement it was launched under. IBM's autonomous security agents, built for remediation rather than offensive testing, raise the mirror image question, what authority a defensive agent has once it can act on a live environment at machine speed, and this article keeps that evidence in its own place rather than importing Breach360's approval gate into a different product's documented behavior. What both Daybreak and Breach360 confirm, independently, is the argument at the center of agent authority at execution: a mandate granted in advance, whether that mandate is a model permitted to answer or an engagement authorized to run, cannot by itself carry every more consequential action the resulting agent later discovers it could take. Something else has to decide that, at the moment the agent actually arrives there. Two companies, working on opposite sides of the same problem, built that something else this year, and neither described it as optional.