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.

A third case, from the lab that trains the model rather than a program built on top of one

Update, September 6, 2026. Daybreak and Breach360 both belong to companies operating one layer above a foundation model: OpenAI ships Codex on top of GPT-5.6-Cyber and a review step it controls; BreachLock ships an autonomous testing product on top of whichever model sits under Adversarial Exposure Validation. Anthropic's Claude Fable 5.1 and Claude Mythos 5.1, both released September 1, 2026, test the same distinction from the layer beneath both of those: not what a program built on a model permits, but what the model itself is configured to do, for whom, and on whose say so. Anthropic's own platform documentation, fetched directly for this update, describes Claude Mythos 5.1 as offering Claude Fable 5.1's own capabilities, by invitation only, as part of a program called Project Glasswing. Fable 5.1 is available to every Claude customer, on the Claude API and its partner platforms, the same day Mythos 5.1 became available to nobody who had not already been separately approved.

What "the same underlying model" is stated to establish, and what this record does not extend it to

Anthropic's own platform documentation for Claude Mythos 5.1, read directly by this session, describes it in its page metadata as "the same model as Claude Fable 5.1," and the Fable 5.1 overview page, also read directly, states that "Claude Mythos 5.1 offers the same capabilities to Project Glasswing participants only." Both models share a specifications table this record could confirm from that same primary documentation: a 1M token context window, 128K max output tokens, identical $10 per million input tokens and $50 per million output tokens pricing, the same June 2026 knowledge cutoff, and the same adaptive thinking behavior. Search engine synthesis of Anthropic's own announcement page, which this session's network egress policy blocked from direct access on every attempt, converges on a shorter framing of the same claim: that Fable 5.1 and Mythos 5.1 are the same model with different levels of safeguard. This record treats the specific, source verified claim, shared specifications and capabilities, as established, and treats the shorter paraphrase as consistent with it rather than as an independently verified quotation this session read for itself. What this record does not do is extend "the same underlying model" into a claim that every configuration setting, every deployed safeguard, or every operational detail is identical between the two; Anthropic's own documentation is explicit that what differs is the safeguard configuration each is served under, and this record holds the claim to exactly that scope.

Fable 5.1's own safeguard boundary: more precise, not open

Search engine synthesis of Anthropic's own material, converging independently across multiple secondary write ups of the September 1, 2026 announcement, describes Fable 5.1 as now usable to identify software vulnerabilities in source code, work Anthropic's earlier safeguards had treated more coarsely, while continuing to redirect penetration testing, exploit generation and binary-based vulnerability scanning to Claude's Opus models rather than answering them directly on Fable 5.1 itself. This record found one part of that claim it could confirm from primary documentation it read directly rather than through search synthesis: Anthropic's own "What's new in Claude Fable 5.1" page states that the permitted fallback targets for a declined Fable 5.1 request are Claude Opus 4.8 and Claude Opus 5, and that same page documents Fable 5.1 returning a structured refusal, stop_reason: "refusal" with a stop_details object naming the policy area that fired, for a request its classifiers decline. That primary documentation does not itself enumerate penetration testing, exploit generation or binary-based vulnerability scanning as the specific categories that trigger a refusal or a fallback; it documents the mechanism, a named policy area and a defined fallback path to specific Opus models, that the more specific claim about which cyber tasks redirect where would run through. This record treats the general mechanism as source verified and the specific task list as corroborated by convergent secondary reporting rather than independently confirmed against Anthropic's own primary text, and keeps that distinction rather than collapsing the two into one uniformly sourced claim. Search synthesis further converges on Anthropic describing its newest cyber safety classifiers as producing roughly 60 percent fewer interventions per Claude Code session than Fable 5's did, and biology safeguards intervening on benign requests roughly 85 percent less often; this record records both figures as Anthropic's own reported comparison against its prior model, not as an independently audited result, consistent with how this corpus treats a vendor's own benchmark claims elsewhere in this record for OpenAI's Advanced Cybersecurity Completion Rate figures.

