When AI Can Find Vulnerabilities Faster Than Security Teams Can Verify Them

Finding vulnerabilities has always taken work. Someone has to search the code, test the application, follow unusual behaviour and keep digging until a possible weakness becomes something they can reproduce. Even automated scanning only gets you so far. The difficult findings often need time, expertise and a willingness to try several paths before one leads somewhere interesting. 

AI is starting to change that equation. AI vulnerability discovery can make the search easier to repeat, run in parallel and apply across more code or applications. If one attempt doesn't find everything, running another is increasingly cheap. And because AI models don't always follow exactly the same path twice, another attempt may find something the first one missed. 

For security teams, that sounds like an obvious advantage. The more weaknesses you can find before an attacker does, the better. But every new finding creates another question: is this actually a vulnerability, or does it just look like one? That question isn't getting cheaper at quite the same rate. 

A finding still needs enough evidence to establish whether it's real, exploitable in practice and relevant to the organisation before somebody spends time fixing it. As AI increases the number of possible problems organisations can find, the constraint may be moving from discovery towards deciding which findings deserve to become security work.

AI Is Changing The Economics Of Vulnerability Discovery

AI isn't simply giving vulnerability scanners another feature. It's changing how much searching organisations can afford to do. A benchmark published by Aikido Security on 21 August 2026 shows why. The company tested 10 AI models against 32 fresh vulnerabilities and found that repeated runs could materially increase overall coverage. 

Three runs of DeepSeek V4 Pro collectively recovered 28 of the 32 vulnerabilities for around $295, outperforming individual runs of several more expensive frontier models. Three Flash runs cost $108 and collectively found 24. The interesting part isn't which model finished first. It's what happened when the researchers ran them again. 

Traditional automation tends to make repetition useful because it gives you scale. With probabilistic AI systems, repetition can also give you variation. The model may investigate a different path, make a different connection or find a weakness another run overlooked. 

Instead of asking one AI researcher to search harder, organisations can effectively send several researchers looking in different directions. That changes the economics of automated vulnerability discovery. Once the system and workflow are in place, another search doesn't require another security researcher to spend the same number of hours repeating the work. 

Organisations can run more searches, combine their results and potentially increase the number of weaknesses they find. Gartner is already treating the consequences as an enterprise risk. On 25 August 2026, it named AI-enabled discovery of cyber vulnerabilities the leading emerging risk in its Q2 survey of 316 senior executives and risk managers. 

Gartner warned that the efficiency and accessibility of AI-assisted discovery could make it difficult for traditional risk-management approaches to keep pace. There is an important distinction here. AI isn't necessarily making every part of vulnerability management equally cheap or scalable. It's making it easier to look. And looking harder tends to produce more things that need checking.

More Findings Don't Automatically Mean More Security Intelligence

Security tools finding more possible vulnerabilities isn't automatically a bad thing. Missing a genuine weakness because a system was too conservative isn't exactly a desirable outcome either. The problem is what happens after those findings arrive. A useful way to think about this is through two terms commonly used when assessing detection systems: recall and precision. 

Recall asks how many of the genuine vulnerabilities a system managed to find. Precision asks how many of the things it identified as vulnerabilities were actually vulnerabilities. Push harder for recall and you may find weaknesses that a more conservative search would miss. But if precision doesn't improve with it, you can also generate more false leads. 

Someone still has to work out which is which. Aikido saw this trade-off in its own testing. Repeated searches increased coverage, but the company also noted that the additional burden was transferred farther down the pipeline, where questionable findings had to be discarded. For an enterprise security team, that downstream cost can be substantial. 

A plausible finding may need to be reproduced, checked against the affected software and configuration, tested for exploitability and considered in the context of the organisation's actual environment. Until then, it isn't useful vulnerability intelligence simply because an AI system found it. It's a possible problem waiting for enough evidence to tell the organisation what, if anything, should happen next.

A Vulnerability Finding Is Still A Hypothesis

This becomes easier to see if we separate the stages that often get compressed into the word "vulnerability management".

Discovery → Verification → Exploitability → Priority → Remediation

Discovery asks whether there could be a weakness. Vulnerability verification establishes whether the finding itself is valid:

• Can the behaviour be reproduced?
• Is the vulnerable code actually present?
• Has the system identified a real flaw rather than misunderstood how the application works?

Exploitability moves the question closer to the real environment. A valid weakness can exist without being practically usable by an attacker under the organisation's current configuration, access controls or deployment conditions. Priority then introduces context. Even a genuine, exploitable vulnerability doesn't exist in isolation. 

Security teams still need to consider what the affected system does, what an attacker could reach through it and how urgently the risk needs attention compared with everything else competing for the same resources. Only then do we arrive at remediation. 

