Can AI Actually Find Crypto Bugs? What AI Security Audits Can and Cannot Do

AI systems can find real crypto bugs, but a generated report is not a proven vulnerability until it is reproducible, reachable, security-relevant, and validated by human review. If you have read a project claim its code was "AI audited" and wondered whether that means anything, you are asking the right question.

Can AI actually find crypto bugs?

Yes. Modern AI systems can find real vulnerabilities in cryptocurrency software, including bugs that end up with a public advisory and a patched release. What they cannot do, on their own, is prove that a report is real, that a project is safe, or that no severe bugs remain.

The word "find" is doing more work in that sentence than it looks. An AI agent can generate a plausible written finding in a few seconds. Turning that finding into evidence a maintainer will accept is the harder job, and it is where most of the technical and human effort still sits. This is the same reason a traditional crypto audit is evidence rather than a safety guarantee: the value of a review lives in the process behind it, not in the badge on top. At Blockready, we treat this as a literacy problem. Readers who cannot distinguish a candidate finding from a validated vulnerability are the ones most likely to trust an "AI audit" badge that does not deserve trust.

The rest of this article walks through how that gap works, what current systems do well, where they still fail, and how to read an "AI-audited" claim without getting fooled by the marketing around it.

The Ethereum Foundation case: one validated bug, many confident false alarms

On July 9, 2026, the Ethereum Foundation Protocol Security team published an account of a coordinated AI-agent security workflow run against protocol code, cryptographic code, and smart contracts. The team's chosen title was blunt: the triage is the product.

The workflow surfaced a real remotely triggerable denial-of-service vulnerability in rust-libp2p Gossipsub, a peer-to-peer pubsub library used by Ethereum consensus clients and other applications. The GitHub Security Advisory GHSA-xqmp-fxgv-xvq5 documents the mechanism. A peer sends a crafted Gossipsub PRUNE control message containing an unusually large backoff value. That value is stored and later added to an Instant during heartbeat processing without a safe overflow check. The addition can overflow and panic, terminating the process. The advisory is tracked as CVE-2026-34219, marked High under CVSS v4 with a score of 8.2, and fixed in libp2p-gossipsub 0.49.4.

Two accuracy points matter for anyone summarizing this event. The vulnerability was in a shared networking dependency used by validator-related software, not in Ethereum smart contracts or the Ethereum protocol itself. And the demonstrated impact is availability, not theft of funds or consensus corruption. Media summaries collapsing this into "AI found a bug in Ethereum that could steal validator funds" have gone beyond what the primary sources support.

Alongside the real bug, the Foundation reported that coordinated agents produced many confident but invalid findings. Debug-only panics that cannot occur in production builds. Convincing call chains that were not reachable from an external input. Formal-looking proofs that established the wrong property, or a weaker property, than the one the model claimed. Multi-step exploit sequences in which every individual operation was valid but the sequence never actually reached the forbidden state. The core lesson of the report is that scale of hypothesis generation moves the bottleneck to triage. When ten agents can each produce fifty plausible-looking findings a day, the scarce resource stops being "did anyone notice this suspicious pattern?" and becomes "which of these three hundred write-ups describe something that can really happen against the code we ship?" Validation, not language generation, is where accuracy is decided.

How AI security agents examine crypto code

The phrase "AI security audit" hides a lot of different systems. It might refer to a single language model reading Solidity smart contract code and flagging suspicious lines. It might refer to AI-generated static analysis rules that prioritize known-pattern detectors. It might refer to AI-generated property-based tests that try to violate an invariant. Or it might refer to a multi-agent pipeline running dozens of hypothesis threads in parallel, invoking static analyzers, generating candidate exploits, and executing them inside a sandbox.

A useful mental model separates the work into three roles. AI models generate and reason. Deterministic tools execute and observe. Humans decide what counts. The Ethereum Foundation's pipeline made that explicit. Multiple agents took on separate jobs, including reconnaissance across the code base, hunting for suspicious patterns, filling gaps in earlier scans, testing candidate reachability against a reproducer, deduplicating findings, and passing survivors to a human reviewer. Each of those roles has different reliability characteristics, and combining them is what makes the system usable at all. A single model prompted to "audit this contract" produces a very different artifact from an orchestrated pipeline that has to execute its own candidate exploit against real code before it is allowed to file a report.

