Cyber Capability Gates Are Becoming Product SKUs: Allowlist AI Cyber Model Access by Agent Role

Between September 1 and September 3, 2026, three vendors shipped a cyber-gated model in three days, and none of the three gates is a setting you can grep for. Anthropic put Claude Mythos 5.1 behind trusted-access programs and, for now, a short list of US organizations. Google put Gemini 3.8 Flash Cyber behind the Fairwind Program. OpenAI put GPT-6 Astra’s fuller cyber capability behind Daybreak, plus a workspace toggle that ships off. The capability is now a SKU, a SKU is an entitlement, and an entitlement held by an agent is a credential you have to inventory.

The move for Tuesday is one allowlist that says which agent roles may hold AI cyber model access, through which vendor path, with what account security, and where the evidence lives. Add two things no vendor gives you: a log shape for every session run on a gated model, and a revoke path you have rehearsed with a stopwatch.

The live threshold essay covered the controls to put in front of a cyber-capable model on launch week: a kill switch, a replayable log, human gates. This piece is the layer above it, the entitlement layer: who is allowed to hold the key at all, and how you prove it.

Sep 1–3, 2026: three cyber SKUs in three days, three ways in

The pattern is the same across all three, and the vocabulary is not. Read the three dialects once, then stop re-reading launch posts.

Anthropic, September 1. Claude Fable 5.1 and Claude Mythos 5.1 launched together, and the launch page draws the line plainly: “Claude Fable 5.1 and Claude Mythos 5.1 are the same model, but with different levels of safeguards. Fable 5.1 is generally available, while Mythos 5.1 is available only through our trusted access programs.” The programs are the Cyber Verification Program and the Life Sciences Verification Program, though the CVP’s own description says it covers Opus- and Sonnet-class models today and adds Mythos-class models “in the near future.” Access is narrow for now: “Currently, it is only available to a set of US organizations” (Anthropic).

The developer docs describe the same access as Project Glasswing participants only, reached through your Anthropic, AWS or Google Cloud account team (Claude Platform docs).

The GA model moved too. Anthropic now allows Fable 5.1 “to be used for identifying software vulnerabilities” and says Claude Code users “can expect an average of around 60% fewer interventions per session from our cyber safeguards, relative to the previous safeguards on Fable 5.” The dual-use work is still routed to Opus models: “This includes penetration testing, exploit generation, and binary-based vulnerability scanning.” That redirect matters for step 4 below, because a session you think ran on one model may have been answered by another.

Google, September 2. The Gemini 3.8 post introduces Flash and Flash Cyber side by side, and the second one is gated: “3.8 Flash Cyber ships with a more permissive set of mitigations for cybersecurity, and as such, is only available to trusted defenders who require a more comprehensive set of cyber capabilities.” Who counts as trusted is a list, not a form field: “Through our new Fairwind Program, we’re providing trusted government authorities, as well as critical infrastructure operators and software maintainers with prioritized access to Gemini 3.8 Flash Cyber” (Google). No price is published for the Cyber variant. Note that Google’s phrase is “only available to trusted defenders,” not defenders-only; the difference is who decides.

Screenshot: Google, “Introducing Gemini 3.8 Flash and 3.8 Flash Cyber” (Sep 2, 2026), captured Sep 19, 2026.

OpenAI, September 3. The September 1 safety post had already set expectations: “We plan to make Astra available soon, but access to its most advanced cybersecurity capabilities will be more limited” (OpenAI). Two days later GPT-6 Astra shipped as one model id with two behaviors: the GA version “will refuse to comply with more advanced cybersecurity tasks such as creating proof-of-concept exploits for vulnerabilities,” while “defenders can use it to complete tasks such as secure code review and patching.” For enterprises the gate starts closed: “Enterprise administrators can enable Astra for their workspace; access is off by default at launch” (OpenAI).

The wider capability lives in the system card under Trusted Access for Cyber: “Trusted Access for Cyber, also known as Daybreak access, helps qualified organizations and practitioners use advanced cybersecurity capabilities for authorized defensive work.” The account-security rule is explicit: “Individual members must enable Advanced Account Security to use Daybreak Blue; those who do not will receive standard access,” with “availability expanding in phases” (OpenAI system card).

Screenshot: OpenAI, “GPT-6 Astra” system card, section 10.2.6.2 “Cybersecurity - Trusted Access for Cyber” (Sep 3, 2026), captured Sep 19, 2026.

That is the news. None of the three publishes how a grant is revoked, how it is scoped to a role inside your organization, or what logs you get back. The docs do not say, which is why the rest of this is yours to write.

An agent holding a gated model is a privileged user, not a smarter chatbot

A human analyst with Daybreak access is a person with a badge. An agent with the same access is a process that runs at 3 a.m., fans out subagents, and holds whatever tokens its harness was started with. The privileged-user argument already applies to any agent with a shell; a cyber SKU raises the stakes on the same shape, because the model on the other end will now do vulnerability work the GA model would have refused.

