coindesk.com
Developers at the Ethereum Foundation recently set AI agents loose on the software Ethereum runs on, hoping to discover bugs in an ongoing effort to keep strengthening the largest blockchain by value locked.
And while bugs were found, meticulous human judgment was still required to differentiate between what was real and what were false positives - with the Protocol Security team publishing field notes on tips the broader ecosystem should follow in their own AI workflows.
Ethereum runs on thousands of nodes, or ordinary computers running the network's software, each keeping a copy of the chain and passing messages to its neighbors.
Validators, the nodes that stake ether and vote on which blocks are valid, sit on top of that layer. They only work if messages reach them.
The bug these engineers found sat in gossipsub. The flaw let a remote system trigger a crash — wherein the node's software hits an impossible calculation, gives up and shuts itself down, taking a validator offline until an operator restarts it.
This was quickly fixed and disclosed as 'CVE-2026-34219' with credit to the team. The broader concern, however, was separating the agents' real bugs from the ones that were confidently masquerading as such.
"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," wrote Nikos Baxevanis, who authored the post.
The difficulty started with what an agent produces. A fuzzer, the standard tool that hurls malformed data at software until something breaks, returned a crash and a record of where it happened, which an engineer can confirm in minutes.
An agent, however, returns a created narrative. It traces how the flaw could be reached, argues why it matters, proposes a severity rating and supplies working code that demonstrates the attack. All of it arrives in fluent prose, reading the same whether the bug is real or invented.
Three kinds of false positive kept recurring, according to the Foundation.
The first was a crash that only occurs in a test build, where the compiler switches on safety checks that the shipped software does not carry, so nothing breaks for real users.
The second was an attack that only works if the dangerous value is planted inside the program by hand, because every route an outsider could take to deliver it rejects the value first. The third came from formal verification, the practice of proving mathematically that code behaves correctly, where a proof passed by demonstrating something trivially true and told the reviewers nothing about the software.