This structure matters because it changes what the AI system is actually doing. It is not "auditing." It is producing candidate hypotheses at speed, then relying on tools and people to sort real bugs from confident-looking noise. Everything upstream of that filter changes what comes out the other end. Model choice affects what kinds of patterns get recognized. Scaffold design decides whether the agent can run its own tests or has to guess. Tool access controls whether "reachable" means "I checked" or "it looked reachable in the source." Even the retry budget matters, because a best-of-eight result reads a lot better than a single-shot one but says something different about reliability.

Understanding this workflow is not academic. It is the difference between reading an "AI audit" claim as a security guarantee and reading it as a process description. When AI security work is misrepresented as autonomous certification, the reader has no way to know which parts a person actually validated and which parts a model just wrote well.

The gap between finding a candidate and proving a vulnerability

A "candidate finding" is a plausible written claim that some piece of code might be exploitable. A "validated vulnerability" is a claim that has survived a real test against real code, with real inputs, in a real configuration. The gap between them is the entire point of security review.

The Ethereum Foundation describes a specific evidence bar: a useful candidate should identify the attacker-controlled input, the invariant that is expected to hold, the mechanism by which the invariant breaks, and an observable failure condition. That is the beginning of the validation chain, not the end.

Anthropic's property-based testing research gives a useful sense of the validation cost. In one manually reviewed sample, 56% of AI-generated reports were judged valid, and 32% were judged valid enough to actually report. Ranking the top reports raised those numbers to 86% and 81%. Two things are true at once. The improvement from ranking is real, and the workflow is meaningfully more useful than a raw model dump. And even after ranking, expert review still had to filter what the system produced. That review effort is not a rounding error. It is the audit. Any headline number about AI security capability that quietly excludes the human hours behind it is measuring something other than what a project needs when it decides whether to ship.

What current AI systems do well

Within these limits, the useful work is real. Across primary research and the reviewed benchmarks, current systems consistently help with a bounded set of tasks.

They read large amounts of code and documentation faster than a human can inspect linearly. They explain data flow, access-control patterns, and dependency interactions in plain language. They propose invariants, recognize known vulnerability patterns, and suggest suspicious combinations of patterns. They generate candidate transaction sequences, property-based tests, and proof-of-concept scripts. In controlled sandboxes, they can execute exploits against known-vulnerable contracts. And they cluster duplicates, rank reports, and route the strongest candidates to a reviewer.

Anthropic's SCONE-bench research illustrates what this looks like at the higher end of capability. The company reported that its models generated simulated exploits worth roughly $4.6 million against selected post-cutoff vulnerable contracts, and identified two novel issues during a simulated scan of 2,849 recent contracts. Both figures need context to be read honestly. The exploit "value" is simulated, meaning it is what the exploit would have moved against the sandboxed contract in a laboratory setup, not real stolen funds from a live deployment. The 2,849-contract scan was a filtered set of recent smart contracts on a controlled benchmark, not the full production surface of any live protocol. And the research is a vendor-authored experiment. That is legitimate primary evidence for the specific thing the vendor measured. It is not an independent measure of general audit readiness, and it should not be read as one.

Where AI still falls short

The failure modes are just as important. An AI-generated report does not, by itself, prove any of the following: that the suspected path is externally reachable, that the issue exists in the production build rather than a debug or test configuration, that the observed behavior violates the intended specification rather than a guessed property, or that an exploit is operationally realistic. It does not prove that the issue is novel, that all meaningful attack surfaces were examined, or that no severe bugs remain elsewhere.

Confident language makes this harder to see. The Ethereum Foundation report described findings that were written like professional security advisories but did not survive triage. A weak call chain in source text becomes a "critical" issue in the model's phrasing. A trivially violated property becomes a "formally verified" claim. The reader who trusts the prose ends up trusting the wrong thing. This is the same failure mode we've written about in AI-generated trading claims: confident output is not evidence of a working system. In security work, the risk is higher because the output looks like a report a firm would sign.

False positives and false negatives are different risks

