Vulnerability intelligence for AI agents: the complete guide

Point a capable language model at a security task and it can reason about a vulnerability as well as most engineers. What it cannot do is remember what is exploited in the wild, know how fresh its own knowledge is, tell you the base rate for a bug class, or notice when it has just invented a CVE that does not exist. Those are not reasoning failures. They are the things a stateless reasoner structurally cannot generate on its own, and they are exactly what "vulnerability intelligence for an AI agent" has to supply.

This guide is the complete, data-backed version of what that means in practice, built on a live corpus of 368,000+ CVEs fused from NVD, CISA KEV, FIRST EPSS, OSV/GHSA and CISA Vulnrichment (SSVC), plus a layer of ~14,000 distilled, disclosed bug-bounty mechanics. Every number below is measured, not asserted. It covers six things, in order: why raw CVE data is not intelligence, how to prioritize by exploitation, why the data has to be fresh, why agents fabricate CVEs and how to catch it, how attacks transfer across products, and the honest ceiling on what an autonomous agent can actually do.

Why a CVE lookup is not intelligence

The obvious way to give an agent CVE knowledge is a tool that proxies the NVD API: name a CVE, get its record back. That is a lookup, and it is fine for a lookup. It stops being useful the moment the agent has to decide something, because it cannot answer the four questions that actually drive a decision:

• Which of these matters? There are tens of thousands of "critical" CVEs. Severity is not urgency.
• What else works like this? The same bug mechanism recurs across unrelated products; a per-CVE lookup never surfaces the sibling.
• Is this claim even true? An agent will confidently cite a CVE that does not exist, or attribute a real one to the wrong product.
• How exploitable is this, really? A version match is a lead, not a finding; the dossier (is there a public exploit, is it automatable, is it being used now) is what decides.

Real intelligence answers those four. The rest of this guide is each of them, with the data.

Prioritize by exploitation, not by severity

This is the single highest-leverage thing an agent can get right, and most vulnerability workflows get it wrong. CVSS measures severity - how bad a bug is if exploited. It says almost nothing about whether it will be. In our corpus, with CISA KEV (the catalog of known-exploited vulnerabilities) as ground truth, the base rate of exploitation is 0.489%, roughly 1 in 200. Any signal worth using has to beat that base rate by a lot.

CVSS barely does. EPSS, which estimates the probability a CVE is exploited in the next 30 days, does dramatically better:

An EPSS >= 0.5 CVE is about 10x more likely to be actually exploited than a critical-CVSS one, and roughly 760x more likely than an EPSS < 0.001 one. And CVSS is nearly redundant once you have EPSS: combining both (15.5%) barely beats EPSS alone (15.2%). The takeaway for an agent is blunt: use EPSS, KEV and SSVC for likelihood, and keep CVSS only as the impact term, never as the answer to "should I worry."

Two more signals matter, both near-perfect filters:

• The exploit-tagged reference. 99.6% of exploited CVEs carry a reference tagged as an exploit or PoC. Among CVEs without one, exploitation is 0.003%. The presence of a public exploit reference is close to a binary "is this real" gate.
• SSVC's active tier. CISA's SSVC decision framework tags each CVE's exploitation as none / poc / active. Its active tier independently reconstructs the KEV catalog at 99.9%: of 1,613 CVEs marked active, 1,611 are in KEV. Two separate CISA programs agreeing almost perfectly is exactly what a ground-truth signal should look like, and active occasionally flags exploitation before KEV catches up.

There is also an ecosystem fingerprint: NuGet/.NET and Maven/Java packages are the most weaponized; Rust (crates.io) the least, a roughly 30x spread. An agent triaging a dependency should weight the ecosystem, not just the version.

Folded together, this produces a defensible P1-P4 model: P1 = KEV or SSVC active; P2 = EPSS in the top percentile or a working public exploit; P3 = high CVSS or high EPSS or a PoC exists; P4 = everything else. The full breakdown, with worked examples on Log4Shell, the xz backdoor, and BlackLotus, is in vulnerability prioritization that works, and the underlying measurement is in what actually predicts vulnerability exploitation.

Freshness is part of prioritization

A priority model is only as good as its data is fresh, and the window has collapsed. Median time from CVE publication to KEV listing fell from about 951 days in 2019 to roughly 2 to 8 days in 2023 to 2026. The patch window is now a week. An EPSS score you refresh weekly instead of daily, or a KEV entry you ingest late, silently turns a P1 into a missed P4. For an agent, this means the intelligence source has to be refreshed daily and carry its own freshness so the agent can distrust a stale answer. A concrete corpus_stats snapshot at the time of writing: 368,765 CVEs, 1,638 KEV entries, EPSS on 344,957 of them, data under half a day old. Those figures drift; the point is that the agent should be able to ask.

