When Auditing Code Becomes Cheap: AI Has Changed Bitcoin Security

Artificial intelligence did not create the vulnerabilities that shook the Bitcoin ecosystem. What changed was the economics of finding them: reviewing millions of lines of code, testing hypotheses, and repeating the process costs less and less. That advantage is already available to attackers and defenders alike.

August 14, 2026 · Sovereign Geek

In just over two weeks, several well-known names in the Bitcoin ecosystem appeared in connection with security incidents: Coinkite’s COLDCARD, BTCPay Server, Boltz, LNP2PBot, and Trezor. There is, however, an important distinction: not all of them were “hacks,” not all involved stolen funds, and in Trezor’s case the incident occurred at an external logistics provider.

The COLDCARD case was the starting point for this conversation. In the previous post, When the Math Fails: Inside the COLDCARD Entropy Vulnerability, we examined in detail how the problem reduced the effective seed space and why updating the firmware does not repair a seed that has already been generated.

The wave brings together different cases: a seed-generation weakness exploited against users, Lightning credentials exposed by a critical vulnerability, and services that reported attacks and operational losses. Putting all of them under the word attack would make for a more dramatic headline, but a less useful analysis.

What really matters is not assuming that there was a single coordinated campaign. Nor has it been proven that an AI discovered every flaw. The most defensible common thread is another: the marginal cost of searching for vulnerabilities with AI agents is falling rapidly, while Bitcoin’s open-source code provides a public, valuable, and verifiable surface on which to work.

First: What Actually Happened?

Project	What happened	Known impact	Status as of August 14, 2026
Coinkite / COLDCARD	An integration error caused certain versions to use a MicroPython PRNG in the seed-generation path, instead of properly relying on the intended TRNG.	Coinkite estimates around 40 bits of effective entropy in affected Mk2/Mk3 devices and about 72 bits in affected Mk4/Q/Mk5 devices. Updating the firmware does not repair an existing seed.[5][6]	Fixed firmware is available; affected users must generate a new seed and migrate, except for the specific private dice-roll exceptions explained by Coinkite.[5]
BTCPay Server	A vulnerability allowed an unauthenticated remote attacker to obtain LND `.macaroon` files.	BTCPay confirmed exploitation, affected users, and stolen funds. The described risk was concentrated in deployments using LND; BTCPay’s on-chain wallets were not affected by this specific flaw.[7]	Fixed in BTCPay Server 2.4.2; the project also asked users to update LND, review activity, and regenerate credentials.[7][8]
Boltz	The project stated that several AI-assisted attacks succeeded and caused operational losses.	According to Boltz, user funds were not at risk thanks to its non-custodial architecture.[16]	Swaps were suspended while vulnerabilities were sought and fixed; public technical details remained insufficient for full independent validation.[15][16]
LNP2PBot	Its operator reported that sustained attacks escalated and caused losses absorbed by the team.	The team promised to make users whole and settle pending payments; it did not publish enough technical analysis to identify the exact vector.[17][18]	The service shut down. This case should not be confused with LNbits: no new LNbits advisory appeared within the same window.
Trezor / ShipMonk	ShipMonk, Trezor’s shipping provider, reported unauthorized access to systems containing customer order data.	11,742 customers had full exposure—name, email, phone number, and shipping address—and 1,947 had partial exposure—name, city, and email: approximately 13,689 people.[26]	Trezor’s systems and devices were not compromised. The immediate risk is targeted phishing by email, phone, or even physical mail.[25][26]

The Trezor case belongs to a different category. It was not a hardware-wallet vulnerability or a seed extraction: it was a breach in the data supply chain. BleepingComputer reported that ShipMonk attributed the access to exploitation of a critical SQL injection vulnerability in Metabase; Trezor, meanwhile, said the investigation remained ongoing.[25][26]

The technical distinction does not reduce the human risk. With a name, email address, phone number, and home address, an attacker can build far more convincing messages, impersonate Trezor, an exchange, or a bank, and pressure the victim into revealing a wallet backup. Trezor was explicit: its devices remain secure, and no user should ever type or share a wallet backup online.[26]

AI Attribution: Plausible Does Not Mean Proven

In the COLDCARD incident, Coinkite wrote that, because the code was public, it had to assume someone had used AI to review older firmware versions. It also acknowledged that its own review with one of the best models available had not found the error.[6]

Jameson Lopp was even more explicit on Casa’s blog: researchers “now believe” the vulnerability was most likely found by a frontier model. That wording matters. “Presumably” or “most likely” does not mean “confirmed.”[1]

