Big Sleep — An AI Agent Finds an Unknown Flaw in SQLite

Big Sleep is an AI agent built jointly by Google's Project Zero and Google DeepMind to hunt for unknown vulnerabilities in software. On 1 November 2024 the team announced its first real-world find: an exploitable stack buffer underflow in SQLite, the embedded database used by countless applications. The flaw was reported to the SQLite developers in early October 2024, fixed the same day, and never appeared in an official release, so, as the team put it, SQLite users were not affected.

The team called the find, in its own words, what it believed was "the first public example of an AI agent" discovering a previously unknown, exploitable memory-safety issue in widely used real-world software. That claim is hedged — "we believe", and "public" — and it should be read as Google's own assessment, not an independently certified record.

What was found

The bug sat in seriesBestIndex, a function of SQLite's generate_series extension (ext/misc/series.c). SQLite uses the value −1 as a special marker for constraints on the ROWID column, and that function did not handle the marker. A crafted query could therefore make it write outside the bounds of an array on the stack — the "underflow" in the name, because the write landed below the start of the buffer.

Project Zero's write-up gives the commit identifiers rather than a release number, which is itself the point: the vulnerable code existed only in the development branch. The team described the bug as likely exploitable, but also noted that it surfaced in a debug build with assertions enabled; in a release build the assertion is absent and the outcome depends on the compiler and optimisation level.

Why fuzzers had missed it

Fuzzing — firing enormous numbers of semi-random inputs at a program — is a standard technique for finding memory-safety bugs. The Big Sleep team checked why it had not caught this one. Google's OSS-Fuzz harness for SQLite was built without the generate_series extension, and another harness contained an older, unaffected version of the function. When the team ran AFL against the SQLite command-line target for 150 CPU-hours, it did not find the bug either.

That is a narrow result, and the authors framed it narrowly. They called the findings "highly experimental" and wrote that a target-specific fuzzer would likely be at least as effective at finding vulnerabilities. The argument was not that language models had overtaken fuzzers, but that an agent that reads code and reasons about it can reach places a generic harness never exercises.

From one bug to a programme

Big Sleep grew out of an earlier Project Zero research framework named Naptime, as the title of the November post records. What followed in 2025 turned a single proof of concept into an operational tool — at least by Google's account.

The July 2025 claim was bolder than the first. In a post by Kent Walker, Google's president of global affairs, the company wrote: "We believe this is the first time an AI agent has been used to directly foil efforts to exploit a vulnerability in the wild." According to The Record, Google's threat intelligence group had seen signs that attackers were staging a zero-day without being able to identify it, and colleagues then used Big Sleep to isolate the flaw. Google declined to name the attackers or describe the indicators. No outside party has published evidence that would let the claim be checked.

For the August batch, Google spokesperson Kimberly Samra told TechCrunch that a human expert reviews each report before it is sent, but that each vulnerability was found and reproduced by the agent without human intervention. Details were withheld until fixes shipped, under Google's disclosure policy.

Who gained, who carried the cost

The beneficiaries of the November 2024 find are easy to name: SQLite's users, who never received the bug, and the open-source projects that later received Big Sleep reports. The approach also changes who can do vulnerability research. Finding a memory-safety flaw in mature code used to take scarce specialists; Google's framing was that an agent could search code at a scale human teams could not.

The costs fell elsewhere. The same TechCrunch report noted that maintainers of several projects had complained about hallucinated bug reports — the bug-bounty equivalent of AI slop — and quoted Vlad Ionescu, co-founder of the AI security start-up RunSybil, who said many submissions looked like gold but were "actually just crap". Every AI-generated report, good or bad, lands on a maintainer who has to read it. Google's answer was the human expert in the loop before submission; volunteer projects have no equivalent buffer on the receiving end. That tension, between finding more bugs and swamping the people who fix them, ran through the next two years and is the subject of the XBOW article.

There is also a defensive-versus-offensive question that Google's announcements leave open. A tool that finds an exploitable bug before release finds it equally well for whoever runs it. Google ran Big Sleep internally and reported what it found; it did not release the agent. The same choice — restrict the capability, use it defensively, publish the results — was made at much larger scale by Anthropic in 2026 with Claude Mythos Preview and Project Glasswing.

Where it sits in history

Big Sleep did not invent automated vulnerability discovery; fuzzers and static analysers had been finding bugs automatically for years. What changed in November 2024 was the method: a large language model reading source code, forming hypotheses and testing them, the way a human researcher would. The SQLite bug was small and caught early. Its significance lay in the precedent, which within eighteen months had become a race among AI labs and security vendors.

Related pages: the cybersecurity timeline, the AI timeline, and two earlier open-source security crises that defined how the industry thinks about shared code, Heartbleed and Log4Shell.