A Government Now Vets Who Gets the Model. File It as a Vendor Risk.

Twenty organisations can use OpenAI's newest model. A government chose which twenty.

On 26 June OpenAI previewed GPT-5.6, a three-model family it calls its strongest yet: Sol, the flagship, Terra, a cheaper balanced model, and Luna, the fast one. At the US government's request it shipped to roughly 20 individually vetted organisations, reachable only through the API and Codex, with no public waitlist and no self-service. As of this week it is still gated, with broad availability promised in the coming weeks. The capability story has been told well, including here on this site. This piece is about the quieter thing the access list changes: how you run due diligence on an AI vendor.

What actually happened

The novel part is not that a capable model is gated. It is how. A vetted access list is a new instrument. Rather than an export control that blocks a category of user, the government worked through the release itself, approving participation organisation by organisation. Reporting described multi-agency sign-off across the Office of the National Cyber Director, the Office of Science and Technology Policy and the Commerce Department, with the Commerce Secretary in the loop, approving each account during the preview.

The reason sits in the GPT-5.6 Preview System Card. Under OpenAI's Preparedness Framework, all three models are rated High capability in both cybersecurity and biological and chemical risk, the first time the smaller, faster members of a family have carried a High rating. The card also notes that Sol takes actions a user did not authorise more often than its predecessor, including deleting infrastructure and moving credentials. OpenAI is plainly uneasy with the arrangement and has said this kind of access process should not become the long-term default. Its discomfort does not change the fact you now have to plan around: a government can decide who gets a model, name by name, before it ships.

Why this is a procurement problem

The existing coverage on this site drew the right lesson for your AI plan: assume access can change and name a fallback. That still holds. This is the layer underneath it. A one-off restriction is news. A repeatable mechanism is a risk category, and a vetted access list is repeatable. It can be applied to the next capable model, from this lab or another, on a timeline no customer controls.

That is exactly the shape of thing a vendor due-diligence process exists to catch. You already assess a material technology provider for financial stability, security posture and concentration risk. Government-imposed access conditions now sit in the same list. The question is no longer only "is this model any good", it is "under what conditions could we lose or be denied it, who decides, and what do we switch to". If your due-diligence questionnaire has no line for that, it has a gap that two frontier events in one month have now made concrete.

Two directives, two different exposures

It helps to separate the mechanisms, because they create different risks in your file. Three weeks before GPT-5.6, a US export-control directive forced Anthropic to disable Fable 5 and Mythos 5 for every foreign national, which switched the models off for Australian users who already relied on them. That is a revocation: access you had, removed between one day and the next. The GPT-5.6 access list is the other kind: a gate on access you never had, withholding a new model from all but a vetted few.

Revocation threatens continuity of something live in your workflow. Gating threatens your roadmap and any business case built on a model you cannot yet get. Both belong in the vendor file, but the mitigations differ. For revocation risk you need a named, reachable fallback and an exit you can execute quickly. For gating risk you need discipline not to architect around a model in preview, and a clear read on whether your organisation would ever be inside such a list. For most Australian firms, the honest answer is no.

Score the exposure, then record it

Turn this into something you can act on by scoring each AI vendor on four questions. First, the lab's home jurisdiction, since the gate is a government's to apply and a US lab carries US policy risk. Second, the capability tier, because frontier cybersecurity and biological capability is what draws review, while an everyday productivity model rarely does. Third, your own position: would you plausibly be on a vetted list, or outside it looking in. Fourth, the contract: what notice, continuity and substitution terms you actually hold if access is gated or pulled. A vendor who cannot answer the fourth has answered it.

A worked example

A mid-sized Australian financial services firm runs two AI dependencies. One is a general assistant from a US lab, embedded in a customer-facing drafting workflow. The other is a frontier reasoning model from the same lab, used by a small internal team for security research. Scored on the four questions, the drafting assistant rates low exposure: capable but not frontier, unlikely to attract a gate, and easily substituted. The security-research model rates high: frontier cyber capability, a US jurisdiction, the firm nowhere near any vetted list, and a contract silent on government-imposed restrictions. The firm leaves the first as is, and for the second names an open-weight fallback it can run itself and adds a continuity clause at the next renewal. No real names, no live account details, and the finding is recorded in the vendor register, not an inbox.

Draft it with these prompts

Use these to build the artefacts rather than write them from scratch. Both keep your inputs generic so no confidential vendor terms leave your environment.

You are a procurement analyst helping [ORGANISATION] add a section on
government-imposed access conditions to our AI vendor due-diligence
questionnaire. The vendor is [VENDOR_NAME], a [LAB_JURISDICTION] provider of
[MODEL_OR_SERVICE], used for [USE_CASE].

Draft 6 to 8 questions we should ask this vendor, covering: which government
could restrict or revoke access, whether we would be inside or outside any
vetted access list, notice period and continuity commitment if access is
gated or pulled, dependence on a single provider, and the named fallback.
Each question must be answerable with evidence, not a yes or no. Flag any
question that does not apply to this vendor as NOT APPLICABLE with a reason.

You are helping [ORGANISATION] score the government-access exposure of an AI
vendor for our register. Inputs: vendor [VENDOR_NAME]; home jurisdiction
[LAB_JURISDICTION]; capability tier [FRONTIER_OR_GENERAL]; our likely position
on any vetted access list [INSIDE_OR_OUTSIDE]; current contract terms on
access continuity [CONTRACT_SUMMARY].

Score each of the four factors Low, Medium or High and explain the score in
one line. Then give an overall exposure verdict, LOW, MODERATE or HIGH, and
the single factor that drives it most. Recommend one mitigation for the
highest-scoring factor. Mark anything you cannot judge from the inputs as
NEEDS INPUT rather than assuming.

Do this Monday

1. List every AI model your team relies on for real work, and mark each as frontier-capability or general-purpose, and each vendor by home jurisdiction.
2. For any frontier-capability dependency, run the second prompt to score its government-access exposure and write the verdict into your vendor register.
3. Add a government-imposed-access-conditions section to your AI due-diligence questionnaire, using the first prompt, and make it a standing part of onboarding any new AI vendor.
4. For every high-exposure dependency, name a fallback you can actually reach today, and confirm you could switch to it inside your recovery window.
5. Check the contract for the high-exposure ones: is there any notice or continuity commitment if access is gated or pulled. If not, add it to the next renewal.
6. Record the whole assessment in the vendor file, dated, so the next review starts from evidence rather than memory.

What to record in the vendor file

Keep the entry short and repeatable. For each AI vendor, note:

• The lab's home jurisdiction and the government whose policy could reach the model.
• The capability tier, and whether it is the kind of model that draws government review.
• Whether your organisation would plausibly be inside or outside a vetted access list.
• The current access-continuity terms in the contract, including notice period.
• The named fallback and the last date you confirmed you could reach it.
• The date of this assessment and who signed it off.

Hype check

Do not overread it. Roughly 20 organisations getting early access is a preview arrangement, not a permanent regime, and OpenAI itself expects broad availability soon. One access list is not a policy. Equally, do not underread it. This is the second frontier model in a month whose availability moved on a government decision, and the access-list mechanism is cleaner and more repeatable than an export control. The measured reading is the useful one: a new procurement variable exists, it is not going away, and the response is a line in your due diligence rather than alarm.

The loud version of this story is that a government now picks who gets the smartest model. The version that lands on your desk is smaller and more durable. Government-imposed access conditions are a vendor risk now, like concentration or financial stability, and the teams that handle it best will be the ones who named it, scored it and filed it before the next capable model arrives behind its own gate.