Project Zero describes a curated October 2024 variant-analysis experiment: the researchers supplied a recently fixed SQLite vulnerability as a starting point and asked Big Sleep to search for a related bug. The selected Gemini 1.5 Pro trajectory could inspect source code, run SQLite, use a debugger, and iterate within the research environment.
What task was Big Sleep actually given?
The agent encountered a missing Tcl dependency, changed tactics, reasoned about the virtual-table planning path, and produced a SQL query that reproduced a stack-buffer underflow. Project Zero reported the finding to SQLite rather than granting the agent authority to patch or release production software.
What made the result verifiable rather than merely plausible?
The decisive artifact was the reproducible crashing query. It let researchers and SQLite maintainers inspect the same failure instead of accepting the model’s explanation on authority. Project Zero assessed the flaw as likely exploitable, while SQLite’s public check-in independently records the same-day repair to the generate_series() extension.
That handoff preserved separate responsibilities. The agent searched and assembled evidence; Project Zero reviewed and reported it; SQLite maintainers changed the code. The work crossed the proof boundary through a replayable artifact, but authority over remediation and release remained with the software owner.
What can—and can’t—the case establish about agentic work?
The case supports a narrow operating claim: an agent with bounded tools, a defined search target, and a reproducible acceptance artifact can perform useful security-research work. It doesn’t show that the system should receive production credentials, change code without review, choose business priorities, or control releases.
Project Zero published a selected successful trajectory, not an overall success rate, attempt count, cost comparison, or return-on-investment study. The finding was a curated research result, and ‘likely exploitable’ isn’t evidence of code execution, exploitation in the wild, a breach, or loss.
The 4P Verifiable-Agent Trace
Useful agent work becomes reviewable when the search is bounded, the artifact can be replayed, and effect authority remains with its owner.
| stage | case evidence | proof boundary | authority boundary |
|---|---|---|---|
| Pin | Researchers supplied a fixed vulnerability as the variant-analysis starting point. | The search target and relevant code family were explicit. | Researchers chose the task; the agent didn’t set security priorities. |
| Probe | The agent inspected source, executed SQLite, used a debugger, and adapted after a missing dependency. | Tool traces exposed the investigation rather than hiding it behind prose. | Tool use stayed inside the research environment. |
| Prove | A SQL query reproduced the stack-buffer underflow. | Reviewers could replay the failure independently of the agent’s narrative. | A finding remained a report, not permission to alter production code. |
| Pass | Project Zero reported the issue and SQLite maintainers fixed it the same day. | The public SQLite check-in corroborated remediation. | Maintainers retained patch and release authority. |
Ryze Guides analysis of Google Project Zero’s case report and SQLite’s public source-control records.
Original observation
The crashing query did more than support the vulnerability claim: it changed the coordination problem. Reviewers no longer had to decide whether to trust an agent’s explanation; they could replay the failure. Verifiability increased the work’s usefulness while leaving remediation authority exactly where it belonged.
How can you transfer this lesson to ordinary work?
Use an artifact-to-authority ladder. First define the search boundary: the code, records, or cases the system may inspect. Next define the trace: what it must preserve about tools, inputs, failed paths, and decisions. Then define the replay test: what an independent reviewer can run or inspect without trusting the model’s explanation. Only after those steps should you define the next permission.
| Rung | Question | What it can support |
|---|---|---|
| Boundary | What may the system inspect? | A bounded search |
| Trace | What did it try and use? | A reviewable process |
| Artifact | Can someone replay the result? | A finding worth review |
| Authority | Who may change the real system? | Only the separately approved action |
A practical transfer test
Suppose an agent reviews invoice records for duplicate payments. A persuasive paragraph isn’t enough. A useful output identifies the exact records, shows the comparison rule, preserves the query, and lets a person reproduce the match. Even then, the artifact supports investigation—not an automatic refund, vendor accusation, or ledger change. Those effects need their own owner, evidence standard, and approval.
This is the durable lesson from the documented Big Sleep case: design the work so success leaves something inspectable behind. Then keep the authority decision separate. That separation lets you benefit from capable search without asking one selected result to prove reliability, economics, or safety beyond the evidence.
Source notes
Cited sources support publicly available evidence and established patterns. Ryze Guides provides synthesis, decision aids, and practical interpretation to help you save time and mistakes.
- From Naptime to Big Sleep: Using Large Language Models To Catch Vulnerabilities In Real-World Code — Google Project Zero. https://projectzero.google/2024/10/from-naptime-to-big-sleep.html
Supports: Primary case report describing the bounded variant-analysis task, selected agent trajectory, reproducible query, disclosure, and stated limitations. - Fix a problem in the generate_series() extension — SQLite. https://sqlite.org/src/info/41d58a014ce89356
Supports: Official SQLite check-in independently recording the same-day repair to the generate_series() extension. - Better handle shared WHERE terms when planning virtual table queries — SQLite. https://sqlite.org/src/info/1976c3f7e1fe77cf
Supports: Official SQLite source-control record for the seed commit supplied to the selected Big Sleep trajectory. - Project Naptime: Evaluating Offensive Security Capabilities of Large Language Models — Google Project Zero. https://projectzero.google/2024/06/project-naptime.html
Supports: Primary architecture context for the code-browser, Python, debugger, and reporting tools used by the research agent.
