A finding without an exploit is a rumor

Finding things that might be vulnerabilities used to be the expensive part of security work. In 2026 it got much cheaper. Google's threat intelligence group counted 5,045 disclosed CVEs in January and 10,740 in August, and warns that raw volume can mislead, since automated assignment for the Linux kernel accounts for part of it. The UK AI Security Institute estimates that the length of cyber tasks models can complete on their own has doubled roughly every 4.7 months since late 2024.

Attackers get the same discount. On October 19, NorForge published a write-up of Cairn, an AI-driven hacking system aimed at online shops. Attempts cost about $5 each, succeeded about 10% of the time, and took a little under 23 hours when they worked. The techniques it was told to prioritize were ordinary web bugs: SQL injection at login, file upload, deserialization, authentication bypass.

An agent's own verdict is not proof

In the RECEIPT study from UC Berkeley, an agent hunting cross-site scripting was told to verify each proof of concept before reporting it. It made 27 claims, marked each one verified, and 17 of them were false. That is 63%.

Even when findings are real, sorting them costs time. FireCompass reported its own results from 150 AI-assisted reports on HackerOne: 12.7% were accepted, 38.7% were duplicates of bugs someone else had filed first, and 32.7% were closed as informative, with a person checking each report before it was filed. curl's maintainer Daniel Stenberg wrote on October 22 that the pure nonsense has mostly stopped and today's reports are usually accurate, but every one now involves AI, and the work has moved to volume, wordiness and calls on what counts as a vulnerability at all.

For a team receiving findings, that is the cost that grows. Every finding that is unproven, duplicated or out of scope is engineering time spent sorting it, and a tool that produces ten times more candidates produces ten times more of that work.

Proof is a property of the process

The useful part of the RECEIPT result is what fixed it. The researchers stopped taking the agent's word: each proof of concept was replayed in a fresh, reset copy of the app, with attacker and victim accounts kept apart, and the verdict came from the replay. With the same agent and model, the system then made 30 claims and all 30 were real. It also found 24 new XSS bugs across 95 apps.

The design choice I would defend from that: the verdict should come from something other than the agent that made the claim, and where possible from running the exploit again.

What I ask of any finding, ours included

So when a finding lands in your queue, from us or from anyone else, these are the questions worth asking of it:

• Is there a working exploit against the system in scope?
• Did something other than the finder check it, ideally by running the exploit again?
• Can a third party rerun the evidence: the request, the response, the script?
• Is the severity argued from what the exploit achieved?
• After the fix, was the same exploit run again, and did it fail?

This is the bar Rheono is built around. The agents hunt inside a written scope, a separate validator agent tries to break each finding in its own session, for bug classes we can replay the exploit is rerun without a model, and nothing reaches you without a working proof of concept. The sample report shows the shape of one, and /verification shows how a finding closes.

Discovery gets cheaper every few months, on both sides of the fight. Proof is what holds its value, and the question worth asking any security vendor, AI or not, is what they do to show a finding is real before it reaches your queue.