Devansh Batham wrote that one vulnerability submission earned a $100,000 bounty.
I asked what made the finding so expensive. He replied with Needle in the haystack: LLMs for vulnerability research.
The title suggests a story about finding one hidden bug. The method is more useful than that.
His core claim is that LLMs found the reported vulnerabilities without manual source review. I cannot independently verify every listed finding or bounty detail. I can inspect the workflow, compare it with primary research, and test whether the lessons make engineering sense.
They do.
A vague audit prompt creates a vague search
Find all vulnerabilities in this repository sounds ambitious. It gives the model no useful boundary.
The model must invent the threat model, select the entry points, understand the trust boundaries, search the entire codebase, and prove each result. That is several hard jobs in one prompt.
Long context does not remove this problem. Chroma tested 18 models and found that performance became less reliable as input length increased. Its controlled tests also found that distractors caused more damage at longer lengths.
The earlier Lost in the Middle paper found that models used relevant information less reliably when it appeared inside a long context.
More context can be useful. Unselected context is still work the model must do.
Start with the attacker model
Batham starts with past vulnerabilities, entry points, trust boundaries, high-risk operations, and the attacker-victim relationship.
That turns a general code review into a set of small questions:
- What input can the attacker control?
- Which identity or tenant owns the target data?
- Which guard must run before this operation?
- What invariant would a valid request preserve?
- Which call chain reaches the risky operation?
This is ordinary security engineering. The LLM helps search and explain the slice. It does not replace the threat model.
The one-page limit in the article is a useful constraint. A threat model should direct the audit. It should not become another haystack.
Audit thin slices
The article recommends narrow slices of code with exact call chains, guards, and attacker-controlled values.
This changes the model’s job from understand everything to test this invariant along this path.
That is also how I would make the work reviewable. A human can inspect a small path. A verifier can run against it. A maintainer can reproduce the result without accepting a long chain of model reasoning.
The approach matches a larger result from Mozilla and Anthropic. In March 2026, Mozilla reported 22 CVEs, including 14 high-severity bugs from an AI-assisted Firefox review. Mozilla highlighted the minimal test cases that made the reports easy to verify.
Anthropic’s account says the work scanned nearly 6,000 C++ files and produced 112 reports. Not every report became a security bug. The triage loop with Mozilla mattered.
That is the part I trust most: large search, small proof, maintainer validation.
The verifier is the product
Batham lists tests, crash harnesses, fuzzers, static checks, and policy checks as verifier loops.
This is the strongest lesson in the article.
An LLM can produce a convincing explanation for a path that cannot occur. A runnable test turns the claim into evidence. A failing invariant check can search every future change. A maintainer can reject the report without debating prose.
The useful loop is:
- Define one attacker capability and one protected outcome.
- Select a narrow code path.
- Ask the model for candidate failures.
- Build a runnable verifier.
- Keep the finding only when the verifier proves it.
The model can help with each step. The verifier still decides what survives.
Less scaffolding can produce more signal
The article proposes spending less than 10% of the effort on agent scaffolding, 60% to 80% on slice audits, and 20% to 30% on verifier loops.
Those numbers are a field rule, not a published benchmark. The direction is sound.
A large instruction system often feels like progress because it is visible and reusable. It can also add competing rules, stale assumptions, and more text between the model and the code that matters.
I would keep four items in the persistent instructions:
- The threat model.
- The allowed attacker capabilities.
- The protected invariants.
- The required proof format.
Everything else should earn its place through a better verified finding rate.
My takeaways
The lesson is not that an LLM can replace a security researcher.
The lesson is that an LLM becomes more useful when the researcher gives it a bounded security problem and a hard proof loop.
I will use this pattern for defensive reviews:
- Build the threat model before opening a large context.
- Search one trust boundary at a time.
- Ask for exact data flow and guards.
- Require a safe, runnable reproducer or invariant check.
- Record false positives beside confirmed findings.
- Send maintainers concise evidence through responsible channels.
The bounty is the headline. The reusable part is the discipline that made one finding defensible.