Public discussion focuses on false positives because they are visible. A false positive is a reported vulnerability that is not reachable, reproducible, in scope, or materially different from intended behavior. In a security team, false positives consume expert time, slow real remediation, and can distort risk perception. Reddit threads about AI audit tools tend to converge on the same complaint: some real findings, a lot of noise.

False negatives get less attention because they are absent from the report. A false negative is a real vulnerability the system does not identify. The reader cannot see missing findings, and the tool cannot advertise them. This creates an asymmetric information problem: an "AI audited" claim tells you what the system chose to say, but it cannot show what the system failed to notice.

The practical consequence is that "no issues found" says more about the scope and the tool than about the absence of vulnerabilities. That distinction is exactly the kind of interpretive skill Blockready's DYOR resources aim to build, because a clean-looking report is where most beginner confidence gets overextended.

Why benchmark scores do not equal audit readiness

Benchmarks are useful, but only if you know what they measure. Different benchmarks answer different questions. Detection benchmarks measure whether a system flags a known bug. Patch benchmarks measure whether it produces a working fix. Exploit benchmarks measure whether it can construct a working exploit against a known-vulnerable contract in a sandbox. End-to-end benchmarks try to combine these into a single readiness score.

EVMbench, released in February 2026 by OpenAI, Paradigm, and OtterSec, separates Detect, Patch, and Exploit as distinct tasks. The EVMbench paper reports 120 vulnerabilities across 40 repositories with a top exploit score of 72.2%. The accompanying OpenAI launch article reports 117 vulnerabilities and a top exploit score of 71.0%. Both figures come from the same release. Preserving the discrepancy is more honest than silently blending them.

The independent re-evaluation preprint by Peng, Wu, and Zhou stress-tested EVMbench with more model and scaffold configurations on post-cutoff incidents. It found no agent succeeded end-to-end across all 110 agent-incident pairs and reported detection performance up to 65% on the incident set. The paper is a preprint and results are configuration-specific, but the direction is clear: benchmark rankings shift when the setup shifts.

A common beginner mistake is to treat a single benchmark score as an audit-readiness statement. A model that hits 72% exploit performance on filtered known-vulnerable contracts is not a model that is 72% likely to keep production code safe. It is a model that solved a specific task in a specific setup on a specific date. The evaluation dataset was pre-selected. The vulnerabilities were known and reproducible. Retry budgets, model versions, and tool access are usually configured to show the system at its best. That distinction is easy to lose when marketing copy prints one number and moves on. A fair reading treats benchmark scores as evidence about a specific task under a specific configuration, not as claims about how the system will behave on code no one has seen yet.

What an AI code audit does not cover

Even a perfect smart-contract audit only covers smart-contract code. A crypto project can fail through many other layers: protocol client software, cryptographic circuits, cross-chain bridges, oracles, wallet software, transaction-signing interfaces, frontends, DNS, package dependencies, private-key management, multisig operations, governance and upgrade keys, economic design, cloud infrastructure, and social engineering.

The security-data literature makes this pattern hard to ignore. The Q2 2026 crypto hacks review and the Hacken Q1 2026 audit paradox both document how much crypto loss happens outside the audited contract itself. Signing-key compromises, bridge relayer failures, oracle manipulation, and frontend takeovers keep showing up in the incident logs even when the underlying smart contracts pass their audits. An AI system that reviews Solidity has not reviewed the validator client, the bridge relayer, the multisig operating process, the oracle feeds, or the humans who hold the keys, unless those are explicitly in scope and documented. Assuming otherwise is a common way to overestimate what any "AI audited" claim protects against.

How to evaluate an "AI-audited" claim

If a project or vendor claims AI review, the useful question is not "did AI look at it?" It is "what did AI actually check, and how do you know the findings are real?"

None of this is an argument against AI in security work. It is an argument for reading AI security claims the same way you would read any other security claim: with attention to scope, evidence, and who accepted responsibility for the outcome. When AI is used well inside a scoped human-led pipeline, real bugs get found faster and safer patches ship sooner. When it is used as a marketing prop, "AI audited" ends up meaning something much closer to "we ran a model over the file."

Frequently Asked Questions