Agents hallucinate CVEs, and it is worse than it sounds

A generative system rewarded for finding bugs will, left alone, invent them. With CVEs this is acute because a CVE identifier (CVE-YEAR-NUMBER) is exactly the kind of structured token a language model fills in confidently. There are three distinct failure modes, and "add RAG" covers none of them cleanly:

1. Invented identifiers. The model emits a CVE ID that was never issued. It parses, so a human skims past it. This is the CVE analogue of slopsquatting (agents hallucinating package names, which attackers then register).
2. Wrong attributes on a real CVE. The ID checks out but the severity, exploited status, or affected product is wrong. The most dangerous mode, because the ID validates.
3. Right CVE, wrong reachability. Real and correctly described, but the target's vulnerable version or precondition is not actually present.

The defense is a per-claim fact-check against a source of truth, run before the claim ships, by something with no stake in the answer. Real refuted output:

verify_cve_claim("CVE-2025-99999")
  ->  exists: false   "No record in NVD / OSV / GHSA. Likely hallucinated or not-yet-published."

verify_cve_claim("CVE-2021-44228", product="Apache Struts", severity="medium", exploited=false)
  refuted  "not exploited"          ->  in CISA KEV (added 2021-12-10)
  refuted  "severity medium"        ->  actual CVSS 10.0 -> P1
  refuted  "affects Apache Struts"  ->  this CVE is Apache Log4j2, not Struts

That is Log4Shell, one of the most consequential bugs of the decade, described as a mild Struts issue, and each clause refuted with cited evidence. The full walkthrough of the three modes is in how to catch AI-hallucinated CVEs.

Find the move, not just the CVE

Known CVEs are the floor. The higher-value question for a security agent is "what attack works on a target like this," and the answer lives in the structure of past disclosures. A vulnerability is a transferable mechanism (source -> sink, via trigger, given preconditions), not a property of one product, and the reuse is measurable. In a sample of 10,000 disclosed HackerOne reports:

The median specific mechanism has already been filed against 4 distinct products; 70% are multi-product; a third have hit 11 or more. And it is not saturated: 27% of mechanisms first disclosed 3+ years ago recruited a brand-new product within the last 18 months (a lower bound, since public disclosure lags real discovery). The public record is, structurally, a transfer map: for most mechanisms you can read off which products an edge has been filed against and infer which comparable ones it has not been tried on yet. The full measurement is in do vulnerabilities transfer between products.

For an agent, this turns into two tools. find_attack_approaches retrieves the closest mechanics and, critically, takes a tried= list so it surfaces what you have not worked yet:

find_attack_approaches("a multi-tenant SaaS with a REST API and file uploads")   # tried=[]
  broken access control (public S3 bucket)     zomato      over-permissive bucket ACL
  arbitrary file read                          Nextcloud   trick the victim into an attacker-controlled app

find_attack_approaches(..., tried=["IDOR", "access control"])   # burn the obvious, and it re-ranks
  cloud storage takeover                       IBM         take over the S3 bucket tied to the endpoint
  authorization bypass (signed upload)         Rails       mismatched content_length so the presigned URL doesn't bind it

find_continuations is the by-step twin: give it your product-free attacker position and it returns the concrete payload step from a real report, each UNVERIFIED with the check that settles it (for a blind SSRF via webhook: point it at a 303-redirect to read arbitrary responses, or use DNS rebinding to pass the filter). This is the workflow shown end to end on the tools page.

The honest ceiling: an agent does not hack by itself

The last piece is the one the hype skips. We tested, across eight experiments, whether a large vulnerability corpus turns a model into a better autonomous researcher. The honest result is mostly no. A model with the corpus can reconstruct a developer's recurring broken assumption and occasionally predict a novel manifestation of it (it won on one product, lost on another by over-committing to the past pattern), but it is a modest edge over a strong base model, and a cheap model with the corpus does not match a frontier model alone. The details, including the failures, are in eight experiments.

The reason is structural, not a tuning problem. On a mature target, the agent reasons well and aims at a precise seam fast, and then it hands off: the paying vulnerabilities (account takeover, payment logic, cross-tenant access) live behind an authenticated session, a real phone, a WAF, a browser the sandbox does not have. That ceiling is an environment boundary, not a model-quality one, so a bigger model does not cross it. What actually compounds is not more reasoning but two unglamorous things around it: a memory of the agent's own dead ends (no public database contains failures, yet a recorded wall is worth as much as a lead), and a discipline that refuses to let a clever idea become a fabricated result. The full argument is in the bottleneck for AI security agents isn't reasoning, and the protocol-level consequence (you cannot inject a loop into a stateless caller) in why you can't turn a pull-based MCP into a push model.

