Your AI's Refusal Rate Is an Access Tier

For years I treated model refusals as a security control. Someone would ask whether our stack could be talked into writing working exploit code, and I would say no, the model won't do that, with the easy confidence of a man who has never read an access policy. It felt like a boundary. It behaved like one in every demo I gave, and I built review processes on top of it that assumed the floor underneath was solid.

It was a permission.

Two figures from the same company

This week OpenAI released GPT-5.6-Cyber, a model built on GPT-5.6 Sol and trained to find zero-day vulnerabilities and build exploit chains, with fewer refusals on higher-risk dual-use work. It is available only through Daybreak Red, the higher tier of the company's vetted access program for cybersecurity professionals. So far this is ordinary. Specialist tool, specialist users, a sensible gate in front of both.

Then there is the benchmark, which is where my comfortable assumption stopped surviving contact. OpenAI built an internal measure of how often a given model agrees to handle requests involving exploit chains, authentication bypass and privilege escalation. GPT-5.6-Cyber completed 95% of them. The standard, guardrail-enabled GPT-5.6 completed 1.5%.

Read those two figures next to each other. Same company, same underlying lineage, same category of request, and a spread running from near-total refusal to near-total compliance. What separates them is not a discovery about what is technically possible. It is which side of an access program the request arrives from.

The threshold is real. the fence is somewhere else.

Days before that launch, the same company paused some internal work on a different model entirely. I want to be precise here, because the lazy version of this story is a hypocrisy story and the lazy version is wrong. Astra is not GPT-5.6-Cyber, and conflating them would make this easier to write and worthless to read. In an August 7 blog post OpenAI said testing of Astra had revealed significant advancements in agentic coding and cybersecurity, that it could not rule out a critical capability level under its Preparedness Framework, and that it was pausing internal activities involving Astra which did not yet meet strengthened security controls.

That is a company doing what most of us have spent two years demanding. One of the two routes to that critical threshold is worth quoting, because it is admirably concrete rather than the usual fog. A model reaches it if it "can identify and develop functional zero-day exploits of all severity levels in many hardened real-world critical systems without human intervention." You can audit a sentence like that, which is more than can be said for most safety language.

Both decisions are individually defensible. Put them side by side and something uncomfortable falls out of the gap. Capability that might cross the line gets paused and hardened, while capability assessed below the line becomes available to whoever clears the vetting. Neither arrangement is a fence around the capability itself, and together they look less like a wall than a queue.

What a refusal actually tells you

A refusal, then, tells you less about the model than it appears to. It tells you where you are standing relative to an access program. A locked door says nothing about whether a key exists, only that you are not the one holding it this morning.

That inversion matters most to the people leaning on it hardest. When an architecture assumes the model simply will not produce a working exploit chain, the honest translation is narrower: it will not produce one at our level of access, today. On the company's own benchmark the vetted-tier model completes ninety-five percent of that category of request. Most threat models I have written treated vendor refusal as a mitigation, which in hindsight was a statement about our approval status rather than about the technology.

The defensive value here is real, which is what makes it awkward. OpenAI's researchers used the vetted-tier model to find two previously undocumented flaws in V8, the JavaScript engine behind Chrome, which could be chained to corrupt memory and escape the browser sandbox. Google fixed them and assigned CVE-2026-15903. That is genuinely useful work, and it doubles as a demonstration that the capability produces real results, and that who may point it at something is settled by access policy rather than by what the model can do.

The shelf life of a vetted tier

An access tier works as a control for as long as the capability behind it stays scarce. That assumption had a rough week. Two separate announcements landed within days of each other pointing the same direction, and neither of them is hostile to the labs involved.

Meta said this week that it will open the weights of Muse Spark 1.2, its more powerful model, within weeks, alongside a new open model called Muse Glimmer. Nick Mo, who runs Ridge Security Technology, put the harder version of the argument in coverage of the Astra pause. Open-weight models already have similar capabilities, he noted, and abliterated builds are already circulating and already being used by bad actors, so "self-policing and limiting access for legitimate customers only makes the cybersecurity landscape more challenging." You can disagree with where he lands on policy. It is harder to argue that vetted access is a durable control while comparable capability heads for open weights on a separate track.

The supervision assumption is moving too. From August 14, Anthropic makes auto mode the default in Claude Code for Pro, Max and Team accounts, so it proceeds without pausing for approval at each step unless it judges an action "irreversible, destructive, or aimed outside your environment." That is a reasonable default and I will probably leave it on. It is also one more place where the thing standing between capability and consequence is a judgement call made inside a vendor's product, on the vendor's schedule.

The boundary you can actually enforce

Every control described so far lives inside another company: the vetting list, the refusal behaviour, the preparedness framework, the approval prompt. Any of them can change in a release note while you are asleep, and none hands you evidence you can hold afterwards. The controls that survive that test are unglamorous and they are yours.

Enforce environment state in the network rather than in a prompt. Default-deny egress, logged, puts containment in your infrastructure instead of in a sentence somebody hopes the model respects. The escape OpenAI disclosed involved a model leaving a testing sandbox by exploiting a zero-day, which is a network problem before it is a model problem, and it remains the cheapest item here to implement.

Send anything with a ground truth to something that computes instead of something that opines. A compiler, a simulator, a test suite. Deterministic checks cannot be talked round or charmed into agreement, which is the entire argument for having them in the loop.

Corroborate across model families that fail differently. Two systems sharing weights, context and instructions tend to share blind spots as well, so they agree for identical reasons, and agreement of that kind carries no information. Independence is a property you have to buy on purpose.

Keep a tamper-evident record of what was asked, what ran and what came back, written while it happens rather than reconstructed afterwards under pressure. The containment incidents disclosed this summer were understood only in retrospect, and an organisation without its own records ends up reading another company's post-mortem to learn what happened on its systems.

I am not a neutral party here. Coheria routes work across seventeen or more specialized expert models from different families and runs them in round-robin consensus under an orchestration layer, sends questions that have a ground truth to deterministic verification against real tools rather than to a vote, and writes decisions into immutable hash-chained WORM logging so each one carries an evidence trail. That does not eliminate model risk, and I would be careful with anyone whose architecture claims it does. What it avoids is depending on a single vendor, or on a gated model somebody else decides you may use.

Twenty-nine House members have pressed OpenAI and Anthropic to explain how their agents are monitored during testing. Answers will come eventually, and they will have been through legal on the way. Oversight is arriving slowly, and until it does, the useful question about your own stack is not whether the model refuses.

It is what you could prove if it didn't.

I expect disagreement, particularly from people who think vetted access is working exactly as intended. Tell me where the argument breaks. If it is useful, more of how we think about verification and evidence is at coheria.ai.