How AI Finds Zero-Days: Machine-Speed Vulnerability Research

A zero-day used to require a human expert who understood a codebase well enough to notice the one line of logic that didn't hold. That expert might spend weeks staring at a parser or a memory allocator before something clicked. AI systems now do a version of that same work in hours, running in parallel across thousands of code paths, and they don't get tired of reading the same function twenty times. The tools built to find these bugs before criminals do are now good enough that criminals are using them too.

That shift — from AI-assisted research as a defensive curiosity to AI-assisted research as an attacker capability — is the story of the last two years in vulnerability discovery. This post explains what's actually happening under the hood, why the balance of who benefits is changing, and what it means for anyone who ships or defends software.

What "AI finding a zero-day" actually means

A zero-day is a vulnerability the vendor doesn't know about and hasn't patched. "AI finds a zero-day" doesn't mean a model reads source code and has a flash of insight — it means an AI system, usually a large language model wired into a set of tools, runs an investigative loop that used to require a human security researcher at the keyboard.

That loop generally involves the model doing some combination of:

• Reading and summarizing unfamiliar code to build a mental model of what a function is supposed to do
• Forming hypotheses about where that logic might diverge from the assumption ("this bounds check assumes the buffer was already validated upstream — is it?")
• Writing test harnesses, fuzzers, or proof-of-concept inputs to probe those hypotheses
• Running the code, reading the crash or the sanitizer output, and reasoning about whether it's exploitable
• Iterating — refining the hypothesis, writing a better harness, trying a different input — dozens or hundreds of times

None of these steps are individually new. Fuzzing has existed since the 1980s. Static analysis tools have flagged suspicious patterns for decades. What's new is that a language model can now drive that entire loop with minimal human steering, reading unfamiliar code with something closer to human comprehension rather than pattern-matching against known bug signatures.

The difference from traditional fuzzing

Traditional fuzzers are dumb in a specific, useful way: they throw huge volumes of mutated input at a program and wait for it to crash, with no understanding of what the code is trying to do. That works well for shallow bugs reachable from simple inputs, but it struggles with logic bugs that require a specific, structured sequence of operations to trigger — the kind that require actually understanding the program.

An LLM-guided approach adds a layer of reasoning on top of that brute force. The model reads the code, decides which functions look risky, writes a fuzz harness targeted at that function specifically, and — critically — can look at why a fuzzer failed to find anything and adjust its strategy. That's the part a coverage-guided fuzzer alone can't do.

How the pipeline actually works

Most of the credible systems in this space, from Google's Big Sleep project (built on the earlier Project Naptime work) to the entrants in DARPA's AI Cyber Challenge, follow a broadly similar architecture even though the implementation details differ.

1. Target selection. The system is pointed at a codebase, a specific commit diff, or a binary. Diffs are a common starting point because a code change is a concentrated source of new bugs — something worked yesterday and might not today.
2. Comprehension. The model builds a working understanding of the relevant code: what calls what, what invariants are assumed, where untrusted input enters the system, and where it flows.
3. Hypothesis generation. The model proposes specific, falsifiable theories about where a bug might live — an integer overflow in a size calculation, a use-after-free in an error path, a missing authorization check on a secondary route.
4. Tool-assisted verification. The model writes code — test cases, fuzz harnesses, symbolic execution constraints, or simple exploit attempts — and executes it in a sandboxed environment to check the hypothesis.
5. Triage and refinement. Crashes get inspected. Most crashes are not exploitable, so the system (or a human reviewer) has to work out whether a given crash reflects a real, weaponizable vulnerability or a benign fault.
6. Reporting or exploitation. In defensive use, this ends with a report and, ideally, a patch suggestion. In offensive use — whether by a red team or an attacker — it can end with a working exploit.

That last step is the entire ballgame. The same pipeline, pointed at the same target, produces either a bug bounty submission or a weapon, depending only on who's running it and what they do with the output.

Why this needs agentic tooling, not just a bigger model

A model that can only respond to a single prompt with a single answer can't do this work. Vulnerability research is inherently iterative: you try something, it doesn't work, you learn from the failure, you try something else. That requires an agent loop — a model that can call tools (a compiler, a debugger, a fuzzer, a shell), observe the results, and decide what to do next, repeated automatically across many cycles without a human approving each step.