The hypothesis is credible because the attack fits a new capability: an agent can traverse public repositories, follow execution paths, compare assumptions against the implementation, and look for repeatable patterns without tiring. But we do not have public forensic attribution proving who used which model, with what instructions, and at what time.

The Casa article gets the operational conclusion right even though the attribution remains open: teams must act as though machines are already reading their code, because the capability exists and will continue to become cheaper.[1]

This Is Not an Open-Source Problem; It Is a Race for Speed

It would be easy to draw the wrong conclusion: “if public code can be analyzed by attackers, then it should be closed.” That confuses visibility with insecurity.

Open-source code allows independent researchers to audit, reproduce, and fix flaws. It also reduces dependence on promises that are impossible to verify. The problem is not that the attacker can read the code; the problem arises when the attacker can do so continuously while the defender audits only once a year.

For years, an in-depth audit required scarce specialists, weeks of work, and budgets that many community projects could not afford. Today, an AI agent can automate the initial sweep, run tools, produce test cases, and repeat the analysis after every change. Stanford’s AI Index found that the inference cost of a system with performance equivalent to GPT‑3.5 fell by more than 280 times between November 2022 and October 2024.[11]

That does not mean a complete audit is 280 times cheaper. Security analysis also consumes infrastructure, harness design, test execution, and human time to separate real findings from false positives. But it does mean that its economic raw material—inference—has become radically more accessible.

There are more direct signals. In a penetration study on a real university network of roughly 8,000 hosts, the ARTEMIS agent found nine valid vulnerabilities, outperformed nine of ten human participants, and some of its variants cost $18 per hour, compared with $60 per hour for professional pentesters. The authors also observed more false positives and difficulties with graphical interfaces: cheap does not mean infallible.[21]

In Firefox, Anthropic and Mozilla offered an especially clear defensive demonstration. Claude Opus 4.6 found 22 vulnerabilities in two weeks; Mozilla classified 14 as high severity and published fixes. Anthropic spent approximately $4,000 on hundreds of subsequent exploitation attempts and obtained only two rudimentary exploits, concluding that finding flaws was roughly an order of magnitude cheaper than turning them into exploits.[12][13]

That difference opens a window for defenders. But it is a window, not a permanent guarantee.

Bitcoin Red Team: Trying to Get There Before the Attacker

In response to the COLDCARD situation, a volunteer initiative known as Bitcoin Red Team began reviewing ecosystem repositories at scale. Its public leaders, Calle and Rob Hamilton, described a process that combines AI agents with human specialists: selecting repositories, launching analyses, reproducing serious findings in local environments, and communicating them privately to maintainers.[3]

The initial figures were striking: 390 projects analyzed, 4,962 initial findings, 85 classified as critical, and 635 as high.[3][22] But those numbers must be interpreted correctly: a finding classified by a tool is not the same as a confirmed vulnerability. Validation, reproduction, and coordinated disclosure remain human work.

Nor does the team automatically “patch” everything it finds. It normally provides evidence and proofs of concept; maintainers evaluate the report, fix their project, and publish an update. That is the responsible way to reduce the time between discovery and repair without handing out an exploitation guide before a patch exists.

OpenSats turned the effort into more stable infrastructure through a Red Team Fund: a fund to pay researchers who find and disclose flaws and to reimburse the monthly cost of model tokens.[24] This matters because the bottleneck will not be computational alone. People who understand Bitcoin, reproduce results, coordinate disclosures, and support small maintainers will also be needed.

The first campaign shows that the cost of mass screening has fallen. It does not show that 390 repositories received the equivalent of 390 professional audits. Confusing the two would be precisely the kind of overconfidence that good security practice should avoid.

What Casa Is Doing—and What Other Companies Can Copy

Casa’s article offers a more mature model than “connect a chatbot to the repository.” Its recurring harness uses three phases: discover, verify, and report. Each potential flaw must cite the exact file and lines, include the relevant code, and produce formats that can be integrated into the engineering workflow. Verified findings generate tickets, and critical ones alert on-call personnel.[1]

Casa combines this layer with human reviews, branch protection, signed commits, regression tests, end-to-end tests, exploratory QA, external pentests, and audits focused on major changes. It also uses multi-provider multisig so that compromising a single key or device is not enough to move funds.[1]

The broader lesson is not “buy the most expensive model.” It is to build a system in which AI may propose, but must prove.

A Practical Plan for a Company

