The Ethereum Foundation's Protocol Security team published a detailed account Thursday of how it deployed coordinated AI agents against the software Ethereum depends on, and what the process revealed about the challenge of separating real vulnerabilities from automated false positives.
The most concrete result is already public. A remotely triggerable panic in libp2p's gossipsub, a core component of the peer-to-peer layer that Ethereum consensus clients run on, was fixed and disclosed as CVE-2026-34219, with credit to the team. But the post is less about that specific bug and more about what it cost in human judgment to trust the results.
"Agents finding bugs wasn't the surprise," the team wrote. "The surprise was how little of the work went into finding them, and how much went into telling the real bugs from the ones that just looked real."
How agents coordinated without a central controller
The Foundation ran many agents in parallel against one target rather than directing a single agent through the codebase. The agents coordinated through the repository itself, with shared state in version control and no central process to hand out work. Each agent writes down a claim where the others can see it, does the work, and commits. The Foundation said it adapted this structure from Anthropic's published account of building a C compiler with a fleet of agents, which uses the same approach.
Roles emerged from the work rather than being fixed in advance. Recon agents turned attack surfaces into concrete, testable hypotheses. A recon output was not "audit the decoder" but a specific field, the property it should hold, the way it might break, and the proof that would settle it. Hunting agents took one hypothesis, traced it through the code, and tried to build a reproducer. Gap-filling agents reviewed what was accepted and what was rejected, wrote the next batch of hypotheses, and tracked coverage so agents did not keep returning to the same ground. Validation agents re-checked each candidate independently and removed duplicates.
Before a candidate counted as a finding, it had to satisfy a defined schema: an attacker-reachable entry point, a stated invariant, a specific mechanism by which that invariant could break, an observable proof such as a panic or a stalled process, and a self-contained artifact that ran against the production code.
"The schema is there for a reason," the team wrote. "It forces a specific, testable claim and a clear definition of done. An agent that has to write down an observable proof can't fall back on 'this looks risky.'"
Why most candidates did not survive triage
The Foundation stated that most candidates either proved wrong or fell outside the scope of the audit. It described this as expected rather than a flaw in the method.
The most common false positive pattern was a panic that only appeared in a debug build. When compiled and run the way the software actually ships, the value wraps around without a crash. A related problem came from reproducers built around internal values no real attacker input could produce, because every reachable path rejects that input before it reaches the vulnerable function. The Foundation also flagged a version of the same issue in formal verification work, where proofs could technically pass without constraining the behavior the team actually cared about.
Every surviving candidate received two independent checks. The first asked whether a real attacker could reach the issue in a normal configuration. The second weighed the cost to an attacker against the cost to the network if the bug fired. The Foundation also ran every candidate against a list of known, fixed, or rejected issues, because without that list, agents kept rediscovering the same closed issues.
Anthropic's property-based-testing agent generated roughly a thousand candidate reports, then used ranking and expert review to reach a top tier that held up approximately 86 percent of the time. Cloudflare, which ran a frontier model through a security-research harness against its own systems, concluded that narrower scope produces better results than broad code scanning.
What agents missed and where the work shifted
The Foundation described AI agents as particularly capable at reading a specification alongside the code it describes and at drafting a reproducer from a rough starting point. The area where agents consistently fell short was bugs that only emerge across a sequence of steps, where each individual step is valid and only the ordering produces a problem. For those bugs, the Foundation said the agent's correct role is to suggest which sequences are worth running through a stateful test harness, not to act as a replacement for that harness.
Researcher Stanislav Fort tested a range of models on real vulnerabilities and described the results as a jagged frontier. A model that recovers a full exploit chain on one codebase can fail basic data-flow analysis on another, which is why the Foundation said every candidate gets checked on its own.
"AI didn't replace the security researcher. It moved the work," the Foundation wrote. "The time that used to go into coming up with and chasing down hypotheses now goes into judging them at scale, including building the oracle, running the triage, keeping the list of known issues, and handling disclosure."
The post cited Nicholas Carlini's argument that the exponential case for AI capability improvement is worth taking seriously even with wide error bars. If the generation side scales faster than the judgment side, the gap between what agents produce and what human researchers can verify would only widen.
AI-assisted security research beyond the Ethereum Foundation
The Ethereum work sits inside a broader shift in how vulnerability researchers use AI. In April, a preview version of Anthropic's Claude Mythos found 271 vulnerabilities in Mozilla's Firefox browser. In May, security researcher Taylor Hornby used Claude Opus 4.8 in an AI-assisted audit that uncovered a critical vulnerability in Zcash's Orchard privacy pool. That flaw had existed for roughly four years and could have allowed an attacker to create counterfeit ZEC without a clear on-chain trace. A network upgrade to restore confidence in Zcash's supply remained in progress at the time of publication.
The Ethereum Foundation published Thursday's post as an organization that had recently cut 20 percent of its workforce as part of a broader restructuring.
"Agents let us cover far more ground than we could by hand. In exchange, they ask for more careful judgment, across a much bigger pile of confident-sounding claims," the Foundation wrote. "That's a trade worth making, as long as you remember that the judgment is the real product."
Kristian Koch
Disclaimer: All materials on this site are for informational purposes only. None of the material should be interpreted as investment advice. Please note that, despite the nature of much of the material created and hosted on this website, HODL FM operates as a media and informational platform, not a provider of financial advisory services. The opinions of authors and other contributors are their own and should not be taken as financial advice. If you require advice, HODL FM strongly recommends contacting a qualified industry professional.