This is also why the recent jump in capability tracks the broader rise of agentic AI systems more than it tracks raw model scale. A more capable base model helps, but the bigger unlock has been giving models reliable tool access, longer effective context for holding a codebase's structure in mind, and enough autonomy to run for hundreds of steps unsupervised.

Why it matters right now

For most of this technology's life, the headline use cases were defensive. Google's Big Sleep team used an AI agent to find a real, previously unknown vulnerability in SQLite before it shipped — a textbook example of AI catching a bug earlier in the pipeline than traditional testing would have. Continuous fuzzing infrastructure like OSS-Fuzz started incorporating LLM-generated harnesses to reach code paths human-written fuzz targets never touched. The framing was consistently: this makes defenders faster than attackers, because defenders can run this at scale across their own codebase before release.

That framing changed when Google documented the first known criminal use of AI to discover and exploit a zero-day, in May 2026. The capability that had been demonstrated in a defensive research context — an AI agent autonomously finding and weaponizing a previously unknown vulnerability — showed up on the other side of the table, used by an actual criminal actor against a live target rather than a lab environment.

The significance isn't that AI-found exploits suddenly became possible; the SQLite discovery and similar defensive research had already proven the mechanics worked. The significance is that the barrier to using this capability offensively — cost, expertise, tooling maturity — dropped low enough for it to happen in the wild, outside a research team with a responsible disclosure process. That's the pattern with most dual-use offensive-security tooling: it gets built and refined for defense, and the same technique eventually gets pointed the other way once it's mature and accessible enough.

For security teams, this collapses the old assumption that AI-driven vulnerability research was mainly a "we should adopt this eventually" conversation. It's now also a "the other side already has it" conversation, and those run on different timelines.

Practical implications for businesses and builders

The immediate question for most organizations isn't "should we build an AI vulnerability research team" — it's "what does this change about our exposure and our defenses starting now."

A few concrete shifts worth planning around:

Some practical takeaways follow directly from this:

• Patch velocity now matters more than patch frequency. If AI-assisted scanning can find bugs in a diff within hours of it becoming public (via a GitHub push, a changelog, or a compiled release), the gap between "vulnerability exists" and "vulnerability is being probed" shrinks. Slow patch cycles are riskier than they used to be.
• Diffs are now a bigger liability surface than they look. A small, seemingly low-risk code change can be exactly the kind of concentrated, comprehensible target these systems are best at analyzing. Treat security review of diffs, not just full codebases, as a priority.
• Legacy code isn't hiding anymore. Old, poorly documented, or unfashionable software used to be safer partly because few humans wanted to research it. That obscurity discount is eroding — an agentic system doesn't get bored reading old C code.
• Defensive adoption is no longer optional to consider. Running the same class of tooling against your own codebase before release — as part of CI, not as an occasional audit — is the most direct way to close the gap between what an attacker's tooling can find and what you already know about.
• Triage capacity becomes the bottleneck. AI-driven scanning, offensive or defensive, produces a lot of candidate findings. Most crash reports are not exploitable. The organizations that benefit most are the ones that can rapidly separate signal from noise — which, again, increasingly means AI-assisted triage on the defensive side too.

None of this requires every company to build a custom agentic security pipeline. It does mean evaluating whether your existing SAST/DAST and fuzzing investment is keeping pace with what's now feasible against you, and whether your patch and disclosure processes assume a slower attacker than the one that now exists.

Limitations and open questions

It's worth being precise about what this technology can and can't reliably do today, because the discourse tends to swing between "AI will end software security as we know it" and "this is overhyped and doesn't really work."

False positive rates remain a real cost. Agentic systems generate a lot of candidate crashes and suspicious patterns. Distinguishing an exploitable memory-safety bug from a benign fault, or a genuine logic flaw from a false hypothesis, still requires either a skilled human reviewer or a second AI system trained specifically for triage — and that second layer has its own error rate.

Coverage is uneven across languages and bug classes. Memory-safety bugs in C/C++ — buffer overflows, use-after-free, integer overflows — are relatively well-suited to this approach because the failure mode (a crash) is a clear, machine-checkable signal. Subtle logic bugs, authorization flaws, and business-logic vulnerabilities in higher-level languages are harder, because there's often no crash to detect — the program runs "successfully" while doing the wrong thing.

Compute cost is nontrivial. Running an agentic loop across a large codebase, with many iterations of hypothesis-and-test, consumes real inference budget. That cost is dropping, but it's not yet free enough that "just run it on everything, constantly" is the default for most organizations.

