Artificial intelligence can generate security findings faster than most teams can review them. That is not automatically an advantage.
For organizations responsible for crypto infrastructure, the more important question is whether an AI-generated finding survives scrutiny. Can a human reproduce it? Does it affect deployed code? Is the proposed attack path economically or technically realistic? Which team owns the response?
Those questions sit at the center of the Ethereum Foundation Protocol Security team’s work running coordinated AI agents against Ethereum’s protocol code. Its central observation is unusually practical: “The triage is the product.”
That framing deserves attention beyond Ethereum. It points toward a more credible benchmark for AI-assisted security across blockchains, wallets, exchanges and payment infrastructure. The useful output is not a large pile of machine-generated vulnerabilities. It is a smaller set of findings that have been deduplicated, reproduced, prioritized and delivered to the people capable of fixing them.
In an industry where software controls transferable assets, the distinction is consequential.
More findings can create more work, not more security
Generative models are good at producing plausible explanations. Security work demands something harder: proving that a suspected weakness is real under defined conditions.
An AI agent can identify code that looks dangerous, infer a possible execution path and write a convincing report. But the resulting alert may rest on an impossible state, misunderstand a safeguard elsewhere in the system or duplicate an issue already raised by another agent.
Coordinating multiple agents compounds the problem. Parallel analysis can expand coverage, but it can also generate overlapping reports and incompatible interpretations of the same code. Without a disciplined review layer, higher output becomes a queue-management problem.
That is why the Ethereum Foundation’s emphasis on triage matters. It shifts the measure of success away from raw production—how many issues an agent reports—and toward operational usefulness.
A serious AI security workflow needs to answer at least four questions:
1. Is the finding reproducible? 2. Is it distinct from other findings? 3. How severe is it in the actual system? 4. Can the responsible team act on it?
Until those questions are resolved, an AI-generated vulnerability is closer to a lead than a result.
Crypto needs a benchmark tied to validated outcomes
Many common AI benchmarks are poorly aligned with protocol security.
A model may perform well when asked to detect a known bug in a curated code sample. Production infrastructure is less accommodating. The relevant weakness may depend on interactions among modules, client implementations, network assumptions and economic incentives. Documentation may be incomplete. The code may have changed since the test was designed.
Crypto systems add another difficulty: an apparent software bug is not always an exploitable financial vulnerability, while a financially dangerous configuration may not resemble a conventional coding flaw.
The reported $9.3 million drain from a More Markets lending reserve illustrates the importance of analyzing systems rather than isolated code. According to Blockaid’s account reported by Cointelegraph, an attacker used an Ankr liquid-staking token and an efficiency mode to overborrow and drain WFLOW from the reserve.
That incident should not be treated as evidence that an AI system would have detected the attack. The supplied reporting does not establish that. It does, however, show the kind of cross-component reasoning security reviews may need to perform: examining an asset, a lending configuration and a borrowing mechanism together.
An AI benchmark built around isolated snippets would reveal little about that capability.
A more useful evaluation would measure the complete path from initial signal to validated security result. Relevant metrics could include:
- the proportion of findings successfully reproduced; - the false-positive rate after expert review; - duplicate findings generated by separate agents; - time required for human triage; - coverage across interacting components; - severity agreement between the model and reviewers; - and the share of validated findings that reach an accountable engineering team.
These metrics are less impressive in a product demonstration than a claim that an agent found thousands of bugs. They are also much closer to what infrastructure operators need.
Human review remains part of the system
The Ethereum Foundation’s work does not support the simplistic conclusion that AI is replacing protocol security researchers. Its emphasis on organization and scrutiny points in the other direction.
AI agents can expand the searchable surface. They can inspect multiple areas of a codebase, propose hypotheses and prepare material for review. Humans still have to determine which hypotheses deserve attention and whether the analysis reflects how the protocol actually operates.
This division of labor has design implications.
First, AI findings need provenance. Reviewers should be able to see which code version, assumptions, prompts, tools and execution traces produced a report. Without that information, reproducing the result becomes harder and model updates can quietly change behavior.
Second, agents should produce evidence, not just prose. A useful report might include a minimal test case, the affected execution path and clearly stated preconditions. Fluency is not a substitute for a working demonstration.
Third, the review queue needs explicit ownership. A valid report that remains unassigned does not improve security. Teams need rules for routing findings to client developers, protocol maintainers or other responsible operators.
Finally, rejected findings should become evaluation data. If reviewers repeatedly dismiss alerts because an agent misunderstands the same protocol rule, that pattern should inform future tests and system changes. Triage is not merely cleanup after generation; it is the feedback mechanism that makes the system more useful.
The data layer may become the defensible product
As base models improve, generating a preliminary code review will become easier and cheaper. The more durable advantage may sit in the surrounding infrastructure.
A well-run security operation can accumulate structured information about which findings were valid, why others failed, how long verification took and what remediation followed. That dataset is valuable because it reflects real engineering judgment rather than synthetic answers or simplified benchmark tasks.
For crypto teams evaluating AI security products, this changes the diligence process. Model branding matters less than workflow evidence.
Buyers should ask how findings are validated, how duplicates are handled and whether the product can reproduce a suspected issue. They should also ask what happens when the model is uncertain, how sensitive code is protected and whether generated reports can enter existing vulnerability-management systems.
A tool that produces fewer findings may be more valuable if those findings reach engineers with adequate evidence. Conversely, a high-volume system can impose a hidden cost by consuming scarce reviewer time.
That cost is especially important for smaller protocols and crypto businesses. They rarely have unlimited security staffing. An alert stream that requires specialists to reject hundreds of plausible but invalid reports can reduce attention available for audits, incident response and operational controls.
Payments and custody raise the stakes
The lesson extends beyond protocol clients.
Wallet providers, stablecoin payment companies, exchanges and custody platforms increasingly depend on complex software stacks. An apparent weakness may span identity systems, signing policies, smart contracts and offchain transaction processing. AI agents could help inspect those boundaries, but only if their output is evaluated against realistic workflows.
For example, identifying suspicious signing code is not enough to establish that funds can be moved. A reviewer would need to understand the authorization model, the deployed configuration and the controls surrounding key use. Similar constraints apply to payment systems, where a technical anomaly may or may not translate into an incorrect settlement or unauthorized transfer.
The practical product shift, then, is not autonomous security. It is assisted investigation with a rigorous evidence pipeline.
That may sound less transformative than replacing a security team with agents. It is also a more plausible route into production.
The grounded takeaway
Ethereum’s experiment offers a useful standard for the wider market: judge AI security systems by what remains after review.
Raw issue counts, polished vulnerability descriptions and model-generated severity labels are easy to display. Reproducible findings with known assumptions, clear ownership and an auditable path to remediation are harder.
Crypto infrastructure teams should therefore treat triage capacity as part of any AI security deployment, not an administrative task added afterward. If an organization cannot verify and route the findings an agent produces, faster generation will mainly create a larger backlog.
The near-term value of AI in crypto security is likely to come from extending expert attention—not eliminating the need for it.