AI can increasingly contribute across this entire chain, so the boundary isn't as simple as machines discovering vulnerabilities and humans doing everything afterwards. But the distinction between the stages still matters because each one adds something the previous stage couldn't establish. 

A possible vulnerability isn't the same thing as a verified vulnerability. A verified vulnerability isn't necessarily exploitable. And an exploitable vulnerability doesn't automatically become the organisation's most important security problem. As discovery scales, keeping those distinctions clear becomes more important, not less.

The Verification Bottleneck Is Already Becoming Visible

We don't have to imagine what happens when vulnerability volume grows faster than the systems processing it. Parts of the cybersecurity ecosystem are already being forced to make choices about where limited attention goes. NIST changed the way it operates the National Vulnerability Database in April 2026 after CVE submissions increased 263 per cent between 2020 and 2025. 

It enriched nearly 42,000 CVEs in 2025, 45 per cent more than in any previous year, and still couldn't keep pace with incoming submissions. Instead of continuing to enrich every CVE with additional information security professionals use to assess risk, NIST moved to a prioritised model. 

Known exploited vulnerabilities, software used by the US federal government and critical software receive priority. Other CVEs can now be labelled "Lowest Priority" and aren't scheduled for immediate enrichment. NIST doesn't attribute that entire increase to AI, so we shouldn't either. 

But newer industry data suggests AI-assisted research is adding pressure to an ecosystem that was already struggling with volume. Beazley Security recorded 20,755 newly published CVEs in Q2 2026, up 36 per cent from the previous quarter. Around 5,600 were classified as high risk. 

Over the same period, additions to CISA's Known Exploited Vulnerabilities catalogue increased from 40 to 44, although that catalogue represents vulnerabilities meeting CISA's specific evidence requirements rather than every vulnerability exploited anywhere in the world. 

Beazley attributes the sharp growth in disclosures to widespread adoption of agentic AI in vulnerability research. The operational response is appearing elsewhere too. Cisco announced in June that it was moving to a scheduled, twice-monthly security disclosure model, explicitly describing the change as a response to AI-accelerated vulnerability discovery and a structural change in the threat landscape. 

HackerOne has approached the problem from another direction. Its Patch the Planet initiative pairs AI-assisted research with expert human validation, tested fixes and coordinated disclosure. The company says automated tooling has made it cheaper to file a vulnerability report than to confirm one, while open-source maintainers are left handling large numbers of unverified findings. 

Different parts of the vulnerability ecosystem are arriving at a similar problem. Increasing the supply of findings is relatively easy. Increasing the capacity to establish what deserves attention is harder.

Cheap Discovery Can Create Expensive Security Work

For enterprise security teams, the cost of a vulnerability doesn't begin when somebody patches it. It starts much earlier. A finding entering an AppSec or vulnerability-management workflow may need investigation from security analysts, developers or system owners. 

Someone may have to reproduce the behaviour, inspect the affected component, check deployment conditions and work out whether an attacker could realistically use it. If the finding is credible enough, it may then become a ticket, interrupt planned engineering work and move through change or remediation processes. 

AI can reduce some of those costs too. But if discovery expands faster than the rest of the workflow, cheap searches can still create expensive queues. This is different from ordinary alert fatigue. An alert usually tells someone that a system has detected an event or condition worth reviewing. 

AI security research can go further by producing detailed, technically plausible explanations of weaknesses that may require equally detailed investigation to disprove. The more convincing the hypothesis, the easier it becomes to treat it as work before the evidence justifies doing so. That creates a risk on both sides. 

Set the threshold too high and security teams may discard unusual findings that turn out to be real. Set it too low and developers can spend increasing amounts of time investigating problems that aren't exploitable, don't exist in the deployed environment or simply don't deserve immediate attention. 

The question isn't how to stop AI finding vulnerabilities. It's where the organisation places enough friction to stop security workload growing simply because discovery has become easier.

Vulnerability Counts Become Less Useful As Discovery Gets Easier

There is another consequence that sits slightly farther away from the technical workflow. The meaning of a vulnerability count starts to change. Imagine one organisation scans an application once and finds 100 possible weaknesses. Another runs several AI researchers across the same application, follows more paths and finds 250. 

The second organisation doesn't automatically have less secure software. It may simply have looked harder. That's always been true to some extent. Better tools and more mature security programmes tend to find things weaker programmes miss. 

But AI could widen the difference considerably because organisations can vary not only which tools they use, but how many searches they run and how aggressively those systems explore. Raw finding volume then becomes a poor measure of vulnerability risk on its own. The same problem applies internally. 

