Orchestrating AI Agents for Vulnerability Research

This research examines what coordinated AI assistance contributes to vulnerability analysis, and where the results still depend on human judgment.

The Old Model Is Broken

Traditional vulnerability research follows a well-worn pattern: a human expert selects a target, studies its source code, writes a fuzzing harness, generates seed inputs, launches a fuzzer, then — and this is where most of the time goes — manually triages every crash.

Each crash requires loading the input in a debugger, walking the heap, reading disassembly, classifying the root cause, deduplicating against known bugs, and determining exploitability. A skilled researcher might spend weeks on a single library before producing actionable results.

The actual fuzzing — the automated part — typically accounts for less than 20% of the total effort. The other 80% is human analysis.

This creates a structural problem: the attack surface of modern software is growing exponentially, but the pool of researchers capable of doing this work is not. There are perhaps a few thousand people worldwide who can competently take a crash from a fuzzer and determine whether it’s exploitable. Meanwhile, every connected device runs dozens of C and C++ libraries with complex binary format parsers — each one a potential entry point.

The math doesn’t work. It never has.

Working with AI research assistants

The campaign used AI assistants to support research and documentation. The central evaluation question was whether their work could be checked and trusted. Speed alone was not sufficient: useful results needed reproducible evidence and human review.

The experience exposed gaps between producing a plausible research artifact and establishing that it was correct. Those gaps shaped the lessons below.

Results

What We Found

Across nine open-source libraries — including libarchive, FreeType, DjVuLibre, libtiff, libexif, LibRaw, and Poppler — the system identified three previously unknown security findings in a widely-deployed library present on virtually every operating system:

What We Didn’t Find

Equally telling: the system spent 3.6 billion executions on FreeType 2.13.3 with zero crashes. It confirmed all 60+ DjVuLibre crashes mapped to a single known CVE. It retired ImageMagick, hostapd, and several other targets without identifying new findings during the campaign. A campaign without new findings does not establish that the software is free of vulnerabilities.

Knowing when to stop is as valuable as knowing what to chase. The agents make retirement decisions based on execution counts, coverage plateaus, and crash deduplication — not human impatience or sunk-cost bias.

What Went Wrong

No system is perfect, and ours has failure modes worth acknowledging:

• Harness quality varies. One agent confused build flags between libraries, producing a harness that compiled but exercised the wrong code paths. Automated testing caught it, but hours of fuzzing were wasted.
• False confidence in triage. The system classified a crash as “known bug” based on superficial stack trace similarity. A human reviewer later identified it as distinct. We’ve since added deeper deduplication.
• Exploit development still requires human judgment. The agents produced excellent research artifacts — heap maps, allocation timelines, grooming strategies — but translating those into a working exploit required human expertise where agents would confidently propose approaches that don’t survive contact with reality.

A system that claims perfection invites distrust. A system that knows its failure modes can be relied upon within its boundaries.

The last mile: human validation

AI-generated analysis helped organize the research, but final validation required human expertise. A convincing explanation did not establish that a finding was correct, distinct, or consequential. Human review remained necessary for conclusions and disclosure decisions.

A Single Desktop Workstation

A persistent myth in vulnerability research is that serious fuzzing requires cloud compute clusters and dedicated fuzzing farms. When AI agents handle the analysis pipeline, the equation inverts.

Peak throughput: ~75,000–82,000 executions per second across all campaigns. Modest by cloud standards — but our confirmed findings came at near-zero marginal hardware cost. The primary expense shifts from compute infrastructure to AI model API usage, which remains modest relative to traditional staffing.

Smart targeting beats brute-force compute. Google’s OSS-Fuzz project has enormous compute resources and generic harnesses. Our agents found bugs in libraries that OSS-Fuzz has been testing for years — because domain-specific harnesses exercise code paths that generic approaches miss.

Quality of harness matters more than quantity of cores.

What Comes Next

We’re in the early days. The current system requires human oversight for strategic decisions, disclosure coordination, and final exploit validation. But the trajectory is clear:

Near-term (2026–2027): Fully autonomous crash-to-CVE pipelines for common vulnerability classes — with human approval as a gate, not a bottleneck.

Medium-term (2027–2029): Proactive variant analysis. When a vulnerability is found, agents automatically evaluate whether similar patterns exist in related codebases — in hours rather than the months it takes the community to discover variants organically.

Longer-term: Continuous, autonomous security assurance as a service. Organizations subscribe to a pipeline that monitors dependencies, finds vulnerabilities before attackers do, and delivers fixes — not reports.