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.

Each is a test that never actually tests anything, and an agent writes that empty version as quickly and as convincingly as the genuine one.

Another concern was that agents are strong at reasoning about a single moment and weak at bugs that span a sequence of individually valid steps, where nothing is wrong except the order.

That describes most of the exploits that have drained crypto protocols this year, where attack methods use technical tools that are individually fine, but mask the theft that lives in the sequence of carrying out several usual steps that lead to a malicious outcome.

Recent attacks fit the pattern. The Edel Finance exploit earlier this month sidestepped an accurate Chainlink price feed through the wrapping layer above it, and in the BONK governance attack, buying tokens, voting and executing a passed proposal were each ordinary transactions.

The Foundation's answer is to let the agent suggest which sequences are worth testing, and to run the tests anyway.