Finding vulnerabilities with AI: the workflow decides, not the model

Two stories from the same week of July 2026. First: security researcher Chaofan Shou pointed the Kimi K3 model at Redis 8.8.0 and had 19 previously unknown vulnerabilities on the table after roughly 90 minutes, complete with proof-of-concept code. The Redis maintainers have since confirmed the findings with patch releases. Second: projects like curl and Node.js have paused or shut down their bug bounty programmes because they are drowning in AI-generated security reports, most of them worthless.

The same technology, a breakthrough in one case and a plague in the other. The difference is not the model. It is what is built around the model, and that is exactly what makes this case interesting for anyone who runs their own software and wants it checked.

The bottleneck is not finding, it is verifying

AI models have become frighteningly productive at flagging suspicious spots in code. The problem sits one step later. Someone has to review every report, and that review capacity does not scale when the volume of findings explodes. Stephan Zeisberg, Head of Research at Security Research Labs, puts it plainly, the real value is created by verification, and verification is what is scarce.

The numbers are stark. For AI security reports without built-in cross-checking, false positive rates around 80 percent were reported across 2024 and 2025. Four out of five reports are false alarms, yet they sound exactly as urgent as the one real finding. Dump such a list unfiltered on a small team and you create paralysis, not security. The paused bug bounty programmes are the logical consequence, because there strangers were dumping those lists on maintainers, hoping for payouts.

What the successful cases do differently

The Redis find and a second example show the productive variant. Mozilla closed 271 security bugs for Firefox 150, not with a better model but with a pipeline that enforces one hard rule, every finding needs a reproducible test case. A report without proof simply does not exist for the process. The same idea sat inside the Redis case, because the 19 vulnerabilities did not arrive as claims but with working proof-of-concept code the maintainers could run directly.

That is the entire trick, and it is less spectacular than the headlines. The AI may raise as much suspicion as it likes, but only what can be concretely demonstrated makes it onto the findings list. With that one rule the 80 percent pile of noise collapses, because false alarms by their nature cannot produce a working proof.

Photo: afgprogrammer / Unsplash

What an audit pass looks like for a web project

I work with AI on code daily and regularly run it across projects as a second pair of eyes. Out of that practice, a five-step routine has proven itself for ordinary web projects, meaning the size of a company website, a shop, a booking system or an internal tool:

1. Cut the scope small. Not “check everything”, but the places where there is something to take: login and session handling, file uploads, API endpoints, anything around payments, every spot that processes user input. A narrow brief produces deeper results than a broad one.
2. Write the proof obligation into the brief. The AI gets the rule that every finding needs a concrete test case, for instance the exact request that triggers the problem. Anything it cannot back up it may at most flag as an open question.
3. Deduplicate and cap findings. Models happily report the same weakness five times in variations. Allow a limited number of findings per code area and merge duplicates, otherwise the list grows faster than it shrinks.
4. Prioritise from the outside in. First everything a stranger can reach without credentials, then problems that require an existing account, last the theoretical weaknesses that are not even reachable in the actual setup.
5. Secure fixes with tests and repeat. Every confirmed finding gets a test after the fix that flags a regression. The pass itself gets repeated after bigger changes, an audit is a snapshot at time X, not a permanent certificate.

The time this takes has become manageable, the combing itself costs minutes rather than days. The work sits in the steps around it, and those resist automation because they need judgement.

Photo: andrewtneel / Unsplash

Where the human stays non-negotiable

Three things the pipeline cannot take over. The first is verification itself, because even a supplied test case has to be run, understood and weighed in context by someone. The second is the threat model, the question of what in this specific system is worth protecting and who realistically attacks it. An AI finds the unlocked basement, but it does not know whether tools or gold bars are stored down there. The third is logic and authorisation flaws in the business process, say a user reaching data not meant for them through a perfectly legal sequence of clicks. To every scanner, those look like normal behaviour.

Especially for projects built largely with AI, this second human view is the real gain. The code there is written faster than any human has ever read it, and the casual control of a classic code review is absent entirely. What typically slips through in those projects I have written up in the piece on due diligence for AI-built projects, and the audit is the matching tool.

Bottom line, the question has shifted. Whether AI can find vulnerabilities stopped being worth debating this July at the latest, 19 confirmed zero-days in 90 minutes end that discussion. The question is whether the stream of findings turns into verified, prioritised and fixed problems or into a list that paralyses everyone. The workflow decides that, not the model.

If you run an application, classically developed or AI-built, and want to know where it stands security-wise, feel free to get in touch. I run this kind of pass with reproducible proof instead of a list of horrors, and afterwards you know what actually needs doing and what does not.