Mythos 5.1: different safeguards, not absent ones, and a name that covers more than one gate

What changes for Mythos 5.1, on the same convergent search synthesis, is not the removal of safeguards but a different configuration of them: more permissive cybersecurity and life-sciences safeguards, available only to organizations Anthropic has approved through what secondary reporting names as the Cyber Verification Program for defensive security work and the Life Sciences Verification Program, described as an invite-only track built with the involvement of the US government, for advanced life-sciences research. Anthropic's own directly read platform documentation names only one program by name, Project Glasswing, as the gate Mythos 5.1 sits behind; it does not itself name the Cyber Verification Program or the Life Sciences Verification Program on either the Fable 5.1 or Mythos 5.1 pages this session could fetch. This record could not resolve, from anything it could read directly, whether the Cyber Verification Program and Life Sciences Verification Program are tracks operating inside Project Glasswing, separate programs that independently unlock Mythos-tier access, or some third arrangement; one secondary source describes Cyber Verification Program access to Mythos models as a near future addition, phrasing that reads as predating this launch, while a fresher secondary source describes Mythos 5.1 as already restricted through all three names at once. This record records the exact relationship among the three as undocumented rather than asserting a single hierarchy, and treats what it can confirm narrowly: Mythos 5.1 requires an Anthropic-administered vetting decision, by whichever named program actually decides a given applicant's case, before the model is reachable at all.

Access grantor: Anthropic's own decision, not an independent one AWS or Google Cloud makes

Anthropic's own platform documentation, read directly, tells a prospective Mythos 5.1 customer to contact their Anthropic, AWS, or Google Cloud account team for access, language that could be misread as three independent paths to the same grant. Search engine synthesis of Amazon Bedrock's own Mythos 5.1 documentation, which this session's network egress policy blocked from direct access, narrows what that AWS path actually is: Claude Mythos 5.1 on Amazon Bedrock is offered as a Preview, a Beta Service under AWS's own service terms, available only in the us-east-1 region, and reaching it requires both an invitation through Project Glasswing and a dedicated AWS account allowlisted by the Bedrock Marketplace team, with an Anthropic account executive submitting the customer's AWS account for that allowlisting. Read plainly, that sequence has one eligibility decision in it, Anthropic's own Project Glasswing invitation, and one enforcement step downstream of it, AWS allowlisting the specific account an Anthropic representative names. This record found nothing in what it could gather describing AWS independently evaluating whether an applicant should hold Mythos access, as distinct from provisioning access to an applicant Anthropic has already approved, and reads the evidence available as AWS enforcing Anthropic's own eligibility decision rather than AWS constituting a second, independent authorization architecture. This record could not confirm that reading against AWS's own documentation page directly, because this session's network egress policy also blocked docs.aws.amazon.com on every attempt, and a human editor should verify the live page's exact wording before this section is treated as fully source verified on that specific point.

What Anthropic's own trusted access architecture does not establish

Everything in the two sections above describes a decision about access to Anthropic's model service. None of it, on anything this record could find, describes a decision about authority over any resource a Mythos 5.1 user might point the model at. An organization approved through Project Glasswing, the Cyber Verification Program or the Life Sciences Verification Program has been vetted, by Anthropic, for something Anthropic itself decides: whether that organization's stated purpose fits the reduced-safeguard configuration Anthropic is willing to serve it. Nothing in what this record could verify states that the same vetting decision also establishes that a specific Mythos 5.1 user is entitled to penetration test a specific third party's network, to develop or run a specific exploit against a specific target, or to conduct a specific biological experiment in a specific jurisdiction. Anthropic's own two part structure, an organization approved once and a model configuration served to every request that organization then makes, reads on this record's evidence as a standing, coarse grained capability grant rather than a per request approval: this record found no description of Anthropic re-evaluating a named human requester's authority over a named target on each individual Mythos 5.1 call, only a description of what safeguard configuration a vetted account is served. That is the same shape this record has already named for Daybreak, a model level decision loosened for a vetted population, and it carries the same limit here: whatever authority a Mythos 5.1 organization needs over the specific system, dataset or laboratory it acts against has to come from somewhere other than Anthropic's own eligibility decision, because Anthropic's decision was never about that system, dataset or laboratory to begin with. This record also found nothing establishing how an approved organization decides internally which of its own employees may use Mythos 5.1, whether that internal decision is itself checked at any technical layer, or whether Anthropic's own vetting can be withdrawn, re-evaluated or must be periodically renewed once granted; a retirement date of not sooner than September 1, 2027 appears in Anthropic's own documentation for both models, but that is a stated commitment about how long the model itself stays available, not a statement about how long any organization's Project Glasswing membership lasts, and this record keeps the two apart rather than reading one as evidence of the other.

