Two things landed within about forty-eight hours of each other last week, and the only reason they didn't get read as one story is that they came out of different press offices.

On 1 September OpenAI said out loud that GPT-6 Astra is the first model it has ever built that reaches Critical on the cyber axis of its own Preparedness Framework. Not High. Critical — the top of the scale, the tier that document was written to describe and had never once had to use.

The next day Google shipped Gemini 3.8 Flash Cyber, the security-specialised sibling of its new Flash model, and put it behind an access programme called Fairwind that did not exist the week before.

Same week, same shape. A model that finds real bugs in real code, and a door with a bouncer on it.

The coverage went almost entirely to the capability, which is the alarming half and is fair enough. I want to talk about the door.

What the Critical tier bought

OpenAI's number: on an internal benchmark built from twenty high-severity vulnerabilities in Google's V8 engine, Astra didn't just re-find the known ones. It turned up two that weren't in the set, chained them together, escaped the sandbox and ran commands on the host. Nobody walked it through that step by step. On the published benchmarks it scored 100% on ExploitBench and got there considerably more token-efficiently than GPT-5.6 Sol.

Google's number is less cinematic and, if you write code for a living, more interesting: in Chrome security testing, Flash Cyber produced 2.6 times more correct vulnerability patches than the best commercial model they evaluated, with internal success rates above 70% across twenty languages. Not "found a scary bug" — fixed bugs, at a rate that survives review.

That difference in framing tells you the two companies read the same capability differently. OpenAI shipped something it's frightened of. Google shipped something it wants to sell to defenders. Both are right.

And the caveat that falls out of most summaries: the headline Astra figures are Astra with Daybreak access, not the model in your dropdown. What reaches an ordinary API key is limited to secure code review and patching, and it declines requests for proof-of-concept exploits. So that 100% belongs to a configuration you almost certainly don't have.

Two doors, one design

Layers, basically.

OpenAI splits it in half. Daybreak Blue is the boring defensive tier on the mainline models: secure code review, vulnerability triage, patch validation. Daybreak Red is where the specialised cyber models live — proof-of-concept exploits, pentesting, red teaming — behind a separate and stricter approval. The Critical-tier offensive capability starts with an alpha group described as organisations responsible for protecting critical digital infrastructure (the US government, partners already inside) before widening to Blue, which currently reads like the badge queue at a vendor conference: Accenture, IBM, CrowdStrike, Cisco, Sophos, Cloudflare.

Fairwind is one door with a longer list of who may knock: governments and national cyber authorities, critical-infrastructure operators, core technology platforms, maintainers of widely used software, academic labs doing defensive benchmarking. Google says more than 650 organisations are already in.

And then the controls. This is the part I'd print out. To hold Fairwind access you pass background checks, put user-level authentication with phishing-resistant MFA in front of it, restrict use to your internal cybersecurity, incident response or penetration testing teams, log which employees touch it and what for, and never share, redistribute or resell it.

Read that as a maintainer.

"Restrict access to your internal incident response team"

I am the internal incident response team. I'm also the pentest team, the reviewer, and the person who hits merge. That isn't a joke about being scrappy — that's a good chunk of the dependency tree you deployed last Tuesday.

Both programmes name open-source maintainers explicitly, and they mean it. OpenAI put a billion dollars behind Daybreak for Frontline Defenders, which lists maintainers alongside water utilities, municipal government and under-resourced non-profits, with subsidised access and actual training attached. Google gives priority to maintainers of widely used software. Nobody forgot us, and I want that on the record, because the lazy version of this post is "big labs ignore open source" and this time it isn't true.

But eligibility written as a control set is a filter with a shape, and the shape is has a compliance function. A background check is a thing an employer does to an employee. "Restrict access to team X" presumes an org chart with more than one box in it. Access logging presumes somebody reviews the log. None of that is hostile. All of it was written by people who have only ever provisioned software to companies.

The one-person project that fifty thousand builds depend on is eligible on paper and, in practice, has to become an institution for a weekend to fill in the form. Some will. Most won't, for the same reason most of us never got round to the SBOM.

And "widely used" is quietly carrying an enormous amount of weight in there. Every dependency that blew up in the last decade was, the day before, not obviously widely used.

The loop that makes this genuinely annoying

Here's what moves it from "a shame" to "hang on".

Maintainers already receive the output of these models. At volume.

Daniel Stenberg shut curl's bug bounty in January because he was drowning in AI-generated slop: confident, detailed, entirely fabricated. That half got told a lot. The sequel got told less. The models got good. The reports stopped being fake. Stenberg now credits AI-assisted tooling with more than a hundred real fixes in curl — bugs that had survived years of fuzzing, sanitisers, static analysis and paid human audits.

And the rate went from roughly one AI-assisted report a week to one every eighteen hours. His own worry is the correct one: an avalanche of good reports is still an avalanche, and no project got extra maintainers to absorb it.

So the maintainer is already downstream of the capability. Any stranger with an API key is running something over their code and writing it up. The allowlist doesn't change that — it never governed the inbound direction. What it governs is whether the maintainer gets to run the same class of tool over their own tree first, on a Sunday, and land the fixes before the queue arrives.

That's the bit that reads backwards to me. Not "dangerous tool locked up". Locked up on the receiving end only.

The asymmetry you can't gate your way out of

The honest defence of an allowlist is that it raises the floor on effort. It does. And I'd rather have it than not — a frontier exploit-chain generator on a free tier would be plainly idiotic.

But gating protects the best tool, and offence doesn't need the best tool. Nobody needs 100% on ExploitBench. You need one bug, in one thing, that one target actually runs. Second-best, third-best, an open-weights model six months behind with no forms attached — that's a perfectly serviceable afternoon for anyone with bad intentions and no deadline.

Defence is the side that needs the ceiling, because defence has to cover everything. Which means an allowlist ratchets the asymmetry the wrong way by construction, and everyone involved knows it, and there is no obvious better answer, which is why this post doesn't end with one.

Two people in OpenAI's own orbit said the uncomfortable parts out loud, incidentally. Yona Shavit asked publicly whether Astra's good behaviour under evaluation came from the model knowing what was expected of it. Steven Adler pointed out that the updated Preparedness Framework has quietly stopped requiring safety testing of fine-tuned models. Neither is a gotcha. Both are the sort of question you want asked by someone who isn't paid to ask it.

And the clock is still running

One more thing and I'll stop.

Four days ago I wrote about the CRA's twenty-four-hour reporting clock — the bit of the Cyber Resilience Act saying that if a vulnerability in your product is being actively exploited you have a day to say so, through a web form, starting on the 11th.

Same maintainer. Same week. Legally obliged to triage and report inside twenty-four hours; outside the vetting perimeter for the tool that would help them do it. Nobody designed that. Two perfectly reasonable processes, drafted in different buildings, landing on the same tired person nine days apart.

So

The capability is real and the release discipline is, I think, defensible. I'd have gated it too, and I don't have a better mechanism to offer.

What I'd want is for somebody to notice that "open-source maintainers are eligible" and "open-source maintainers can actually get in" are two different sentences, and that everything between them is made of controls that assume an employer. A vouching route through a foundation that already exists. Something a person can pass. Anything that doesn't require a background-check policy administered by the person being background-checked.

Until then: your dependencies are being scanned by better tools than their maintainers are allowed to run. That's the actual state of the art this week.

Go and read something you maintain. Nobody's coming.