Table of contents
On 21 July Guillermo Rauch, Vercel’s CEO, posted his internal eval results on X, and the argument about open-weight models in security got a lot louder. Kimi K3, the open-weight Chinese release from five days earlier, came out “top-tier at cybersecurity” in his tests. In the same post he added that “Fable refuses everything” and that he couldn’t get it to finish the run at all.
A day later Semgrep published a table with precision and recall.
Two days after that, the UK AISI and the US CAISI published theirs.
None of the three measurements backs up that sentence. Which is a lot more interesting than the ranking itself.
What was claimed, and what was measured
AISI and CAISI ran Kimi K3 through ExploitBench and the TLO cyber range, and published the numbers. It scored 32 percent on ExploitBench against 24 percent for GLM-5.2, the strongest of the open-weight models as of June 2026. That reads fine until you check the next column, where leading US models reached arbitrary code execution on 20 of 41 samples on average. Kimi K3 managed zero of 41.
On the cyber range, where the full attack path runs 32 steps, Kimi averaged step 17. US frontier models averaged 28.5. It cleared the whole range once in ten attempts.
Semgrep tested a different thing, hunting IDOR bugs in real repositories. There Kimi K3 landed 0.684 precision, while Claude Opus 4.8, GPT-5.6 Sol, GPT-5.6 Terra and GLM-5.2 all sit between 0.86 and 0.91. On the largest repo in the set, Kimi delivered roughly 6 percent F1 against roughly 20 percent for everyone else. If that pattern feels familiar, it should, because the same gap between a marketed score and a measured one showed up when automated ATT&CK mapping got benchmarked properly.
To be fair, this is not apples to apples. AISI tested the US models with system-level safeguards switched off. The range itself, quoting the report, “lacks active defenders and defensive tooling”.
Why the open-weight models debate is pointed the wrong way
Most of the argument is about the ceiling. Whether open-weight models have caught up with the frontier or not.
If you defend things for a living, your problem is the floor.
Security comes down to one idea. You push the cost of attacking up until it stops being worth it. A model ranking tells you how high the best attacker on earth can reach. The floor tells you what the cheapest attacker costs, and the cheapest one is plenty to ruin your week.

One line in that same AISI and CAISI report made no headlines at all. “Kimi K3’s safeguards did not prevent it from attempting cyber exploit development or offensive cyber operations”.
Now put that next to the second half of Rauch’s post. The closed model said no. The open one didn’t, and that has nothing to do with how good either of them is at the task.
Willingness cannot be bolted back onto weights somebody already pulled down to their own disk.
What this changes for you
The refusal layer we treat as a safety control is a property of the vendor’s API. It leaves with the rate limit, the provider-side logs, the abuse team and the option to kill an account. Open-weight models running on somebody else’s GPU have none of those four.
There’s a second shift underneath that one. The classic limit on offensive operations is organisational. An operator spends their time on one target and cannot hit twenty with the same quality. Cheap automation lifts that limit.
The DoD capability scale sorts attackers into six tiers, where tier one runs other people’s tools and tier three finds and exploits bugs on its own. Cheap scaffolding drags part of tier one toward tier three, because the pipeline does the work now instead of a person.
Risk is impact times likelihood, and the hype was all about impact. The quiet move happened in the other term.
Where open-weight models lose, in plain terms
It pays to be exact about what a precision score of 0.684 costs you. Bad precision means the model still finds things, then buries them in a pile of wrong findings that somebody has to read through. For your team that’s a bill. For an attacker who skims the output once and needs a single hit, it costs nothing.
And that gap can be closed without touching the model at all.
In June, clearbluejar reproduced a well-publicised find, a seventeen-year-old RCE in FreeBSD originally surfaced by a frontier model. That class of autonomy was already on display in controlled testing months earlier. Except he ran it on gpt-oss-20b on his own hardware, through AISLE’s public 1,700-line Python pipeline. The apparent miss went away on a re-run. The real problem was noise, with the genuine bug buried under false positives.
So he added one stage that checks whether the code is reachable. False positives dropped from 30 to 5 and the CVE was still standing. He said it outright. “The scaffolding does the work, and it’s a lever you can pull on your own model”.
Stanislav Fort at AISLE reproduced the same find for under $100.
The obvious objection, and why it doesn’t hold
Someone will say these are synthetic benchmarks, built on cyber ranges with no defenders and curated repos that flatter the scores. Fair enough, and the AISI report says as much itself.
But the objection cuts the wrong way. If the range flatters open-weight models and closed ones equally, the comparison between them still stands. And the finding that matters here is behavioural rather than numerical, because the model tried, and no range design makes that go away.
Four things to check in your threat model
Skip the leaderboard. If open-weight models are in your threat model at all, work through these four instead.
- Find every control you rely on that lives at the provider. List them out loud. Refusal, rate limit, logging, account termination. Everything on that list is gone the moment the weights run locally.
- Re-check your detection thresholds for cheap reconnaissance. Volume goes up, quality of each attempt goes down. Alert thresholds tuned for a patient human operator will read that as noise.
- Measure the window between a public CVE and your patch. That window used to be protected by how few people could weaponise a bug. Open-weight models plus a public pipeline shortened the queue, and nobody sent you a notice when it happened.
- Price your own triage burden. Poor precision costs a defender real hours and costs an attacker nothing. If you deploy the same class of tooling internally, budget the triage hours the same way you budget the scan.
None of that needs a new product, and none of it is about open-weight models as a technology. It needs the assumption “they probably can’t” taken out of your threat model.
One rule to take away
Stop asking whether your attacker’s model is as good as yours. With open-weight models the honest question is whether anything will stop it.
Labs and their evals police the capability ceiling. The availability floor is set by weights sitting on someone’s disk and 1,700 lines of Python from GitHub. Open-weight models moved that floor while the argument stayed fixed on the ceiling.
Build your threat model on the second number.
Source| https://www.mbi-deepdives.com/open-weights/