The Authority Provenance ledger, Claude Fable 5.1 and Claude Mythos 5.1

Authority grantor. Anthropic, for the model access decision itself. Anthropic's own directly read platform documentation names Project Glasswing as the program Mythos 5.1 sits behind, and names an Anthropic, AWS or Google Cloud account team as the contact point for requesting it; on the evidence this record could gather for the AWS path specifically, the underlying eligibility decision remains Anthropic's, with AWS allowlisting the account an Anthropic representative names rather than independently approving the applicant. This record found no equivalent detail for the Google Cloud path and records it as undocumented rather than assumed identical to AWS's.

Principal. An organization, on the language Anthropic's own documentation uses throughout, "Project Glasswing participants" and "approved customers." Whether the operative unit is the organization as a whole, a specific account or workspace inside it, or individually authorized users within an approved account is not established by anything this record could verify, and this record records that layer as undocumented rather than assuming an organization wide grant reaches every employee automatically.

Mandate or basis. Documented only at the level of purpose, not criteria. Search synthesis converges on Anthropic describing Mythos 5.1 as intended for vetted cyber defenders and life-sciences researchers doing legitimate defensive and research work, through the Cyber Verification Program and the Life Sciences Verification Program. This record found no description of the specific evaluation Anthropic runs before approving an applicant, and does not infer a complete vetting methodology from the fact that a vetting decision exists.

Delegated scope. Described only in the negative and only partially: Mythos 5.1 carries different safeguards for cybersecurity and life-sciences work than Fable 5.1 does. This record found no itemized statement of exactly which requests Mythos 5.1's remaining safeguards still decline, as distinct from what they now permit, and does not infer an unrestricted scope from the absence of that itemization.

Explicit limits. Two are documented and this record treats them as real limits rather than as evidence the model is otherwise unrestricted: Anthropic's own directly read documentation states Fable 5.1 and Mythos 5.1 carry 30 day data retention and are not available under zero data retention "unless expressly authorized by Anthropic," and Amazon Bedrock's own reported terms restrict Mythos 5.1 to a single AWS region, us-east-1, and require the customer to opt in to provider data sharing. Anthropic's own language that Mythos 5.1 carries "different," not absent, safeguards is itself a stated limit this record does not read past.

Inherited permissions or assumptions. Undocumented. Nothing this record could verify describes what credentials, network access or infrastructure permissions a Mythos 5.1 deployment inherits from the customer's own environment, as distinct from the model access Anthropic itself grants; that is a question about how a customer wires the model into its own systems, which sits outside anything Anthropic's own model access documentation addresses.

Authority escalation. This is the property this update's own research could confirm most directly, and the one this record treats as its central finding for this case. Anthropic operates a two stage structure: an organization is vetted once, through Project Glasswing, the Cyber Verification Program or the Life Sciences Verification Program, and that vetting then yields standing access to a more permissive safeguard configuration for every subsequent Mythos 5.1 request the approved account makes, rather than each individual request being separately approved by a human at Anthropic. This record found no description of Anthropic re-checking a specific request against the target, action or jurisdiction it concerns, only a description of which safeguard configuration a vetted account is served. An organization's vetted status, once granted, is documented here as changing the model's permitted behavior for that account going forward, not as a per action authorization Anthropic issues each time.

