After Coldcard, AI Found 1,029 Bugs. Censored Models Found None.

TL;DR. The Coldcard failure that drained about 116 million dollars was a build configuration error, not a cryptography bug. What happened next is the part worth your attention. A volunteer red team pointed AI at 390 other repositories and filed 4,962 findings in 27.5 hours, and not one of them came from a public US frontier model. Not because those models are weaker. Because the capable versions sit behind identity gates, and the public tiers reroute or refuse. The frontier labs have largely stopped competing on what their models can do and started competing on what their models will not do. That turns refusal policy into a procurement variable, and it is the same conclusion I reached from the other end when I looked at political framing in public models.

The flaw was one layer below where everyone was looking

A Coldcard is a hardware wallet. Its whole purpose is to generate a seed from a hardware entropy source, keep it off any network, and never let it out. The design target was 128 bits of entropy, which is not brute forceable by anyone, ever.

A firmware release in March 2021 shipped with a build configuration error. Seed generation fell back on a software random number generator instead of the device’s hardware source. Effective key strength collapsed to as little as 40 bits on older devices, which is inside reach of ordinary compute and needs no physical access at all. Exploitation started on 30 July 2026. Inside 25 minutes, roughly 594 BTC moved out of about 500 wallets into a single consolidation address. Galaxy Research has tracked the running total to somewhere near 1,816 BTC, about 116 million dollars, across more than 5,200 addresses.

Here is what I want you to notice before we get to the interesting part. The cryptography was correct. The library was correct. The build was not. An auditor who reviewed the key derivation, the entropy mixing and the signing path would have come back clean, because all of it was clean. The defect lived one layer down, in a compile-time flag nobody was reading as a security control. That is the shape of most expensive failures I get called into: not a wrong algorithm, but a correct algorithm running on a configuration that quietly changed what it was standing on.

Then somebody pointed a model at every other repository

A volunteer group calling itself the Bitcoin Red Team, organized by the developer known as calle with Rob Hamilton of AnchorWatch and funded through OpenSats, decided the same class of bug was probably sitting in a lot of other repositories, and went looking with AI.

• 27.5 hours in: 4,962 findings filed across 390 open source projects. 85 rated critical, 635 rated high.
• 55 hours in: 24 people working in shifts, 425 projects scanned, about 6,700 findings, 1,029 of them high or critical, moving at 7.7 projects per hour.
• Cost: over 40,000 dollars of tokens, running near 10,000 dollars a day at peak. Roughly 100 dollars per repository.

Take those as self-reported and self-classified. Nobody outside the team has graded the severity calls, and a group under time pressure grading its own output is not a neutral instrument. I would trust the order of magnitude and argue about the decimal. The order of magnitude is enough: a first pass over a codebase now costs about what a decent lunch costs, and it runs at eight repositories an hour.

Capability was not the differentiator. Refusal was.

Halfway through the campaign calle posted the observation that got the whole thing attention outside Bitcoin circles: not a single vulnerability had been found by a US frontier model. The work was running on open weights models, Kimi K3 and Qwen 3.8, with GLM 5.2 in the mix. That is what the 10,000 dollars a day was buying.

The obvious reading is that the open models are simply better at this. That is not what happened, and his next message is the one that explains it. One or two people on the team did have access to OpenAI’s cyber tier, and it did find vulnerabilities. Getting that access required identity verification he described as having to KYC your own mother. His summary was blunter than mine: US frontier models produce vulnerabilities that they refuse to fix.

So the capability was there the whole time. It was sitting behind a policy layer. Both major US labs have published the shape of that layer, and it is worth reading as product documentation rather than as an ethics statement.

• Anthropic. On the public Fable 5, queries touching cybersecurity, biology, chemistry or model distillation are rerouted to the older Claude Opus 4.8. The unreduced version, Mythos 5, is the same underlying model with safeguards lifted, distributed to a small set of vetted defenders and critical infrastructure providers through a program called Project Glasswing, in coordination with the US government.
• OpenAI. Trusted Access for Cyber, with GPT-5.5-Cyber as the version that lowers the refusal boundary for security work and adds capabilities like binary reverse engineering. Three access levels, identity and trust based, with phishing resistant authentication required in the top tier since 1 June 2026.

Read those two entries again and notice what is actually being described. In both cases the same weights exist in more than one version, and the versions differ mainly in what they will decline to do. The safety stack is no longer a wrapper around the product. It is the part of the product that varies. Raw capability has largely converged. Refusal policy is where the labs now differentiate, and it is the axis on which they are shipping fastest.

