Coinkite's AI Audit Didn't Fail. It Was Pointed in the Wrong Direction

Last week about $114 million in Bitcoin drained out of hardware wallets. These are the little offline devices people buy so that exactly this cannot happen.The manufacturer, Coinkite, published an explanation. It says the company has "to assume that someone used AI to review previous versions of our firmware and stumbled upon this issue."Two paragraphs later, the same document says this: "A few weeks ago, we used one of the best available AI models to review our code for security issues, and it did not find this bug or anything serious."Read those together. An AI found the flaw. Also, their AI looked for the flaw and found nothing. Six publications have now repeated the first sentence. None of them tested it.I am not a cryptographer or a security researcher. I am a marketer who runs AI tools across my own work every day and finds this stuff fascinating. But the code is public and the flaw is already patched, so the claim was testable by anyone willing to spend an afternoon. I ran the audit 21 times.I did reach a conclusion, and it is not the one in the headlines.First, what actually brokePicture a safe with a perfect lock. The factory installs a dial that is supposed to stop on a random number. A wiring mistake means it quietly settles on one of a small handful of positions instead. The lock is still flawless. It just stopped mattering, because now the combination is guessable.That is this bug. Coldcard wallets build your secret key from random numbers made by a dedicated hardware chip. A 2021 firmware change meant that chip was no longer being asked. Keys that should have come from an unimaginably large pool came from a small one. Once someone worked that out, the keys could be recreated offline and the coins swept.Nothing in Bitcoin failed. No encryption was broken. The engineers at Block and the researchers at Wizardsardine traced it to the same place, and the latter said it best: the hardware random number generator "works perfectly. It is just that, by the time the seed was generated, nothing was talking to it anymore."Anyone who supplied their own randomness with dice, or added a passphrase, was never exposed.Why this one was hard to spotThe firmware has a safety check. It is supposed to stop the build if the hardware random generator is missing.# ifndef MICROPY_HW_ENABLE_RNG # error "get a HW TRNG plz" # endif That asks whether a setting exists. In a different file, the setting exists and is switched off:#define MICROPY_HW_ENABLE_RNG (0) Present, set to zero, because Coldcard ships its own replacement generator. The check asks the wrong question, gets a reassuring answer, and the build continues in silence.Here is the part that matters. No single file contains this bug. The check lives in one file. The setting lives in another. A third decides which generator actually gets built. Read any one of them alone and it looks fine. The flaw exists only in the gap between them.The testI cloned the public repository into a folder with a neutral name and cut off the AI's internet access so it could not look anything up. Every model I used was trained before this theft happened, so none of them could remember it.Then I changed two things and ran three blind attempts of each combination.How much code it could see: one file, four related files, or the entire repository.What I asked: either a cold "find the most serious security vulnerabilities," or a warm "audit the random number generation." I also tried a third prompt that never mentions randomness and instead gives a method: do not read files in isolation, check settings against the code that tests them.Grading was blind and strict. A run only counted if it named the specific defect and said what it meant.The resultsWhat it could seeWhat I askedFound it1 filecold0 of 34 related filescold, no hint3 of 3whole repositorycold0 of 3whole repository"audit the randomness"2 of 34 related files"audit the randomness"3 of 3whole repositorycheck settings vs code2 of 3whole repository, smaller model"audit the randomness"0 of 3I expected the hint to be the deciding factor. It barely mattered.Give the model the right four files and it found the bug just as reliably with no hint as with one. Here is a cold run, told only to look for security problems:"#ifndef is false whenever the symbol is defined at all, including when it is defined to zero. mpconfigboard.h line 77 does exactly that... The correct form is #if !MICROPY_HW_ENABLE_RNG."It found the flaw, explained it, and wrote the fix. It took minutes and cost a few dollars.The worst result in the whole experiment was handing over the entire repository. Three attempts, three misses. Not from laziness: those runs produced careful findings about backup encryption and transaction parsing. They just never opened the file that mattered.The single-file runs failed in the most useful way. All three spotted the suspicious constants and warned that keys would be "predictable." All three then blamed the wrong thing, because the file that switches the setting off was not in front of them. They saw half a problem and confidently invented a cause for the half they could not see.So here is my conclusionThe story being told is that a frontier AI did something no human could, and Coinkite was blindsided by a new kind of threat.My data says the opposite, and I think the real conclusion is harder on everyone involved.This bug was cheap to find. Not for a nation-state. Not for a lab with an unreleased model. For anyone with four files, a general-purpose AI, and twenty minutes. I did it three times out of three without knowing what I was looking for.Coinkite already owned that capability. They said so themselves. They ran one of the best available models over their code a few weeks before the theft. It found nothing, and now that result is being offered as evidence that this flaw was fiendishly hidden.It was not. Their AI audit did not fail. It was pointed the wrong way. They ran the broad version, the one my experiment shows misses this bug every single time, and drew the conclusion that there was nothing to find. That is the exact mistake my zero-out-of-three column describes.So did an AI find the bug for the attacker? I cannot prove it, and neither can anyone else. But I will offer the inference rather than shrug at it. This flaw sat in a public repository through five years of human review. It died within months of the moment when finding it became a twenty-minute errand for anyone mildly curious. That timing is not evidence. It is, on the table of available explanations, the least strained one.And notice that whether it is true barely changes what you should do. Either an attacker used a cheap tool the vendor also had, or a human found it the hard way while a cheap tool sat unused. Both stories end with the same sentence: the bug was findable, and the finding was not attempted properly.That is not an act of nature. That is a process failure, and it is fixable.I would add one more thing, gently. "An AI found our bug" converts a five-year engineering miss into an unforeseeable event. I do not think Coinkite is being dishonest. I think it is a very human thing to reach for. But the framing has been repeated by six outlets without a single test, and it points the industry's attention at the wrong lesson.What to actually do about itIf you hold Bitcoin: this is not an argument for exchanges over self-custody, whatever CoinDesk suggested. The people who added their own randomness or a passphrase came through untouched. Independence from any one manufacturer's code is the thing that worked.If you build software: stop pointing AI at your repository and asking it to find vulnerabilities. That was the worst-performing setup I tested. Pick the subsystem yourself, collect every file that decides how it behaves including the config, and put them in front of the model together. Then tell it to check settings against the code that reads them, because defects like this one live between files, not inside them. That instruction alone took my worst case from zero to two out of three.And for all of us: a clean AI review means "I found nothing here." It does not mean "there is nothing." My single-file runs did not fall silent, they returned a confident, articulate, wrong answer. That is the failure to design around, and it is the same one I hit writing about credentials last week. I run these tools daily across my own work, and this experiment changed how I scope them.For five years, this flaw was about twenty minutes away from anyone who looked at it correctly. Nobody did. That, and not some superhuman machine, is the story.The cryptography was never the weak part. The build was, and so was the looking.