What does proof of exploitability mean in 2026? Four approaches vendors describe

Why does the word validation need unpacking?

Almost every vendor in this market now says it validates exposures. The methods differ in what they send, what they prove and how much trust they need. This note groups what vendors' own pages describe into four approaches.

1. Non-intrusive simulation

IONIX describes non-intrusive exploit simulations and prioritisation by business context, asset sensitivity and blast radius. Its Live Exposure Defense, released on 31 May 2026, correlates each newly published CVE with a customer's internet-facing assets, confirms exploitability through safe active testing and delivers a mitigation workflow within 12 hours. The strength is safety and speed on new CVEs; the trade-off is that it does not set out to prove how far an attacker could go.

2. Large black-box test libraries

CyCognito describes more than 100,000 unauthenticated black-box tests across 30+ categories, with no brute force or state changes. On 16 June 2026 it unveiled Continuous AI Pentesting, which it says runs AI-driven offensive testing continuously across the external attack surface.

3. Agentic attack-style testing

watchTowr describes continuous automated red teaming with eight agents, and on 24 July 2026 introduced Project Red, which it says reproduces emerging vulnerabilities to validate client exposure. Hadrian describes agentic AI that, by its account, proves exploitability within 15 minutes, and sells agentic penetration tests from a published 1,250 euros per test excluding VAT.

4. Runtime validation inside a platform

Rapid7 announced runtime validation for Exposure Command on 19 March 2026, aimed at showing which cloud vulnerabilities are exploitable. That is validation from inside a platform, aimed at cloud workloads rather than the external estate.

Which one do you need?

• If your engineers accept a confirmed exploitable finding without a full attack chain, approach 1 or 2 may be enough.
• If they want proof of impact, or you want to know how far an attacker could get, look at approach 3.
• If your gap is cloud workloads you already scan from inside, approach 4 may fit with your platform.

What should you ask?

What exactly a test sends; whether it can change anything; how fast new CVEs are tested; and whether the vendor retests after you fix. See Safe checks or attack-style testing.