Frontier Model Access Programs: Planning Your Roadmap Around Cyber Capability Thresholds

On 2 September 2026, Google, Anthropic, and OpenAI each released their most capable cybersecurity models on the same day, and none of them can be bought with a credit card. Gemini 3.8 Flash Cyber, Claude Fable 5.1, Claude Mythos 5.1, and GPT-5.6-Cyber are available only to vetted partners through admission programs. The models find vulnerabilities and produce verified patches. Because those same skills work for an attacker, the labs added gates. For anyone building security automation, the best tool for the job now comes with an application form, a review cycle, and a revocation clause.

That is a procurement and staffing problem, and most AI roadmaps don't account for it yet.

What Shipped on September 2

The three launches follow the same pattern: a cyber-tuned model, a named access program, and safeguards that keep watching after admission.

Three properties of these programs matter for planning. Access depends on admission, so someone at the vendor decides whether you qualify. Access is reviewable, so qualifying once does not mean qualifying forever. Access is revocable, so it can end, and the published material says little about how much notice you would get. Orbilon's analysis of the Gemini release treats gating as the new default for the strongest security models, not as a temporary launch measure.

Gating also says something about the models themselves. Earlier this year we looked at how Mythos 5 performed on ExploitBench, moving from crash to working code execution, and at what the Anthropic espionage disclosure showed about autonomous attack agents. The September releases are where that research turns into product. When a model is good enough at offense that its vendor screens customers, it is also good enough to change what your defenders can do, and what your attackers can do.

Capability Thresholds Now Decide Who Gets the Best Model

Every major lab publishes a framework that ties capability levels to required safeguards. Anthropic's Responsible Scaling Policy sets capability thresholds that trigger stronger deployment and security measures. OpenAI's safety framework does something similar through its preparedness categories, including cybersecurity. For years these documents read like research governance. Few buyers read them.

That changed when OpenAI said its Astra model meets its Critical cybersecurity capability threshold. A threshold in a framework document is now also a product tier. Crossing it decides whether a model ships to everyone, ships to vetted partners, or doesn't ship. For anyone building a roadmap, the most capable model for a security workflow may require attestation, an approved use case, or a named entity on a vendor's list.

The other side of gating is what CISO Marketplace calls the refusal tax. General-tier models decline or water down a share of legitimate security requests because they cannot tell a pentester from an intruder. Gated tiers lower that tax for admitted users. So the gap between tiers has two parts:

• Capability gap. The gated model finds bugs, chains steps, or writes working patches that the general model can't.
• Refusal gap. The general model could do the task but declines it, or hedges until the output is useless.

Both show up in production as lower task success. You need to measure both separately, because they have different fixes. You can sometimes reduce a refusal gap by restructuring the task, adding context about authorization, or breaking the work into steps the model will complete. You can't prompt your way around a capability gap.

The roadmap question has moved from "which model is best?" to "which model can we keep?"

Treat Gated Models Like Export-Controlled Dependencies

Companies that ship physical goods across borders already know how to handle a component whose availability depends on someone else's approval. They keep a register, document the licensing basis, qualify alternate parts, and assign an owner who watches for regulatory changes. Gated AI models need the same treatment.

The OpenNash approach is a four-question access register, filled in for every workflow that touches security work.

1. Which workflows need a gated model? List them at the task level. "Vulnerability management" is too broad. "Validate whether a reported CVE is exploitable in our build" is the right size.
2. What evidence does vetting ask for? Entity details, named users, use-case descriptions, monitoring consent, and any attestations. Record when each item expires.
3. What does the fallback do to the success rate? Run the same task set on the gated model and on your best general-tier option. Record both numbers.
4. What notice do you get if access is withdrawn? Pull this from the contract or program terms. If the terms don't say, write "none stated" and plan as if it is zero.

A register entry can live next to your other infrastructure config:

- workflow: exploitability-validation
  owner: appsec-lead
  primary_model: gpt-5.6-cyber
  access_program: openai-private-safety-processing
  approved_use_case: "Internal validation of reported CVEs against owned assets"
  vetting_evidence:
    - entity_registration: current
    - named_users: [user-a, user-b, user-c]
    - use_case_attestation: expires 2027-03-01
  fallback_model: general-tier-model-x
  eval_success_rate:
    primary: null     # fill from your eval run
    fallback: null    # fill from your eval run
  withdrawal_notice: "none stated"
  runbook: runbooks/gated-model-withdrawal.md