Challenge authority. Present at the model layer and undocumented beyond it. Anthropic's own directly read documentation states that both models retain safety classifiers and can return a structured refusal naming the policy area that fired, so a request that falls outside even Mythos 5.1's more permissive configuration can still be declined by the model itself. What this record found no description of is any challenge mechanism operating above the model, comparable to Codex's own auto review or Breach360's lateral movement approval gate, that would evaluate a specific Mythos 5.1 output before whatever the requesting organization does with it next; on the evidence available, the model's own classifiers appear to be the only documented check in this architecture.

Approval enforcement point and binding. Established for the access decision itself and undocumented beyond it. Amazon Bedrock's own reported allowlisting step is a real, named enforcement point for who may reach Mythos 5.1 on that platform at all. This record found nothing describing an enforcement point that binds a specific Mythos 5.1 response to a specific, pre-approved target, action or research protocol; the architecture this record could verify controls who may ask, not what a specific answer may then be used to do.

Revocation or modification. Undocumented. This record found no statement of whether Anthropic can withdraw an organization's Project Glasswing, Cyber Verification Program or Life Sciences Verification Program status, whether membership expires or must be periodically renewed, or what happens to in-progress work if it is withdrawn. A stated retirement date of not sooner than September 1, 2027 for the models themselves is not evidence about program membership, and this record does not treat it as such.

Recovery. Undocumented as a program mechanism, and structurally limited regardless: removing an organization's future access to Mythos 5.1, were Anthropic to do so, would not undo outputs the model had already produced for that organization while approved, in the same way this record has already noted elsewhere in this corpus that revoking a credential does not reverse an action already taken with it.

Evidence. Strong and source verified for the shape of the access architecture: this record read Anthropic's own Fable 5.1 and Mythos 5.1 platform documentation directly, and it states plainly, in Anthropic's own words, that Mythos 5.1 offers the same capabilities as Fable 5.1 by invitation only through Project Glasswing. It is weaker, and corroborated only through convergent secondary reporting this session could not check against Anthropic's own primary text, for the specific safeguard task list, the exact relationship among Project Glasswing, the Cyber Verification Program and the Life Sciences Verification Program, and the reported figures for reduced safeguard interventions. It is undocumented, on anything this record could gather, for vetting criteria, principal level granularity beneath the organization, revocation, and any resource level authorization beyond Anthropic's own model access decision.

Provenance evidence quality. High for the access architecture's shape, sourced to Anthropic's own platform documentation read directly by this session. Lower, at this corpus's existing manual-review grade, for Anthropic's own announcement, the Mythos product page and the Fable 5.1 / Mythos 5.1 system card, all on anthropic.com, a domain this session's network egress policy blocked on every attempt; what this record states from those pages is corroborated through repeated, independently phrased search engine synthesis converging across multiple secondary outlets rather than a direct read. Lower still, and recorded as undocumented rather than inferred, for AWS's own specific eligibility and enforcement mechanics, which this session also could not fetch directly. A human editor with unblocked access to anthropic.com and docs.aws.amazon.com should confirm the primary pages' exact wording before this section is treated as fully source verified on the points this record could not itself read.

Where this leaves Daybreak, Breach360 and Fable/Mythos together