If an organisation introduces better AI vulnerability detection and its reported findings suddenly increase, leadership could interpret the rise as deteriorating security. In reality, the underlying exposure may not have changed at all. What changed was the organisation's ability to see it. That doesn't make vulnerability metrics useless. 

It changes what needs to sit around them. Leaders may need to pay closer attention to how many findings survive verification, how many prove exploitable, how much investigation low-confidence findings consume and how quickly genuinely important vulnerabilities move from discovery into action. 

Those measures say more about the effectiveness of the overall process than the size of the intake queue. As discovery capacity becomes easier to increase, decision confidence becomes a more useful part of the performance conversation.

AI May Have To Help Verify What AI Finds

There is an obvious problem with relying on human verification as the permanent answer to AI-scale discovery. It doesn't scale. If organisations can run five AI researchers today and 50 tomorrow, adding human analysts at the same rate defeats much of the economic advantage. Verification will have to become more automated too. 

We're already seeing the beginnings of that architecture. HackerOne's Patch the Planet model places expert validation behind AI-assisted research rather than sending raw findings directly to maintainers. Aikido describes pipelines that pool results from repeated searches and reject false leads before findings move farther downstream. 

Over time, automated vulnerability validation could become a much more explicit security layer. A discovery agent might identify a possible weakness. Another process could challenge the finding, attempt to reproduce it and collect evidence. 

Exploitability testing could then determine whether the flaw works under realistic conditions before environmental context and business importance decide where it belongs in the queue. That doesn't mean asking one AI system whether another AI system was correct and accepting the answer. Verification only creates value when it adds independent evidence. 

Reproducing behaviour, executing a controlled test, confirming affected versions or demonstrating a viable exploit path tells the organisation something new. A second model confidently agreeing with the first doesn't. Human judgement also doesn't disappear simply because more technical validation becomes automated. 

Someone still needs to decide how much evidence is sufficient, where automated testing is safe and when business context changes the answer. The aim isn't to remove people from vulnerability management. It's to make sure human attention arrives where judgement adds more value than another automated check.

The Goal Isn't Fewer Findings. It's Better Decisions About Them

None of this suggests security teams should tell their AI tools to stop looking so hard. Finding a vulnerability before someone exploits it is still a good outcome. Better discovery can expose weaknesses that traditional scanners, periodic tests or overstretched researchers might never have found. 

The problem starts when discovery capacity becomes the goal rather than one part of the process. For security leaders, the more useful question is whether verification capacity is developing alongside it. If the organisation doubles the number of candidate findings it can generate, what happens to everything those findings encounter afterwards? 

That includes the technical systems used to reproduce and validate vulnerabilities, but it also includes people. Developers, application owners and security analysts shouldn't become the default verification layer for every plausible finding an AI researcher can produce. The threshold for entering those workflows needs to be deliberate. 

Otherwise, organisations risk measuring the productivity of their discovery systems by how much work they create for everybody else.

Questions security leaders should be asking

A useful starting point is to examine how findings actually move through the current vulnerability verification process:

• What evidence does a finding need before it enters an engineering or remediation queue?
• How much of our current verification work is repetitive enough to automate safely?
• Which decisions still require human security, engineering or business judgement?
• Do we know how many findings are rejected during verification, and what investigating them costs?
• Can our systems distinguish a valid vulnerability from one that's exploitable in our environment?
• If AI discovery volume doubled, where would the first serious bottleneck appear?
• Are our vulnerability metrics measuring exposure, or simply how aggressively we're looking for it?

There won't be one correct threshold for every organisation. A vulnerability affecting an internet-facing payment system doesn't carry the same context as an identical flaw inside an isolated development environment. What security teams do need is a clear point where a possible problem becomes credible enough to consume scarce attention. 

Without that boundary, AI doesn't only automate vulnerability discovery. It can automate the creation of security work too.

Final Thoughts: Finding More Vulnerabilities Only Helps If You Can Decide What Matters

For years, one of the obvious limitations in vulnerability management was finding enough of the weaknesses attackers might use. AI is starting to loosen that constraint. Security teams can search more widely, repeat the search more cheaply and use several AI researchers to explore paths that one system might miss. That's progress. 

But it changes where the difficult part begins. A security programme that can generate thousands of plausible findings isn't necessarily more capable than one generating hundreds. The difference lies in what happens next: how efficiently it can establish which findings are real, which can actually be exploited and which deserve limited engineering and remediation capacity. 

The organisations that adapt best may not be the ones with the highest discovery numbers. They'll be the ones that build enough vulnerability verification and decision confidence around AI discovery to turn more searching into better security rather than simply larger queues. 

As AI keeps changing what security teams can automate, the useful questions will keep moving with it. EM360Tech will continue following where those changes create new decisions for the people responsible for enterprise security, risk and resilience.