Inventory what actually protects value. Repositories, dependencies, secrets, CI/CD pipelines, images, firmware, APIs, keys, and administrative paths. Without an inventory, there is no defensible scope.
Define security invariants. Examples: “no Lightning credential may be served over HTTP,” “a key never leaves the device,” “a cryptographic fallback must fail closed.” These rules provide context for humans, tests, and agents.
Run AI analysis in an isolated environment. Never send private repositories, secrets, databases, or credentials to a provider without reviewing contracts, retention, residency, and data use. Prefer sandboxes without production access and disposable credentials.
Require verifiers. Every finding should include a minimal reproducible case, concrete evidence, and, when possible, a test that fails before the patch and passes afterward. Mozilla highlighted minimal cases and reproducible tests as precisely the difference between useful reports and noise.[12][13]
Separate discovery, exploitation, and remediation. Do not automatically give an agent permission to deploy, rotate keys, or run exploits outside the lab. Finding a flaw does not authorize a production action.
Keep human review mandatory. No AI-generated patch should bypass code review, regression testing, change controls, or approval by the system owner.
Analyze every change, not just every anniversary. Integrate review into pull requests, run weekly sweeps, and trigger extraordinary reviews when a relevant industry flaw appears.
Design so that one layer can fail. Segmentation, least privilege, withdrawal limits, separation of duties, multiple keys and providers, monitoring, and recovery procedures reduce the damage when a vulnerability inevitably slips through.
Prepare disclosure and incident response before the incident. Publish a SECURITY.md, a contact channel, safe harbor rules, designated triage owners, and a procedure for notifying users without prematurely revealing the exploit.
Measure useful outcomes. Time to detection, time to validation, time to patch, false-positive rate, regressions prevented, and vulnerabilities reproduced. “Tokens consumed” or “findings generated” are not security metrics by themselves.

What Can an Ordinary Person Do Without Becoming a Specialist?

Continuous education will be important, but it does not have to become permanent vigilance or a diet of fear. A simple routine of 20 minutes per week may be enough:

Make a short list of what you use. Wallet, hardware wallet, node, Lightning server, exchange, and connected applications. If a product is not in your inventory, its alerts should not take up your attention.
Follow official sources first. Enable security notices, RSS, email, and release notifications for each project. On GitHub, you can watch only Releases and Security alerts to avoid the noise of every commit.
Add one curated source. The Bitcoin Optech newsletter summarizes technical developments and maintains a searchable archive.[14] For specific products, also keep the manufacturer’s official blog or channel.
Use AI as a filter, not as an authority. Ask it to summarize which products are affected, which versions fix the problem, and what action the source recommends. Then open the original advisory. A screenshot or viral post is no substitute for the primary statement.
Verify three facts before acting: the exact product and model, the installed version, and the officially recommended action. Scammers exploit real incidents to distribute fake “updates” or ask for seeds.
Never enter your seed phrase, passphrase, private key, macaroon, API key, or backup file into a chatbot. AI can help you understand public instructions; it does not need your secrets to do so.
Download updates from the official website and verify signatures when the project provides them. Do not use links sent through direct messages.
Keep little value in hot systems. A mobile wallet, Lightning server, or experimental service should contain only the amount needed for its purpose.
For significant savings, eliminate the single point of failure. Multisig using devices from different vendors can prevent a flaw in a single implementation from being enough to steal the funds, provided that the setup and recovery process are well understood.[1]
Practice recovery. A sophisticated architecture that no one knows how to restore can be more dangerous than a simple, well-tested one.

One particularly useful rule during an emergency is this:

Do not update out of panic; update from the primary source. Never enter your seed to “check” whether it is affected.

The Deeper Shift: Security Stops Being an Event

Casa’s conclusion captures the transition well: an audit is a photograph, not a film.[1] AI makes it economically feasible to review more code, more frequently, and from more angles. At the same time, it allows an attacker to do exactly the same thing.

The result will not be a world without vulnerabilities. It will be a world in which the time between introducing a flaw and discovering it is compressed. Companies that turn adversarial review into a routine, verify model output, and design their systems to tolerate failures will have an advantage. Those that confuse an annual audit with a permanent state of security will remain exposed.

For individuals, the answer is not to learn offensive exploitation or chase every rumor. It is to keep a small inventory, follow official sources, understand the design of the tools that safeguard their money, and practice recovery.

AI is making both attack and defense cheaper. The advantage will not automatically belong to whoever has the most powerful model, but to whoever turns its results into learning, patches, and resilience faster.