Three companies, three different layers of the same stack, reached the same structural answer this year without describing it as the same answer. OpenAI built a model that answers more for a vetted population and paired it with an execution level review for the agent that might act on those answers. BreachLock built an agent that already acts and paired it with a second approval gate for the specific discoveries that would extend its reach. Anthropic built one model and configured it two ways, serving the more permissive configuration only to accounts it has separately decided to trust, with the model's own classifiers as the documented check on what even that more permissive configuration will do. None of the three collapses identity into a rubber stamp: a vetted population, a configured engagement and a Project Glasswing approval are each real, evidenced decisions that shape what happens next. What none of the three does, on the evidence available anywhere in this record, is let that upstream decision stand in for authority over the specific, real target the resulting request or action would reach. This corpus's own argument for why an instruction cannot carry the whole safety boundary holds one layer further back here than it does for Daybreak or Breach360: it is not only that a model's willingness to answer, or an engagement's configured scope, cannot authorize every consequential action that follows. It is that a principal's own vetted identity, verified once by the party that trains or operates the tool, cannot by itself establish what that principal is authorized to do to anyone else's system, data or research subject. Capability and authority were never the same fact. Anthropic's own architecture, read carefully rather than rounded up, is a clean instance of keeping them separate on one side, access to a model, while leaving the other side, authority over what the model's output is then used against, exactly where it already sat: with whoever actually owns the target, not with whoever Anthropic has agreed to trust.

A fourth case, arriving as a refusal rather than as a grant

The three cases above all describe an upstream decision that opens something: a vetted population that gets fewer refusals, an engagement that authorizes an offensive agent to run, an organization whose approval unlocks a differently configured model. The fourth case is the same architecture seen from the side where it closes. On 7 September 2026, GitHub issue 43320 was opened against openai/codex by a reporter identified as bcdonadio, titled "Astra High subagent hits cyber_policy after 2h of authorized CLI/database feature delivery and review," carrying the labels app, bug, safety-check and subagent, with no maintainer reply, no assignee and no comments at the time of this update. Moona Intelligence read the issue through this session's page fetch tool in two independent passes that converged on identical identifiers, timestamps and quoted text. This record treats it exactly as it treated the Codex reports it already carries elsewhere in this corpus: a credible, independently checkable description of one user's own experience, not a confirmed OpenAI defect, not an authority bypass, and not a disclosed vulnerability.

The reported sequence, in the reporter's own account. A parent coordinator task, identifier 01a07801-04af-7631-8cb2-6e14d2d71ccb, running the model string gpt-6-astra at medium reasoning effort, delegated a feature ownership lane to a depth one child task, identifier 01a07809-1c3d-7873-816d-ab1bd9fa8d1d, at the agent path /root/owner_618, running the same model string at high reasoning effort. The child worked for a reported turn duration of 7,606,164 milliseconds, slightly over two hours and six minutes, produced an implementation candidate and started independent candidate reviewers. At 2026-09-07T00:38:41.967Z, which is 02:38:41.967 on 7 September 2026 in Paris, the child turn terminated with the field codex_error_info carrying the value cyber_policy. The session's own settings at the time, as reported, were approval_policy set to never and sandbox_policy set to danger-full-access. The message surfaced to the user read, in the reporter's own quotation, "This content was flagged for possible cybersecurity risk," followed by an instruction to join the Trusted Access for Cyber program at chatgpt.com/cyber. The reporter states they hold ChatGPT Pro and had already completed Cyber and Daybreak Blue verification, and their stated confusion is precisely that: an enrollment flavored message arriving at an already enrolled account.

What makes this case worth a section rather than a footnote is what happened to the two agents afterwards, which is not the same thing. The child was terminated. The root coordinator was not. On the reporter's own timeline, less than a minute later the parent reported that a model safety check had blocked the feature lane, interrupted that lane's candidate reviewers, parked the lane while an unrelated feature continued, and carried on coordinating. State was preserved. The blocked action was not retried or resumed by a later, higher effort child turn. One task, two agents, two different outcomes, produced by a decision neither of them made.

Seven authority questions, one refusal, and why collapsing them into a single yes or no loses the finding

The temptation with a report like this is to reduce it to one sentence: the user was allowed to do the work and the system stopped them anyway. That sentence is not false, but it merges at least seven separate decisions that were each made by a different party under a different rule, and merging them is exactly the failure this record has been arguing against since its first paragraph about Daybreak. Named separately, on the evidence the report itself provides, they are these.