The framing that follows from the data: this is a force-multiplier for a disciplined operator, not an autonomous finder. It orients, prioritizes, transfers a proven move, and keeps the agent honest. It does not grant the bug.

The tool workflow, end to end

Put together, an agent working a target moves through the intelligence in a natural order:

1. observe a live host - recover the real backend from the JS bundle, get the endpoints and the CVE join.
2. hunt_plan the recon'd stack - a ranked dig-order and the recurring bug-class loci per component.
3. program_outcome_prior - what bug classes have historically paid on this program (descriptive, not predictive).
4. find_attack_approaches / find_continuations - transfer the proven move, grow tried= to reach the non-obvious.
5. check_technology / search_vulns / enrich_cve - version-resolve, search by mechanism, pull the full dossier.
6. verify_cve_claim - fact-check before anything ships.
7. assist_submission - draft against the closest disclosed precedent.

Every tool, with a real example of what it returns, is on the tools page.

FAQ

What is vulnerability intelligence for an AI agent, versus a CVE database? A CVE database returns records you name. Vulnerability intelligence answers the decisions: which CVE matters (exploitation-first ranking), what else works like it (by-mechanism search), is the claim true (fact-check), and how exploitable it is (the full dossier). The first is data; the second helps the agent decide.

Should an AI agent prioritize vulnerabilities by CVSS? No. CVSS measures severity, not likelihood. In a 368,000-CVE corpus, critical-CVSS CVEs are exploited only ~1.4% of the time, while EPSS >= 0.5 CVEs are exploited ~15%. Use EPSS, KEV and SSVC for likelihood; keep CVSS as the impact term only.

What is the difference between EPSS, KEV, and SSVC? EPSS (FIRST) is the probability a CVE is exploited in the next 30 days. KEV (CISA) is the catalog of vulnerabilities known to be exploited. SSVC (CISA) is a per-CVE decision framework whose active tier reconstructs KEV at 99.9%. EPSS predicts, KEV confirms, SSVC decides.

Can an AI actually invent a CVE that does not exist? Yes. A CVE ID has a fixed, predictable shape, which is exactly what a model fills in confidently. The only reliable defense is to look the ID up in NVD/OSV/GHSA rather than trust that it parses.

How do I stop an AI agent from hallucinating CVEs? Attach every CVE claim (severity, exploited, affected product) to a per-assertion check against a source of truth, run before the claim counts, and treat any refuted as a hard stop. This catches invented IDs, wrong attributes, and unreachable-as-deployed claims.

How fast are vulnerabilities exploited now? Fast. Median time from CVE publication to KEV listing collapsed from ~951 days in 2019 to ~2 to 8 days in 2023 to 2026. The remediation window is now about a week, which is why the intelligence has to be refreshed daily.

Do vulnerabilities transfer between products? Measurably. In 10,000 disclosed reports, the median specific mechanism had already been filed against 4 different products, and a third against 11 or more. 27% of decade-old mechanisms recruited a new product within the last 18 months, so the transfer map keeps refilling.

Can an AI agent autonomously find and exploit vulnerabilities? On soft targets, sometimes. On hardened production, no: it hands off at the exploitation boundary (auth, a real device, a WAF), which is an environment limit a bigger model does not cross. The realistic role is force-multiplier for a disciplined operator, not autonomous finder.

How do I connect an AI agent to a vulnerability-intelligence source? Via an MCP server that exposes the intelligence as tools the agent calls like any other. A hosted option is mcp.rozetyp.com (free self-serve key), driven by the MIT-licensed bug-bounty skill and playbook.

Is the data live? It should be, and each record should carry its own freshness. Ask corpus_stats for the current size and data age rather than trusting a figure on a page.

This is built by vulntel, a hosted MCP corpus for AI security agents: fused CVE intelligence, exploitation-first ranking, by-mechanism transfer, and a hallucination guard, as one queryable socket. A key is free: mcp.rozetyp.com/signup. The MIT-licensed bug-bounty skill and playbook drive all twelve tools on a real engagement. The deep dives behind each section: prioritization, predicting exploitation, mechanism transfer, the eight experiments, the bottleneck, and catching hallucinated CVEs.