Over the past year, security teams on our platform cut the time it takes to fix a critical vulnerability by roughly 50%. In the same period, their backlog of unresolved critical vulnerabilities grew nearly 29-fold. These numbers describe the problem every security leader is about to inherit.

AI can now test software at a scale manual testing never reached. Models read code and search thousands of assets for familiar vulnerability patterns, surfacing exposures earlier and faster than any human team could.

For businesses trying to keep pace with an expanding attack surface, that reach is genuinely valuable. It is also exposing a weakness that has drawn far less attention: most organizations cannot validate, prioritize and remediate findings at anything close to the rate AI can produce them.

That imbalance is the whole game now. Investment in AI discovery tools, on its own, does not make an organization more secure. It makes it busier. Left unaddressed, it leaves security teams with larger backlogs and less attention paid to the flaws that actually put the business at risk.

This is the problem Continuous Threat Exposure Management (CTEM) exists to solve. CTEM gives organizations a continuous process for understanding their attack surface, finding weaknesses, proving which are genuinely exploitable, and directing remediation towards the exposures that carry the most business risk. Discovery is one input. The advantage comes from everything after it.

Security leaders have long treated discovery as a capacity problem: test more assets, cover more code, catch weaknesses earlier. AI answers that question decisively. But finding a potential vulnerability is the start of the work, not the end of it.

Every finding still has to be confirmed as exploitable and judged for severity in the specific context where the technology runs. Then it has to reach the right engineering team, win out against existing priorities, get fixed, and be retested to prove the fix holds. AI compresses the first step and barely touches the rest.

That is why the two numbers I opened with can both be true. A rising count of findings can mean better coverage. Faster repairs can sit alongside a growing backlog when discovery accelerates faster than remediation and engineering capacity moves the other way. Neither figure means much alone. The only view that matters runs the entire route, from first detection to verified fix.

Validation is the choke point

AI has also driven down the cost of producing a convincing security report. Some of those reports point to real weaknesses. Others duplicate known findings, misread the target, or describe theoretical issues that carry little real risk. Everyone still has to be investigated. A report that takes seconds to generate can consume hours of an experienced analyst's time before it can be dismissed with confidence.

At enterprise scale, that is how urgent findings get buried. A well-evidenced vulnerability with a credible attack path lands in the same queue as hundreds of submissions that sound plausible and lead nowhere. Security teams have to separate the AI gold from the AI slop, decide which real findings matter most, and do it with engineering capacity that has not grown to match.

Program owners need clear standards for evidence to make that possible. Researchers should be expected to show the likely business impact and demonstrate how a vulnerability reproduces, with automated tooling used to raise the quality of that evidence rather than the volume of submissions.

A consistent track record of valid findings tells a program owner whose work deserves attention first. That record is worth more, not less, as submissions rise.

Business context still decides what matters

Technical severity is only part of what you need to know to decide what to fix first. AI can match a finding to known patterns and reason over the systems it can reach. What it rarely has is the full picture the business holds: which services generate revenue, where regulated data lives, which dependencies make downtime especially expensive, and what compensating controls already exist.

The harder problem is combination. Individual findings that look moderate on their own can form a serious attack path once someone understands how the systems interact, which permissions can be abused, and where controls break down across organizational boundaries.

That is human work. And it is better human work when it is diverse: one researcher goes deep on identity controls, another on API behavior, another on how minor weaknesses chain together across systems. That variety surfaces novel attack paths that automation, and even advanced cyber-models, miss.

Our own data shows what that work is worth. Researchers earned more than $47 million on the H1 Platform in the first half of this year, up more than 25% year on year. The strongest earners are the ones who can explain business impact and show exactly how a weakness can be used.

That is also where researchers add the most to a CTEM program: testing whether an exposure holds up under real conditions, and spotting the connections between weaknesses that look harmless in isolation.

That figure deserves an honest footnote. Aggregate earnings rising does not mean every researcher is winning. As AI absorbs the routine, high-frequency findings, the researchers who once made a living there feel the change first, while those who can chain weaknesses, reason about business logic and produce credible proof find their work worth more.

The job of any serious bug bounty platform is to make that a transition its community can move through, not a wall most of them hit.

That obligation runs both ways. If programs expect researchers to raise the quality of their evidence, researchers should expect fast and fair triage in return, real recourse when a valid report is wrongly dismissed, and a door that stays open to newcomers who have not yet built a reputation.

The best researchers increasingly use AI tools themselves, and the value of a report has never turned on whether a tool helped produce it. Protect the economics and the fairness that reward credible work, and the independent research community grows stronger as AI scales, not thinner.

Build for the volume AI creates

So, is bug bounty dead? Far from it. Assume discovery will only accelerate, and put the effort into everything that happens after a flaw is found.

More discovery puts more pressure on the point where reports are validated and handed to engineering. Without enough triage capacity, well-evidenced findings stall behind automated noise.

Without clear ownership, confirmed risks sit in the gap between security and development. Independent verification matters at the other end too, especially when an AI system proposes the fix and may carry the same blind spot into its judgement of whether that fix works.

Boards and executive teams need measures built on risk reduction, not activity. Finding counts are easy to report and can climb even as an organization gets safer. Confirmed exploitability, remediation speed, recurrence, and the size of the unresolved critical backlog tell the real story.

CTEM holds those activities together as a continuous process, keeping discovery, validation, prioritization and remediation connected as the attack surface changes. It gives security leaders an honest view of where they are gaining ground and where exposure is still building.

The next phase of AI security will not be won on discovery. Discovery is already abundant. It will be won on response: knowing which findings represent real exposure, and moving the most dangerous of them through to a verified fix. AI supplies the reach. Independent researchers supply the judgement and the adversarial creativity AI still lacks.

The organizations that build to convert both into action will pull ahead. The ones that do not will own a faster-growing list of vulnerabilities they never fixed.

We've featured the best endpoint protection software.

This article was produced as part of , our channel to feature the best and brightest minds in the technology industry today.

The views expressed here are those of the author and are not necessarily those of TechRadarPro or Future plc. If you are interested in contributing find out more here: https://www.techradar.com/pro/perspectives-how-to-submit