• The user's own mandate. A human operator set a repository feature campaign in motion and approved an implementation plan. Evidenced by the report, and not in dispute anywhere in it.
• Parent to child delegation. The root coordinator handed a bounded lane, one feature and its review coordination, to a depth one child. Evidenced by the parent and child task identifiers and the child's own agent path.
• Local tool and approval policy. approval_policy set to never, which in this runtime means the agent is not to stop and ask a human for each action. That is a statement about interruption, not a statement about permission.
• Local sandbox containment. sandbox_policy set to danger-full-access, the widest local containment setting. That is a statement about what the local machine will physically allow, not about what any remote party will agree to serve.
• Provider and model policy. The decision that actually fired, recorded as codex_error_info cyber_policy. Made by the provider, not by the operator, not by the parent and not by the sandbox.
• Account and workspace entitlement. The reporter's own stated enrollment in the cyber access program. An account and workspace state, asserted by the reporter and not independently confirmable from the report.
• Resource authorization. Whatever entitles this operator to change this repository. Established only to the extent the report describes the work as the reporter's own feature campaign in their own project, and not the layer that refused.

Enrollment in a trusted access program is an account state. Effective entitlement on one request is a different fact

This record has already drawn one version of this line, for Anthropic, in the section above titled what Anthropic's own trusted access architecture does not establish: being vetted for access to a model is not the same as being authorized to act against a target. The Codex reports sharpen a second, narrower version of the same line, on OpenAI's side of the architecture, and it is worth stating in its own words because it is easy to slide past. Being enrolled in a trusted access program is a fact about an account. Whether that enrollment was actually applied to one specific request, on one specific route, for one specific model, inside one specific organization or workspace, on one specific product surface, is a separate fact. The first does not prove the second, and no report in this cluster establishes the second.

This is not a hypothetical distinction invented by this record to preserve an unknown. OpenAI's own published troubleshooting guidance for the program draws it directly. This session's network egress policy blocked help.openai.com and openai.com on every attempted route, the same blocked domain pattern this record already carries for OpenAI primary sources, so what follows is stated at this corpus's existing manual-review evidence grade, corroborated through repeated, independently phrased search passes that converged on identical wording rather than a direct read. On that basis, OpenAI's own help centre material states that the program reduces some cyber related blocks for approved customers but does not remove every safeguard; that even after approval a user may still encounter system level safety messages that block, slow or reroute a request before completion, and separately model level refusals where the model responds but declines to help; and it names reasons an approved user may still be blocked, including that the request appears high risk or outside ordinary defensive cybersecurity use, that a standard model is being used rather than an approved cyber specialized model, that the request reads as offensive, abusive or too ambiguous to safely complete, or that a product or API safety control still applies. The same material separately states that a commercial agreement or purchase alone does not guarantee access, and that submitting an application or completing identity verification does not guarantee approval, and directs a customer with access problems after approval to work with their OpenAI contact on the appropriate setup and to contact support.

Read against the reports, that guidance does two things at once. It confirms, from the first party that operates the program, that an approved user encountering a block is a documented state rather than a contradiction in terms, which removes the strongest version of the reporters' implied claim that being enrolled should have prevented this. And it confirms that the answer depends on which model, which surface, which control and which account configuration were actually in play on the specific request, none of which any of these reports establishes for the request that was refused. This record therefore records the child's effective cyber entitlement on the rejected request as unknown, and treats resolving it as work that requires evidence only the provider holds.

Related occurrences, and what a cluster of reports does and does not establish