Verification of the AI's own reasoning is still a weak point. A model can produce a plausible-sounding explanation for why a crash is exploitable that turns out to be wrong, or miss the actual exploitability path while fixating on an irrelevant one. Trusting the system's self-reported confidence without independent verification is a known failure mode.

The arms race framing cuts both ways, and nobody has a clean lead. Defensive teams have a structural advantage — they know their own code, have access to source and build systems, and can run continuously in CI. Attackers have the advantage of only needing to find one exploitable bug rather than closing all of them. AI tooling doesn't change that fundamental asymmetry; it just makes both sides faster at their respective jobs.

What to watch next

A few developments will tell you where this is heading faster than any single research paper:

1. Results from adversarial evaluations like DARPA's AI Cyber Challenge, where AI systems compete to both find and patch vulnerabilities autonomously under controlled conditions — a useful proxy for how mature the automated patch-generation side of the pipeline is, not just the discovery side.
2. Whether "find and patch" becomes a single automated pipeline. Discovery has moved faster than remediation. An agent that can propose a validated, minimal patch alongside a vulnerability report — not just a bug report — closes the loop and removes a major bottleneck.
3. Regulatory and disclosure norms catching up. Coordinated disclosure timelines, CVE processes, and vendor SLAs were built around a human research cadence. Whether those processes adapt to machine-speed discovery, on both the reporting and patching sides, is still an open institutional question.
4. How widely offensive use spreads beyond well-resourced actors. The May 2026 case documented by Google involved a single actor; the more important question is how quickly the same capability becomes accessible to less sophisticated criminal groups, the way commodity exploit kits did after novel techniques were first demonstrated by advanced actors.
5. Whether AI-assisted defense becomes standard in CI, not just at big tech companies. The organizations running Big Sleep-style tooling today are mostly well-resourced. Whether this becomes accessible enough for mid-sized engineering teams to run routinely will shape how uneven the defensive landscape stays.

FAQ

Can AI actually discover vulnerabilities that humans have missed?

Yes — Google's Big Sleep project, for example, used an AI agent to find a previously unknown vulnerability in SQLite that had gone undetected through conventional testing. This isn't hypothetical; it's a documented, reproducible category of result, though it's strongest for memory-safety bugs rather than complex business-logic flaws.

Is AI-driven vulnerability discovery the same thing as fuzzing?

No, though they're related. Traditional fuzzing mutates inputs blindly based on code coverage feedback, with no understanding of what the program does. AI-driven approaches add a reasoning layer that reads the code, forms hypotheses about where bugs are likely to live, and then often uses fuzzing or targeted testing as one tool among several to verify those hypotheses.

How did criminals get access to this capability?

The underlying techniques — agentic tool use, code comprehension, automated hypothesis testing — are largely the same ones published and demonstrated in defensive security research. Google's May 2026 disclosure documented the first known instance of that same class of capability being used by a criminal actor to find and exploit a real zero-day, rather than by a research team following responsible disclosure.

Does this mean traditional security testing is obsolete?

No. AI-driven discovery is best understood as an addition to the existing toolkit — static analysis, code review, penetration testing, coverage-guided fuzzing — not a replacement for it. It's particularly strong at scaling the kind of deep code comprehension that used to require a scarce human specialist, but it still benefits from human oversight for triage and verification.

What can a smaller company realistically do about this?

Prioritize patch velocity for known vulnerabilities, treat code diffs (not just full releases) as a security review surface, and evaluate whether existing fuzzing or static analysis tooling has AI-assisted options that fit within CI. You don't need to build a custom agentic research pipeline to benefit from the same underlying shift toward faster, more automated testing.

Is this only relevant to memory-safety languages like C and C++?

Most of the clearest public results are in memory-safety bug classes because a crash is an unambiguous, machine-verifiable signal that something went wrong. Logic and authorization bugs in higher-level languages are an active area of research but are harder for these systems to verify automatically, since there's often no crash to point to.

Will patching also become AI-driven, not just discovery?

That's the direction most serious efforts, including DARPA's AI Cyber Challenge, are pushing toward — pairing automated discovery with automated, verifiable patch generation. It's less mature than discovery today, largely because a bad automated patch can break functionality in ways that are harder to catch than a bad bug report.

Security teams evaluating where AI-driven testing fits into their own release pipeline can get hands-on help from Woyce Technologies.