Both policies are defensible. A model that reliably finds exploitable memory corruption in arbitrary source does not become safe because the person holding it has good intentions. I am not arguing the gates should not exist. I am arguing about what they mean operationally, and the tell is in how this story ended. The Red Team eventually did get access to GPT-5.5-Cyber and to Fable 5, reportedly once the campaign had enough visibility to be worth granting. Access followed reputation. It did not follow a purchase order. A volunteer group with a viral thread got in. A platform team at an unglamorous company with the same legitimate need does not have that lever.

You can read that politically if you want, and plenty of people did. I would rather read it as a procurement fact, because that version is actionable: a capability you cannot purchase, cannot forecast, and can lose by policy change is not a supplier. It is a single point of failure with a marketing page.

The same layer, measured from the other side

I came at this from a completely different direction earlier this month and landed in the same place. In local LLMs, political bias, and why llama.cpp still matters, the question was not refusal but framing: what a public model does to a contested question when it does answer. The Neutrality Project’s open benchmark put numbers on it, scoring each model against its own far-left and far-right personas rather than against an external ruler. In their first release, 97 of 108 measured axis positions landed left of center, with an average around minus 0.41 on a scale running from minus 1 to plus 1.

Different symptom, same organ. In one case the policy layer bends the answer. In the other it withholds it. Neither behavior lives in the weights, both are set by a lab, and both can change without anyone telling you. The conclusion I drew there survives intact here, and I would put it more strongly now: the useful property of an open weights model is not that it is smarter. It is that its behavior cannot be rewritten underneath you on a Tuesday.

That is also why the two stories keep converging on the same practical advice. If your judgment work runs entirely through public models, you are sampling from one distribution of worldviews. If your security work runs entirely through public models, you are sampling from one distribution of permissions. In both cases the fix is the same, and it is not ideological: keep a path you own, tested rather than theoretical, so you know what you lose on the day the gate moves.

Three things I would change on your side of the fence

None of this is a Bitcoin story. Substitute your own dependency tree and every line of it holds.

• Write down which of your workflows depend on a model not refusing. Most teams have never made this list, and it is usually shorter and more load bearing than expected: security review, incident forensics, log analysis that touches credentials, anything adjacent to biology or chemistry if you are in those industries. Each entry is a workflow that can stop working after a policy update you did not agree to and were not told about.
• Treat gated model access as a single source dependency. If a workflow depends on a vetted tier, write down what happens when the policy changes, the tier is withdrawn, or your verification lapses. Note also that the gate is identity based rather than price based, so your usual procurement lever, paying more, does not open it.
• Keep an open weights path tested, not theoretical. It will be worse than the frontier tier. It will also still be there, and it will behave the same way next quarter. The point is not to replace your primary model. It is to know the exact size of the gap before you need it, which you cannot learn from a benchmark table.

And the one underneath all of them, which is where I started. The Coldcard defect was invisible to anyone reviewing the layer where the risk was assumed to live. It sat in the build. A review worth paying for crosses the boundary: the code, the configuration that compiles it, the kernel and filesystem under that, the hardware the vendor sold you, and the assumptions in the quote. Any one of those can quietly rewrite what the layer above it is actually doing. Your model supplier’s refusal policy is now one of those layers too.

Sources

• calle, on the absence of US frontier models from the findings, and on the access gate, X, 6 August 2026. Campaign updates from the same thread at 55 hours.
• Bitcoin Magazine, “4,962 Vulnerabilities In 27.5 Hours”. Where the severity split and the token spend come from.
• TRM Labs, “Inside the USD 116 Million Coldcard Hack”, and CoinDesk, “Major bitcoin wallet flaw drains 594 BTC in 25-minute sweep”. The entropy figures and the loss tally.
• Anthropic, “Redeploying Claude Fable 5” and on Fable 5’s cyber safeguards. The rerouting behavior and Project Glasswing.
• OpenAI, “Scaling Trusted Access for Cyber with GPT-5.5 and GPT-5.5-Cyber”. The access tiers and the authentication requirement.
• My earlier piece, “Local LLMs, Political Bias, and Why llama.cpp Still Matters”, for the Neutrality Project figures and the local inference stack behind them.

If you are weighing this up

If you are trying to work out which of your workflows quietly depend on a model that might decline next quarter, or what an owned inference path would actually cost you in capability, an outside read is usually cheaper than finding out during an incident. Book a 15-minute intro call, or take a focused hour on one decision with an Expert Call.