Issue 43320 is not isolated, and this record read the surrounding reports directly rather than accepting the primary issue's own characterization of them. Two earlier reports from the same reporter describe the same error at the root rather than at a child: issue 42906, opened 5 September 2026, describes four consecutive cyber_policy terminations of a root coordinator during multi agent bug triage, and issue 43131, opened 6 September 2026, describes three more against a root coordinator inside a single task, after which the session itself did not terminate and a retry at a lower reasoning effort resumed useful work. Four further reports from four different reporters land the same week: issue 43203, opened 6 September 2026 by drcadu-crypto and also carrying the subagent label, describes a sub agent blocked before any external command ran while preparing a specification for a defensive fix; issue 43208, opened 6 September 2026 by ychromosome, describes repeated blocks during defensive work in isolated local containers, states that the same work proceeded normally after switching to a different model, and states that an applied for Trusted Access status was not recognized; issue 43189, opened 6 September 2026 by enlaichu, is titled around exactly the mismatch this section is about, reporting a persistent block after completing Daybreak verification, with the message pointing again at the same enrollment link; and issue 43167, opened 6 September 2026 by bitplane, describes refusals beginning after context compaction during non networked debugging work, with other models completing the same work.

The earliest occurrence this session located is the one that matters most for the specific pattern issue 43320 adds. Issue 34864, opened 23 July 2026 by jyongchul, carries the same four labels including subagent, and describes a delegated sub agent blocked by the same classifier while, in the reporter's own words quoted here, "the root task and other non-helper subagents continued, so the result was a partial multi-agent failure rather than a clean, task-level policy decision." That report names a different model, a different operating system and a different product surface from issue 43320, six weeks earlier. A ninth report, issue 35212, opened 24 July 2026 by chumen77, records the messaging half of the same problem from an individually verified user, and is explicit that its complaint concerns the accuracy of the error path rather than a request to bypass any safeguard.

What this record takes from that cluster, and what it deliberately does not. It takes that a delegated child being refused while its parent continues is a repeatedly reported shape rather than a single anecdote, reported by at least two unrelated reporters against at least two different model strings across a six week gap. It takes that at least three reporters describe an enrollment flavored message arriving at an account they state is already enrolled. It does not take that these reports share one backend cause: they are reports against one product from users who cannot see the provider's decision path, they are unconfirmed by any maintainer, and a common symptom is not evidence of a common mechanism. It does not multiply their evidentiary weight as though they were independent vendor implementations of the same architecture, in the way this record does treat OpenAI, BreachLock and Anthropic as three independent instances above; these are related occurrences inside one product's own reporting stream, and this record counts them that way.

The Authority Provenance ledger for the delegated child policy refusal

Root grantor. The human operator running the campaign. Evidenced by the report's own description of an operator directed feature campaign in the operator's own project, and by the operator's approval of an implementation plan before delegation.

Root mandate. Delivery of a repository feature campaign, evidenced at the level the report states it. This record does not extend that mandate to cover the specific content the provider refused, because the report does not identify that content and this record will not infer it.

Plan approval. Evidenced as a user approved implementation plan preceding the delegation. This record keeps plan approval separate from per action approval throughout: an approved plan is an approval of a route, not of every step taken along it, the same distinction this record already draws for BreachLock's configured engagement above.

Delegated principal. A depth one child agent at the path /root/owner_618, task identifier 01a07809-1c3d-7873-816d-ab1bd9fa8d1d, distinct from its parent coordinator, task identifier 01a07801-04af-7631-8cb2-6e14d2d71ccb. Evidenced directly by the report.

Delegated scope. Ownership of one feature lane and coordination of its independent candidate review. Evidenced by the child's own agent path and the parent's own later description of parking that lane specifically while an unrelated lane continued.

Resource authority. Established only as far as the report states it, which is that the work was the reporter's own repository feature campaign. This record found nothing in the report describing an independent verification of repository ownership or entitlement, and records the layer as reporter stated rather than confirmed.

Local approval policy. approval_policy set to never. This record records what that setting means and refuses the reading it invites: it is a deterministic decision not to interrupt a human for approval, which in this runtime family means an action requiring approval is refused outright rather than auto approved. It is not a grant of authority, and it does not bind any party other than the local runtime.

