AI Is Making Vulnerability Discovery Cheap. Remediation Is About to Become the Bottleneck.

A very large security company just moved toward the fix. That is not bad news for anyone whose business is closure — it is confirmation that a better list stopped being a product.

Verified Closure · 22 September 2026

On September 22, Palo Alto Networks launched Unit 42 Continuous Frontier AI Defense, a subscription service that runs continuous offensive testing against first- and third-party web applications, APIs, cloud infrastructure, source code repositories and network assets. It pairs frontier models from Anthropic and OpenAI with open-weight models to find exposures, prove they are actually exploitable by validating end-to-end attack paths, and then hand over prioritized fixes, code-level guidance and virtual patch recommendations.

The numbers Palo Alto published are worth reading closely. In its own environment, the company says it surfaced a year's worth of exposures in three weeks. Across its testing it reports 3.2 times more high and critical vulnerabilities per product than legacy methods, and that more than two in three exposures found in third-party applications had no known CVE.

Take those claims at face value for a moment, because the interesting part isn't whether the service works. Assume it does. Then ask the question every operations lead eventually asks:

What happens to everything it finds?

The cost of knowing is collapsing

For twenty years, the hard part of vulnerability management was producing a trustworthy list. Scanners generated noise. Half the findings were false positives, most of the rest were theoretical, and a good chunk of security engineering existed to work out which of the 4,000 open items actually mattered.

What Palo Alto is describing — and they are not alone, they are just the largest vendor to say it this plainly — is the industrialization of that work. Continuous discovery. Exploitability proven rather than assumed. Attack paths mapped end to end. Prioritization attached. A proposed fix, at the code level, delivered with the finding.

That is a genuine change, and it is worth naming as one. The cost of producing a validated, prioritized, genuinely actionable security finding is falling fast, and it will keep falling.

What doesn't get cheaper

A validated finding is not a fixed system. Between the two sits a chain that looks roughly the same in every enterprise we work in:

Somebody has to own the affected system. Somebody has to decide the proposed fix is operationally safe on that system, which is not the same question as whether it is technically correct. Somebody has to schedule it, which may mean a maintenance window, an application owner's sign-off, a vendor case, or a change advisory board that meets on Thursdays. Somebody has to deploy it across a fleet that is never in one state. Somebody has to handle the third of deployments that fail quietly. Then somebody has to prove the vulnerability is actually gone, and keep the evidence.

None of that gets faster because the finding arrived with better provenance. The chain crosses organizational boundaries, and the boundaries are where the delay lives.

The quote Palo Alto chose to publish from Anthropic is, unintentionally, a precise description of where the handoff happens:

Unit 42 “gets the fix in front of the right team first.”

In front of. The team still has to do it.

The queue nobody budgets for

Here's the part that deserves more attention than it's getting.

If discovery throughput rises sharply and remediation throughput stays flat, the result is not a more secure enterprise. It is a longer queue — and a queue of a much more uncomfortable kind.

The old backlog was full of maybes. You could live with 4,000 unreviewed scanner findings because everyone quietly understood that most of them were noise. The new backlog is different. Each item has been validated as exploitable, with the attack path documented and the fix specified. That backlog is not noise. It is a list of things you have been told are genuinely dangerous, with the remedy attached, that you have not done.

That changes the character of the risk, and it changes the character of the liability. Ask anyone who has sat through an incident review, a cyber insurance renewal, or a regulator's follow-up questions how a documented, validated, unremediated finding reads after the fact.

Palo Alto's own strongest remediation number quietly makes the point. The 51% reduction in mean time to remediate came from its internal deployment — a security vendor's own engineering teams, working on their own products, with their own code, on their own schedule. That is close to the best-case environment for turning a finding into a fix. It is not a hospital network with a clinical change freeze, a manufacturer with equipment that cannot be rebooted during a shift, or a public agency where the application owner left eighteen months ago and the vendor contract lapsed.

“Closed” is not one thing

Most remediation reporting collapses six distinct states into one word:

Those are not synonyms, and the gaps between them are where programs quietly fail.

A dashboard showing a vulnerability should be fixed is not evidence it was fixed. A ticket marked complete is evidence that somebody marked a ticket complete. An owner's assurance that the patch went out last weekend is a claim, not an observation. Even a successful deployment is not closure if the affected asset was offline that night and came back unpatched on Monday.

Verified closure means the end state is independently observable: the system was rescanned, the finding is gone, and the evidence is retained by somebody other than the person who performed the work.

That distinction was a nice-to-have when findings were cheap to ignore. It becomes the whole game when every finding in the queue has already been proven exploitable.

Where this leaves the market

The reflex reading of the Palo Alto announcement is that a very large security company moved closer to remediation, and that this is bad news for anyone whose business is remediation.

The more useful reading is that Palo Alto has now confirmed, with $17 million of R&D and a worldwide launch, that discovery alone stopped being a product. The market is moving toward the fix. It is moving there because customers made it obvious that a better list was no longer worth paying more for.

But the closer these platforms get to the fix, the more sharply they run into the part that is not a technology problem. Getting a correct command executed safely across a functioning enterprise, through the people who own the systems, within the change process that governs them, and then proving it worked — that is operational work, and no amount of model capability removes it.

So the position is not “keep your scanner, we'll do the real work.” It's simpler than that.

Keep your scanner. Keep Defender, Tenable, Qualys, Palo Alto. Let them get as good at finding things as they possibly can; that genuinely helps. We are interested in what happens after one of them identifies something that actually needs to be fixed: who owns it, what it takes to fix it safely, whether it actually got fixed, and what proof exists that it stayed fixed.

AI doesn't eliminate remediation work. It changes the economics of it. When finding the next vulnerability is nearly free, the scarce capability is the ability to close one — and to prove it stayed closed.