The triage is the product: running AI agents against Ethereum's protocol code | Ethereum Foundation Blog<br>EF Blog

Search

Skip to content

The triage is the product: running AI agents against Ethereum's protocol code<br>Posted by Nikos Baxevanis on July 9, 2026<br>Research & Development

Notes from the Ethereum Foundation's Protocol Security team on running coordinated AI agents against real protocol code, including how we organize the work, what holds up under scrutiny, and what client teams and security researchers can take from it. This post stands on its own; later posts will go deeper on individual clients.

What we've been running, and what surprised us

On the Ethereum Foundation's Protocol Security team, we've been running coordinated AI agents against the kinds of systems the network depends on, like systems software, cryptographic code, and contracts that have to be right. The agents found real bugs. One is now public: a remotely-triggerable panic in libp2p's gossipsub, a core part of the peer-to-peer layer Ethereum consensus clients run on, fixed and disclosed as CVE-2026-34219 with credit to the team.

Agents finding bugs wasn't the surprise. 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.

This post is for client teams and security researchers who want to do the same thing. It covers how we organize the agents, the bar a candidate has to clear before it counts as a finding, and the habits that keep the results trustworthy.

Teams elsewhere are converging on the same recipe. Anthropic's Frontier Red Team built an agent that writes property-based tests and found real bugs across the Python ecosystem. Cloudflare ran a frontier model through a security-research harness against their own systems. Everyone lands on the same loop: point a capable model at a codebase, let it search, and triage what comes back. So the real question is how to do this without drowning in confident-sounding noise.

One caveat up front: tooling for agent-driven audits moves fast, and any specific setup is out of date in a few weeks. So this post is deliberately about the methods, which are persistent, rather than the tooling. Disclosure is its own topic and will probably be its own post.

An agent is a search tool, not an oracle

An agent pointed at a codebase is a search tool, a lot like a fuzzer. The difference is what comes back. A fuzzer hands you a crash and a stack trace. An agent hands you a lot more, including a write-up (call chain, impact claim, suggested severity) and the artifacts to back it, like a proof-of-concept you can run against the real code.

All of that makes the result easy to read and easy to trust, the running proof-of-concept most of all. So don't count how many candidates an agent produces. Count how many turn out to be real.

How the work is organized

We run many agents in parallel against one target. They coordinate through the repository itself, with shared state in version control and no central process handing out work. An agent writes down a claim where the others can see it, does the work, and commits.

We got this approach from Anthropic's writeup on building a C compiler with a fleet of agents, which coordinates the same way. There's no central coordinator to build or maintain, and less that can go wrong.

The roles are generated by the work that's discovered:

Recon turns an attack surface into concrete, testable hypotheses. Not "audit the decoder" but "this field is trusted past this point; here's the property it should keep, the way it might break, and the proof that would settle it."<br>Hunting takes one hypothesis, traces the code path, and tries to build a reproducer.<br>Gap-filling looks at what was accepted and what was rejected, writes the next batch of hypotheses, and tracks coverage so the agents don't keep going over the same ground.<br>Validation re-checks each candidate independently, removes duplicates, and decides.

We didn't invent this pipeline. Cloudflare describes the same stages, recon, parallel hunting, independent validation, deduplication, reporting, and their writeup helped shape ours.

Here's what a candidate looks like before it counts as a finding:

target: component and entry point an attacker can actually reach<br>invariant: the property that must hold<br>mechanism: the specific way it might be made to break<br>success: observable proof: a panic, a stall, an accepted-invalid input<br>reproducer: a self-contained artifact that runs against the real code<br>dedup: a key, so two agents don't chase the same thing

The schema is there for a reason. 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."

Reproducible or it didn't happen

One rule matters more than any other. A candidate isn't a finding until there's a self-contained artifact that reproduces the failure against the real code,...