Anthropic’s September 2026 misuse report puts the operator obligation in one sentence: “Organizations should treat AI keys and agent integrations with the same level of seriousness as they do production credentials—because attackers treat them with the same level of seriousness, too” (Anthropic). A key that unlocks a trusted-access model is that sentence with the volume up.

The runbook: an allowlist for AI cyber model access

Six steps: two for the allowlist, two for the paper and the log that make it enforceable, two for how it ends.

1. Inventory every path a cyber SKU can enter your fleet

Before you decide who may hold the access, find out who already could. The entry paths differ by vendor, and two of them do not go through your API keys.

Three entitlement dialects side by side, as published Sep 1 to 3, 2026. Quoted phrases are the vendors’ words; the rest is our summary.

Walk each column with your own inventory in hand. There are five entry paths, and only the last one lives in files you control.

• The workspace toggle. Astra’s enterprise gate is a console setting. Find out whether it is on, who flipped it and when, and which seats inherit it. If the console keeps a record of the change, copy it into your own log; its retention is not yours.
• A program grant. Fairwind, the CVP and Daybreak all start with an application or a verification request. Find the human who submitted it, the principals it named, and any term the vendor stated. The receipt becomes an entitlement file (step 3).
• An account-team grant. Mythos 5.1 arrives through an Anthropic, AWS or Google Cloud account team, so the record is whatever that team sent you plus any change it made to your model access. Find both.
• Individual verification. Daybreak lets individuals verify their identity and request access, and an individual member needs Advanced Account Security on to use Daybreak Blue. Each verified human is a row in your allowlist, not a note in a channel.
• Harness defaults and gateway routes. Any config a coding harness reads, and any route your gateway serves, can name a gated model id or an alias a vendor might route to one.

The grep is the part people skip. Run it across every config a coding harness reads, and across your gateway’s route table:

# illustrative: find every model reference that could resolve to a gated SKU
grep -rniE 'mythos|flash-cyber|daybreak|astra' \
  ~/.claude ~/.codex ~/.config/*agent* ./gateway/routes.yaml 2>/dev/null \
  | grep -viE 'changelog|readme'

Anything that matches goes on a list with an owner’s name next to it. Empty output is a finding too: it means the only entry paths are the vendor consoles and the account team, which are the two you cannot grep.

2. Write the allowlist: role by SKU by entitlement path by evidence

The allowlist is a table, and it is the deliverable. Roles are yours, SKUs are the vendors’, the entitlement path is the program or toggle, and the evidence column is the file that proves the row:

Role	Model SKU allowed	Entitlement path	Evidence you keep
AppSec engineer, interactive	GA models: Fable 5.1; Astra once the workspace toggle is on	Vendor GA plus workspace enable	Toggle audit line; transcripts
Vulnerability-triage agent, headless	One gated SKU, if admitted: Flash Cyber via Fairwind, or Mythos 5.1 via your account team or, once it covers Mythos, the CVP	Program grant on a dedicated service principal	Entitlement file; per-session pack
Patch-drafting agent, opens PRs	GA models only	None beyond GA	Pull-request trail
Detection-engineering agent	Daybreak if admitted; standard access until then	Daybreak; Advanced Account Security on the owning human	Entitlement file; per-session pack
Red-team or exploit validation	No agent role; human-run	CVP-class or Daybreak, human at keyboard	Named human, dated grant
Every other coding agent	GA models; gated SKUs denied	None	Inventory row proving absence

Three rules make the table hold. One role, one SKU: an agent that can pick between a gated model and a GA one at runtime is two agents wearing one badge. Headless roles get their own principal, never a person’s account, for the reasons the service-principal runbook spells out; the headless trust tier already argues that unattended agents get less, not more. And the denied row is a row, not an omission, so the next auditor can see the decision was made rather than missed.

The table will look thin the first week, because most fleets have zero gated grants and six roles that would like one. That is the correct shape; rows are added when an application is approved, never before.

3. Document each entitlement as a file, not a Slack thread

Every allowlist row that names a gated SKU points to one file. The file is boring on purpose:

# illustrative: entitlements/gemini-38-flash-cyber.yaml
sku: "Gemini 3.8 Flash Cyber"
vendor_program: "Fairwind Program"
granted_to: "org"
applied_by: "a.rivera"
applied_on: "2026-09-08"
confirmed_on: "2026-09-15"
vendor_expiry: null            # the docs do not say; review every 90 days
holders:
  - principal: "svc-vuln-triage"
    role: "vulnerability-triage-agent"
    account_security: "sso; hardware key on the owning human"
    owner: "a.rivera"
    expires: "2026-12-14"
logging: "evidence/2026/09/cyber/<session-id>/"
revoke: [holder row, principal key, gateway route, vendor contact]

Two fields carry the weight. vendor_expiry: null is honest; none of the three vendors publishes a term, so the file says so and sets its own. And the revoke list is written before the grant is used, because a revoke path invented during an incident is a guess with a timestamp. Keep the files in the allowlist’s repository, reviewed through the same pull requests.

4. Log sessions on a gated model differently

A session on a gated SKU gets everything a normal session gets, plus three fields that only matter here. The evidence-export drill covers the pack itself; this is the delta.

Field	Why it exists on a cyber-SKU session
Served model id, where the response reports it	Anthropic redirects dual-use tasks from Fable 5.1 to Opus models, so a session filed under one SKU may have been answered by another. Record what came back; the docs do not say how a redirect shows up.
Entitlement file hash	Ties the session to the grant; a later revoke can find every session it covers.
Refusal and redirect events	Astra “will refuse” exploit creation on standard access; a refusal on a gated session means the grant did not apply.

A refusal rate that jumps is the cheapest signal you have that an entitlement lapsed, an account lost its Advanced Account Security setting, or a phase rolled back. Alert on it the way you alert on 401s.

5. Revoke on four levers, and rehearse it

Revoke is not one action, because the entitlement was never one thing. Pull all four, in this order, and time it.

1. Your allowlist. Delete the holder row and commit it. Nothing downstream should read a SKU the table does not grant.
2. Your credential. Rotate the service principal’s key. If the agent ran under a human’s account, that human re-verifies, which is the moment you learn why step 2 wanted a dedicated principal.
3. Your route. Remove the gateway route or harness config that named the model. The grep from step 1 is the verification.
4. The vendor’s side. Astra has a workspace toggle. Mythos went through an account team, so the revoke goes back through them. Gemini 3.8 Flash Cyber came through a program application, and the docs do not say how an organization leaves it. Write the contact you would use into the entitlement file today.

The vendor owns one box. The other six are records you keep, and revoke is the one you rehearse.

Rehearse it quarterly on a non-production principal. The number you write down is the minutes from the revoke command to the first failed call, and the target is under fifteen for the three levers you own. The fourth lever is measured separately, because it is not yours.

6. Re-certify every 90 days

Each entitlement file gets a 90-day review with three questions: is the owning human still here, is the role unchanged, and were the sessions read. Three yeses renew the expires date. Anything else goes to step 5. OpenAI describes Daybreak availability as “expanding in phases,” and Anthropic says it is “coordinating with the US government to expand access to a broader set of domestic and international partners as quickly as possible.” Your calendar says every quarter, and the calendar wins because it is the only one of the three you control.

Where cyber model access drifts, and the signal for each

Failure	The signal	First move
GA models do the defensive work, so nobody inventories the gate	Fable 5.1 finds vulnerabilities; Astra reviews and patches; nobody applied	Inventory GA access too; the denied rows make the boundary visible
A redirect you did not plan	The served model id differs from the SKU in the allowlist row	A routing event with different safeguards; file under both
An account-team grant with no record	A model id is callable and no entitlement file names it	Create the file retroactively, confirmed_on set to the day you found it
Advanced Account Security silently off	Refusal events rise on a Daybreak-labelled session	Re-verify the owning human; until then the row is standard access
The grant outlives the person	The owner has left; the principal still works	Revoke on all four levers; re-apply under a new owner if the role survives

The common thread is that every failure is invisible in the vendor’s console and visible in your allowlist, if you kept one. Consoles show what is enabled. Only your table shows what was decided.

Which agents may hold a gated model is an operating decision

A gated model is the vendor’s decision about capability. Which of your agents may hold it is an operating decision, and it belongs in the same place as the rest of your restricted-mode fleet policy: a written list, per role, of what each agent may reach. The host inventory for computer-use models asks which machines an Astra-class model can drive; this piece asks which agents may ask it the harder questions. On a corporate Windows fleet the two overlap, so the endpoint policy for computer-use models should name the allowlist.

Nothing here requires a vendor feature that does not exist. It requires a table, a few files, a grep, and fifteen quarterly minutes with a stopwatch. That is less than the application form took.

FAQ: AI cyber model access for agents

Which AI models are restricted to trusted defenders?

The three September launches: Gemini 3.8 Flash Cyber through Google’s Fairwind Program, Claude Mythos 5.1 through Anthropic’s trusted-access programs (currently a set of US organizations), and the Daybreak level of GPT-6 Astra through OpenAI’s Trusted Access for Cyber. Each vendor decides who qualifies; none publishes revoke mechanics.

Should an AI agent be allowed to use a cyber-gated model?

Only a named role on a dedicated service principal, with an entitlement file recording the grant, a per-session log that captures the served model id, and a rehearsed revoke path. Interactive human use is a separate row. Split any agent that can choose between a gated and a GA model at runtime.

Sources

• Anthropic: “Introducing Claude Fable 5.1 and Claude Mythos 5.1” (Sep 1, 2026)
• Claude Platform docs: Claude Fable 5.1 model page
• Google: “Introducing Gemini 3.8 Flash and 3.8 Flash Cyber” (Sep 2, 2026)
• OpenAI: “GPT-6 Astra” launch page (Sep 3, 2026)
• OpenAI: GPT-6 Astra system card, “Trusted Access for Cyber” (Sep 3, 2026)
• OpenAI: “The path to Astra” (Sep 1, 2026)
• Anthropic: “Detecting and countering misuse of AI: September 2026”