Local sandbox. sandbox_policy set to danger-full-access, the widest local containment setting available. A statement about local containment only. Nothing in it constrains, or is constrained by, a decision made on the provider's side of the request.

Provider policy decision. The layer that actually refused. codex_error_info recorded as cyber_policy, surfaced to the user as content flagged for possible cybersecurity risk with a pointer to the Trusted Access for Cyber program. This record treats the refusal as real, as fail closed, and as made by a party with its own independent standing to refuse, whatever the merits of this particular decision.

Effective cyber entitlement on the refused request. Unknown. The reporter states enrollment; the report does not establish that the enrollment was applied to this request, on this route, for this model, in this organization or workspace, on this product surface. Enrollment and effective per request entitlement are kept as two separate facts here and this record resolves neither into the other.

Exact classifier trigger. Unknown. The report describes work on command line and database routing features and their review, and the refusal arrived shortly after independent reviewers were started. This record states plainly that adjacency in time is not identification of a cause, and does not name reviewer spawning, transport, accumulated context, reasoning effort or the model itself as the trigger.

Child effect. Terminated. The child turn ended at the recorded timestamp with the recorded error classification and took no further action.

Parent effect. Continued. The root coordinator reported the block, interrupted the affected lane's reviewers, parked that lane and continued unrelated coordination. This record does not read the parent's survival as evidence that the parent held an entitlement the child lacked, nor as evidence that the parent would have been permitted to make the identical request. The parent did not make that request.

Recovery. Partial and stalled. Work product was preserved and the lane was parked rather than lost, but the refused action was not retried or resumed, and a dependent deliverable stayed blocked.

Challenge or appeal path. Documented only as program guidance. The message itself points at joining the access program, and OpenAI's own troubleshooting material, at the manual-review grade described above, directs an approved customer with continuing access problems to their OpenAI contact and to support. No incident identifier, no appeal identifier and no case reference is recorded anywhere in the report, and the earliest occurrence in this cluster, issue 34864, states the same absence explicitly.

Provenance evidence quality. High for the report's own contents, read directly through this session's page fetch tool in two converging passes, and treated throughout as one user's account rather than as a confirmed platform defect. High for the shape of the cluster, each related issue read directly this session. At this corpus's existing manual-review grade for OpenAI's own program documentation, whose domains this session's network egress policy blocked on every attempt. Unknown, and recorded as unknown rather than inferred, for the provider side decision path, the entitlement actually applied and the classifier's trigger, none of which is visible from outside the provider.

What this record does not claim about these reports

Seven readings of this evidence are available and unsupported, and this record states each refusal explicitly so that no later reader mistakes silence for agreement. It does not claim that a cyber entitlement failed to propagate from parent to child; that is a specific backend mechanism no first party evidence here establishes, and it is one of several explanations consistent with the same symptom. It does not claim the provider's decision was wrong; a refusal this record cannot see the inputs to is a refusal this record cannot grade. It does not claim the parent would have been allowed to make the identical request. It does not claim that the reporter's stated enrollment proves the enrollment applied to the refused request. It does not claim that starting independent reviewers, or the transport, or accumulated context length, or the high reasoning effort setting, caused the refusal. It does not claim that a child specific refusal proves an entitlement propagation defect, since context classification, request content and configuration differences remain equally consistent with what was observed. And it does not claim that a week of similar reports proves one shared cause behind them.

What it does claim is narrower and, this record would argue, more durable than any of those. A delegated child's effective authority is not simply copied down from its parent. It is whatever survives the conjunction of the mandate that actually applies to it, the resource scope it actually holds, the execution controls its own runtime actually enforces, the identity and entitlement its own request actually carries, and the independent policy decisions of every party that must agree for its action to proceed. A parent's continuing to run is evidence about the parent, not proof about the child. That is the same argument this record has made three times already, at the model layer, at the product layer and at the vetting layer, arriving here for the fourth time through the one route that had not yet been covered: the layer that refuses rather than the layer that permits.