A vulnerability list tells you what is broken. An attack path tells you what can actually be reached, and through which steps. For an AI agent, those steps are usually a credential, a role and a data store, and none of them has to be a CVE.
The short answer: use the vulnerability list for coverage, and use attack paths to decide what to fix first. Agents carry standing permissions, so the question that matters most is what an agent can reach if someone steers it. A path answers that. A score does not.
In this piece, we will cover:
- What a vulnerability list measures, and what it leaves out
- What an attack path is and how it differs
- Why agents with standing permissions make paths the better unit
- What a breakpoint is and how to find it
- Where nerl0 fits, and the honest limit of any path
What does a vulnerability list tell you?
A vulnerability list names flaws in software, usually with a severity score. That is useful. It tells you what exists in your estate and gives you a common vocabulary.
But the score has a defined scope. FIRST, the body behind CVSS, says in its user guide that a CVSS Base score measures severity, not risk, and should not be used alone to assess risk. Base scores describe the intrinsic traits of a flaw, independent of threats and of the environment it runs in. FIRST says the Base score should be supplemented with threat and environmental analysis, and that this work falls to the organisation using the score.
Other inputs exist for the threat side. CISA's Known Exploited Vulnerabilities catalog lists flaws that attackers are known to exploit in the wild, and CISA says organisations of any kind can use it as one input into prioritising what to fix. FIRST's EPSS estimates the likelihood that a published CVE will be exploited in the next 30 days. Both help rank flaws. Neither tells you where a flaw sits in your own environment.
What is an attack path, and how is it different?
An attack path is a chain of steps from an entry point to a valuable asset. ArmorCode, a vendor, describes attack path analysis as correlating identities, configurations, network relationships and known vulnerabilities to show which weaknesses connect to a critical asset and which lead nowhere. Its premise is that a vulnerability by itself rarely causes a breach.
The unit of work changes. A list asks, "Which flaws are severe?" A path asks, "What can be reached from here, and what is in the way?" Note that ArmorCode also states the limit: the analysis only works as well as the data feeding it, and a graph built from one tool or one domain misses paths that cross between domains.
| Question | Vulnerability list | Attack path |
|---|---|---|
| What is the unit? | One flaw in one component | One route from entry point to asset |
| What does it answer? | What is broken | What can be reached, and how |
| What does it rank by? | Severity, exploit signals | Position on a route to a sensitive asset |
| What can it miss? | Access that needs no flaw | Routes outside the data it sees |
Why do agents with standing permissions make paths the better unit?
An AI agent acts through credentials. It holds an API key, a service account or an OAuth grant, and that identity has a role with permissions. Those permissions are standing: they exist whether or not the agent uses them today. See what a non-human identity is for the background.
That changes what "exploitable" means. If someone can steer an agent with a crafted prompt, a poisoned document or a tool response, the agent can do what its role allows. No CVE is needed. OWASP lists this kind of problem in its Top 10 for Agentic Applications as ASI03, Identity and Privilege Abuse, and describes it as leaked credentials letting agents operate far beyond their intended scope.
A vulnerability scanner will not flag a broad role as a flaw, because a broad role is a configuration, not a defect in code. A path sees it, because the role is a step between the agent and the data store. The same logic holds for tools: MCP servers are a doorway with credentials, and the doorway matters only because of where the credentials lead.
What is a breakpoint, and how do you find it?
Many paths share steps. ArmorCode calls the nodes where multiple paths converge choke points, and says that fixing one can collapse dozens of paths at once. This post uses the word breakpoint for the same idea: the one step whose removal cuts the most routes to a sensitive asset.
For agents, a breakpoint is often not a patch. It can be one permission on a shared role, one credential reused by several agents, or one grant nobody owns. To find it:
- Pick the assets that matter. Start from the data stores you would least like to lose, not from the agents.
- List every route to them. For each route write down the agent, the credential, the role and the store.
- Count the routes through each step. The step that appears on the most routes is the candidate.
- Check what removing it costs. A permission an agent never needs is the cheapest cut. A permission a workflow depends on needs an owner's decision.
- Fix it, then look again. The paths you expected to disappear should be gone. If they are not, the map was incomplete.
This does not replace patching. A flaw on KEV that sits on a route to a sensitive store jumps the queue. A high-score flaw that sits on no route can wait. The two views work together, and the path supplies the context the score lacks.
Where nerl0 fits
nerl0 maps every AI agent and non-human identity and what each can reach. It connects read-only through each platform's own interfaces and reads configuration and permission data, never the contents of data stores.
The Attack Path view and the Security Graph show authority paths: agent, credential, role, crown-jewel data store. Every step is an observed relationship. The guide on how to read the Security Graph walks through one path step by step.
Issues carry severity, evidence, an owner and a recommended breakpoint. The next scan verifies the fix. That matches the loop above: pick the cut, make it, and look again.
A path is a route that exists in configuration. "Proven" describes the route, not that anyone used it. A path does not say whether an agent will follow a given prompt, or what sits inside a data store. Every answer in nerl0 states what it cannot show. More on this in A route is not proof of use.
Coding agents are a common start of such paths, because they inherit the developer's credentials. See what credentials your coding agent inherits.
Summary
A vulnerability list tells you what is broken. An attack path tells you what an agent can reach, through which credential and role. Because agents hold standing permissions, paths are the better unit for deciding what to fix first, while scores and KEV keep their place for coverage. Look for the breakpoint, the one step that removes the most routes, and remember that a route is not proof of use.
Sources
- CVSS v4.0 User Guide, FIRST, accessed Oct 29, 2026
- Known Exploited Vulnerabilities Catalog, CISA, accessed Oct 29, 2026
- Exploit Prediction Scoring System (EPSS), FIRST, accessed Oct 29, 2026
- What Is Attack Path Analysis? A Practitioner's Guide, ArmorCode, accessed Oct 29, 2026
- OWASP Top 10 for Agentic Applications: the benchmark for agentic security, OWASP Gen AI Security Project, accessed Oct 29, 2026
Sascha writes about what AI agents and non-human identities can reach, and builds nerl0 to keep that visible.
