Proven beats predicted
Threat intelligence answers a question about the world: what are attackers using right now, somewhere, against someone.
Useful. But the question that decides your week is narrower: can this be done to us, here, today. AIPTx answers that one by trying, and keeping the request and the response.
Exploitability weighted at 40% · Evidence captured on every validated finding · CVE matching from live fingerprinting
Overview
Threat intelligence became a standard part of vulnerability management for a good reason. Severity alone is a poor guide to urgency, and knowing that a vulnerability is being actively exploited somewhere is genuinely better information than knowing its CVSS score.
But it remains a probabilistic input. A feed tells you that a class of vulnerability is being used against organisations that are not you, on systems that are not configured like yours. It raises the priority of a finding without establishing that the finding is real, reachable or exploitable in your environment.
For most tools that is the best available answer, because they cannot test. Detection is inference (a version matched, a pattern appeared) and inference plus intelligence is a reasonable way to rank inferences.
AIPTx is in a different position. It exploits. Where a finding can be safely demonstrated, the agent performs the attack and captures the request, the response and a reproducible curl command. That is not a probability that something might be exploitable. It is a record that it was.
So exploitability here is weighted heaviest in ranking (40 percent, ahead of impact, asset value and exposure) because the input is observation rather than estimation. A predicted exploitability of 0.8 and a captured HTTP response proving the exploit are different kinds of evidence and should never produce the same score.
Where intelligence still matters. This is not an argument that feeds are worthless. Two things validation cannot do: tell you a vulnerability is being weaponised right now in your sector, and rank a finding that could not be safely exploited. For those, conventional intelligence remains the better input, and the exclusions below are explicit about what AIPTx does and does not provide.
How It Works
- Step 01
Identification comes from behaviour, not declaration
Reconnaissance fingerprints frameworks, libraries, server software and versions from live behaviour: response signatures, header artefacts, bundled client code and dependency information. CVE matching then runs against what is actually running rather than against an inventory that drifted.
This matters more than it sounds. A version guess produces a CVE guess, and guessing is the origin of most of the noise in vulnerability management. Accurate identification is the precondition for accurate matching.
See Asset Discovery - Step 02
Then the match is tested
A CVE match is a starting point. Where the resulting finding can be exploited safely, it is, and a confirmed exploit is a different object from a version match. Only one of the two is worth interrupting someone for.
Where exploitation is not safely possible, the finding is reported without that proof rather than dressed up as though it had it. Proven and predicted are kept apart.
See AI Agent - Step 03
Reachability shapes the conclusion
A vulnerable component in your dependency tree is not automatically a vulnerability in your application. If the affected code path cannot be reached from an entry point, a CVSS 9.8 on paper may be unreachable in practice. Exposure is a ranking factor precisely because presence and reachability are different facts.
- Step 04
The result feeds prioritisation
Exploitability at 40 percent, impact at 30, asset value at 20, exposure at 10.
See Risk Prioritization
What is not included
Stated plainly, because this is where the category's expectations sit:
- No external threat feeds.
- No commercial or open intelligence feed integration.
- No CISA KEV correlation.
- Findings are not currently flagged against the Known Exploited Vulnerabilities catalogue.
- No EPSS scoring.
- No exploit prediction scoring.
- No exploit database correlation.
- Public exploit availability is not currently surfaced against findings.
- No dark web or leaked credential monitoring.
- Credential and dark web monitoring are not part of the product.
- No threat actor attribution or campaign tracking.
- Attribution and campaign tracking are not part of the product.
Capabilities
Technology and version fingerprinting
Frameworks, libraries, server software and versions read from live behaviour rather than from a declared inventory.
CVE matching
Against the versions actually fingerprinted, on applications and on discovered network services alike.
Exploit validation
The attack performed, with the exact HTTP request, the response proving it worked, and a reproducible curl command captured.
Exploitability weighted heaviest
Forty percent of per-finding ranking, derived from an executed exploit rather than from a predicted likelihood.
Reachability as a ranking input
Carried through the exposure factor, so a vulnerability nothing can reach is ranked as what it is.
Impact assessment
On every validated finding, stating what an attacker gains rather than what class the issue belongs to.
Classification and references
CWE classes and CVE references on findings, with links to the OWASP, CWE and CVE material behind each.
Severity scoring
CVSS 3.1 score and full vector string.
Network-layer CVE coverage
Version detection and CVE matching across discovered internal and external services.
Trend comparison across assessments
So the recurrence of a vulnerability class over time is visible, which is the pattern a feed would never carry.
Benefits
- 01
Urgency based on what happened, not what might.
An executed exploit is a stronger basis for interrupting a sprint than a probability derived from other organisations' incidents.
- 02
Noise from version-only matching drops.
Fingerprinting from behaviour and then testing the match removes a large share of what makes dependency findings exhausting.
- 03
Prioritisation you can defend.
"This is urgent because the exploit ran and here is the response" is an argument engineering accepts. "This is urgent because a feed scored it 0.87" is one they interrogate.
- 04
Reachability is accounted for.
A critical nothing can reach does not consume a sprint. Whether the vulnerable path is exercised at all is established before the finding competes for anyone's attention, so unreachable code is ranked as what it is rather than as an emergency.
- 05
No dependence on whether you are in the sample.
Intelligence describes what has been observed. A novel or environment-specific flaw appears in no feed, and is found here anyway, because the test does not require prior knowledge of the vulnerability.
- 06
False urgency is filtered out.
Findings that cannot be reproduced, reached or meaningfully exploited do not compete for attention, which preserves engineering time for issues that can actually affect the organisation.
Two findings on the same estate.
Illustrative example. Not a customer account.
Finding A. A library three versions behind, matched to a CVE with a CVSS base score of 9.1. It appears on every intelligence feed. It is on the KEV catalogue. It has public exploit code.
Finding B. A misconfigured authorisation check on an internal API endpoint. No CVE. No feed mentions it. It is unique to this application. CVSS-equivalent severity would be around 6.5.
Every intelligence-driven prioritisation model puts A first, emphatically.
- 01
For A, the agent identifies the vulnerable library, confirms the version from live behaviour, and attempts exploitation. The vulnerable function is never invoked by any reachable code path. The dependency is present but the affected feature is not in use. The exploit does not succeed. The finding is reported with that context: real, matched, present, and not currently exploitable here.
- 02
For B, the agent authenticates as a low-privilege user, requests a resource belonging to another account, and receives it. Request and response captured. curl command attached.
The ranking. B outranks A, because exploitability carries 40 percent and only one of the two was demonstrated. A remains in the queue: an unpatched dependency should be updated and a future code change could make it reachable, but it is not this week's emergency, and the reason is legible.
What this illustrates about intelligence.
The feeds were correct about A. It genuinely is being exploited, elsewhere, on systems where the code path is reachable. They were simply answering a question about the world rather than about this environment. And no feed contained B at all, because B has never happened to anyone else.
FAQ
Frequently Asked Questions
Do you integrate threat intelligence feeds?
No — there is no external feed integration, no CISA KEV correlation, no EPSS scoring and no exploit database lookup, and what AIPTx provides instead is CVE matching against versions fingerprinted from live behaviour plus validation by exploitation.
Isn't KEV data useful?
Yes, genuinely, and it is the single most valuable addition we could make here.
How do you prioritise without exploit-probability data?
By weighting exploitability at 40 percent and deriving it from an executed exploit rather than a prediction, with impact at 30, asset value at 20 and exposure at 10, all published.
What about vulnerabilities you cannot safely exploit?
They are reported without exploitation evidence and marked accordingly rather than presented as confirmed, which leaves reasoning about exploit availability and attack complexity a judgement your team makes.
Do you detect zero-days?
Not as known vulnerabilities, since no identifier exists, but testing does reach the flaws unique to your application — business logic, access control, workflow abuse — which appear in no feed because they have never happened to anyone else.
Do you monitor for our leaked credentials?
No, credential and dark web monitoring are not part of the product.
Do you attribute findings to threat actors?
No, attribution and campaign tracking are not part of the product.
Where does CVE data come from if there is no feed?
From versions fingerprinted off live behaviour and matched against known CVEs including at the network layer, which gives you no exploit-probability data or KEV cross-reference — and we would rather say so than describe fingerprint matching as threat intelligence.
Features that work with this one
Nothing here is a separate product. One assessment feeds all of them, which is why the output is a single ranked plan instead of nine disconnected tools.
Sixty criticals is not a plan
Findings ranked by exploitability, impact, asset value and exposure, with the weights published, so the order can be defended.
An agent that changes its mind
Agents that read the response and decide what to try next, which is what makes access control and business logic testing possible at all.
You cannot test what you have not found
Subdomains, ports, services, endpoints, JavaScript bundles and API schemas, mapped from live behaviour rather than from an inventory that drifted.
Find out what is exploitable here
Skip the probability. Run an assessment and see which findings the agent could actually demonstrate, with the request and the response attached.
Evidence on every validated finding · No credit card required