Most security workflows will not need a gated model at all. Ticket enrichment, dependency inventory, log summarization, policy lookups, and patch review often run fine on general models. The register helps you notice the opposite mistake too, where a team picks the gated tier because it is the newest model and builds a dependency nobody needed.

If you already route tasks across models, gated access is one more constraint on the router. Our piece on model-agnostic routing covers the plumbing. What gating adds is a hard rule: some routes may disappear without warning, so the router has to know what to do when one does.

Measure the Fallback Before You Need It

Picking the fallback model is easy. Knowing how much worse it does on your work takes an eval run, and teams tend to skip it until access is already gone.

Build a task set from real work. Pull 50 to 200 completed tickets from the workflows in your register, keep the inputs, and write down what a correct result looks like: a confirmed exploitable finding, a patch that compiles and passes tests, a correct "not affected" verdict. Run the set on both tiers and score four outcomes per task.

Here is an illustrative example, not a measured result. Say exploitability validation succeeds on 82 of 100 tasks with the gated model and 61 of 100 on the fallback. Of the 21-task difference, 12 are refusals and 9 are wrong answers. That breakdown tells you a lot. Restructuring tasks might recover a meaningful share of the 12 refusals. The 9 capability misses become human workload the moment access ends, and you can turn that into analyst hours and staff for it now.

The test is worth running for the same reason we argued in Model Deprecation Migration: a planned migration takes a sprint, and a surprise one takes over the security team's quarter. Re-run the eval whenever either model changes. Fallback quality moves with each general-tier release, and sometimes the gap closes on its own.

This exercise often turns up a surprising result. For many teams, the fallback is close enough on most tasks that gated access matters for a narrow slice of work. That changes the business case. You may need one admitted team doing deep vulnerability research instead of gated access threaded through every security pipeline.

Revocation Is an Incident, Not a Contract Dispute

Revocation has already happened. Researchers lost access to OpenAI's strongest models in an incident the company described as a glitch. All five researchers TechCrunch interviewed lived outside the US and Europe. Whether it was a glitch or a policy change, the effect on those researchers was the same: a working workflow stopped working, and they couldn't do anything about it.

Several practical risks follow from that pattern.

• Geography. If your security team or contractors sit in several jurisdictions, access may not be uniform. Map named users by location in the register.
• Policy drift. Programs are reviewable. A use case approved in September can fall outside policy by March after a framework update or a government arrangement. Access terms for frontier models have already shifted this year, including gated government previews that reshaped which Claude models were available.
• Regulation. If you operate in the EU, gated access sits alongside the obligations covered in our post on EU AI Act enforcement. A model you can't document is hard to defend in an audit.
• Vendor concentration. One program covers one vendor. If every gated workflow runs through a single admission, a single review decision can take out all of them.

Write the withdrawal runbook the way you would write any incident runbook:

1. Detection. Watch for authorization errors from the gated endpoint as their own alert class, separate from rate limits and outages.
2. Automatic failover. Route affected workflows to the fallback model and mark their outputs for heavier human review, using the escalation rate you measured in your evals.
3. Communication. Name an owner who contacts the vendor's program team and a stakeholder who decides whether paused work can wait.
4. Re-admission. Keep the vetting evidence packet current so you can re-apply, or apply to a second program, within days instead of weeks.

Put the contract questions to your vendor before signing, not after. What notice period applies to revocation without cause? Does a review trigger a pause or an immediate cutoff? Can access be scoped by user so that one flagged account doesn't take down the whole entity? If the vendor won't commit in writing, write "none stated" in the register.

There is also a defensive side. Momo Advisors' read on GPT-5.6-Cyber highlights the dual-use problem behind all of this. Gating limits who gets the vendor-hosted model. It does nothing about leaked weights, misused accounts, or open models catching up. Companies running production infrastructure should assume attackers will have comparable capability, and should shorten patch cycles to match, whether or not their own defenders get admitted.

Building the Access Register Into Your Security Roadmap

The register, the fallback evals, and the withdrawal runbook take a few weeks of focused work for most security teams. The hard part is coordination. Security, procurement, legal, and platform engineering all hold pieces of the answer, and nobody owns the whole thing.

OpenNash can help with that work. We audit which security workflows really need a gated tier, design the router rules and human review gates for failover, build eval harnesses from your own ticket history, and hand over the register, runbook, and code for your team to own. If your team has no gated workflows planned yet, the right move may be a one-day review of the register and nothing more. If you are already applying to Fairwind or Private Safety Processing, the fallback eval is the piece to finish first.

To start, export last quarter's closed security tickets, tag the ones a gated model would have helped with, and book a call with OpenNash to size the fallback gap on that set before your next access review.