The Ethereum Foundation’s Protocol Security team said AI agents can help uncover real vulnerabilities in protocol code, but warned that the hardest part is not generating bug reports. It is proving which ones are real.

The Protocol Security Team has been pointing AI agents at Ethereum’s protocol code. Our core takeaway wasn't about finding bugs, it was about triage.

Here are field notes from the work.https://t.co/HVtc8XcrJK

— Ethereum Foundation (@ethereumfndn) July 9, 2026

In a new post, the team described how it has been running coordinated AI agents against systems Ethereum depends on, including systems software, cryptographic code, and contracts that require high assurance.

The agents found real bugs, including a remotely triggerable panic in libp2p’s gossipsub component, a core part of the peer to peer layer used by Ethereum consensus clients. The issue was fixed and disclosed as CVE 2026-34219.

The team said the result showed that AI agents can be useful in security research, but only when treated as search tools rather than authorities.

An agent can read code, form hypotheses, trace call paths, and draft proof of concept artifacts. But it can also produce reports that look convincing while relying on unreachable code paths, debug only crashes, duplicate issues, or weak formal proofs that do not actually capture the intended property.

“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.”

The Foundation said its process uses many agents in parallel against a single target. The agents coordinate through the repository itself, sharing state in version control rather than relying on a central manager. Their work is divided across recon, hunting, gap filling, and validation.

Recon turns broad attack surfaces into specific testable hypotheses. Hunting follows one hypothesis through the code and attempts to build a reproducer.

Gap filling tracks what has already been accepted or rejected and generates new hypotheses to avoid repeating the same work. Validation independently checks each candidate, removes duplicates, and decides whether it qualifies as a real finding.

For a candidate to count, the team said it must include a reachable target, a clear invariant, a specific failure mechanism, observable proof, a self contained reproducer, and a deduplication key. The goal is to force every report into a concrete claim that can be tested against real code.

The Foundation emphasized one rule above the rest: reproducible or it did not happen. A candidate is not a finding until it includes an artifact that reproduces the failure against the actual code and can be run by someone other than the agent that produced it.

The requirement filters out false positives, from debug only crashes to reproducers built around inputs no attacker could reach. Some formal verification results also pass because the proof is too weak or trivially true, making the report look valid even when the security issue does not hold up.

The team said most candidates are wrong, duplicated, or out of scope, which is part of the workflow. The key is rejecting weak reports quickly while backing real findings with reproducible proof.

Each surviving candidate is checked for real world reachability and attacker cost. A bug any peer can trigger is different from one that requires special access or unrealistic resources.

The Foundation also warned that agents are uneven. They can read specs, draft reproducers, and state invariants, but they struggle with reachability, severity, and bugs that unfold across valid sequences. For those, agents work better as guides for stateful test harnesses than as replacements.

The post frames AI driven audits as a shift in security work, not a replacement for researchers. The bottleneck moves from generating hypotheses to judging them through triage, known issue tracking, artifact validation, and disclosure.

The Foundation said the core practices are not new. Reproducible failures, deterministic environments, clear invariants, careful triage, and human judgment are the same principles that made fuzzing standard practice. The tools have changed, but the bar for trusting results has not.