Why OWASP’s AIVSS changes risk scoring for agentic AI

At a glance

What this is: This is Lakera’s analysis of OWASP’s AIVSS, a scoring approach that keeps CVSS as a baseline but adds agentic AI context for autonomy, memory, multi-agent interaction, and live exploit conditions.

Why it matters: It matters because IAM, PAM, and AI security teams cannot treat agentic systems like static applications, as runtime behaviour can turn ordinary vulnerability scores into misleading risk signals.

Context

CVSS was designed to score software weakness, not the behaviour of an AI agent that can choose tools, chain actions, and act on incomplete context. In agentic AI programmes, that matters because the same vulnerability can behave very differently once runtime autonomy, memory, and tool access enter the picture.

Lakera’s article uses OWASP’s AIVSS as the reference point for this shift. The key governance problem is not whether a vulnerability exists, but whether current scoring models account for the way agentic systems amplify a flaw after deployment.

That makes risk scoring part of identity governance for AI agents, not just a security metric. The article’s starting position is typical for teams moving from static application risk into agentic execution risk, where the score has to reflect behaviour, not only code.

Key questions

Q: What breaks when CVSS is used alone for agentic AI systems?

A: CVSS breaks when the system can act, choose tools, and continue without human gating, because severity is no longer just a property of the code. An agent can amplify a modest flaw into a broader operational event, so teams need a behaviour-aware layer on top of traditional scoring.

Q: Why do agentic AI vulnerabilities need a separate severity model?

A: They need one because autonomy changes the impact of a flaw at runtime. Memory, tool use, and multi-agent coordination can expand the blast radius far beyond what a static vulnerability score suggests, so teams must score the agent’s behaviour as well as the underlying defect.

Q: What signals show that an agentic AI risk score is too low?

A: A score is too low when the agent can reach external tools, delegate work to other agents, or turn a narrow defect into a chained action path. Those are signs that the system’s effective privileges and runtime behaviour exceed what the base vulnerability score implies.

Q: How should teams decide whether to trust a CVSS score for AI agents?

A: Use CVSS only when the agent behaves like a conventional application with tightly bounded actions. If the system can improvise, retain memory, or coordinate across agents, CVSS should be treated as incomplete and supplemented with agentic behaviour scoring before prioritisation.

Technical breakdown

Why CVSS misses agentic AI behaviour

CVSS scores vulnerability severity in a largely static context. Agentic systems change that context because the same flaw may be exercised by an entity that can select tools, carry memory across steps, and coordinate with other agents without a human deciding every action. That means the exploit path is not just a property of code, but of runtime behaviour. A score that ignores autonomy can understate operational exposure, especially where tool access or chained actions create cascading effects beyond the original bug.

Practical implication: Treat CVSS as a baseline, not the final severity view, for agentic AI services.

How AIVSS layers agentic AI risk onto severity

AIVSS keeps the CVSS base score, then adds an Agentic AI Risk Score and a Threat Multiplier. The AARS is intended to capture amplification from autonomy, memory, multi-agent interactions, non-determinism, and related agent behaviours. The Threat Multiplier then adjusts for whether exploitation is live or actively observed. The model is trying to answer two separate questions: how bad the flaw is in principle, and how much worse it becomes when an agent can act on it in production.

Practical implication: Score agent behaviour separately from code weakness when prioritising remediation.

Why multi-agent coordination changes the risk picture

AIVSS matters because agentic AI risk is rarely isolated to one component. Once multiple agents interact, one error can propagate through tool calls, delegated tasks, or shared context, which makes containment harder than in a traditional application. Lakera’s article points to real-world concerns such as tool misuse, cascading failures, and traceability loss. These are not just application security issues. They are governance issues for who or what is allowed to act, when action is permitted, and how much damage a single agentic failure can spread.

Practical implication: Review agent-to-agent dependencies and score them as part of the attack surface.

NHI Mgmt Group analysis

CVSS alone is structurally incomplete for agentic AI. The score was built for software weakness, not for systems that can choose tools, sequence actions, and continue without human gating. Once an agent can improvise at runtime, the vulnerability no longer behaves like a static code issue, so the risk score must reflect behaviour as well as defect severity. Practitioners should treat this as a scoring-model boundary, not a tuning problem.

Agentic AI risk is an amplification problem, not just an exposure problem. A modest flaw can become materially worse when memory, delegation, and multi-agent coordination are in play. That is why a named concept like runtime risk amplification is useful: the security question shifts from whether the bug exists to how far agent behaviour can expand its impact. Teams should score the amplification path, not only the underlying weakness.

Tool use changes the meaning of severity. In traditional application scoring, the system mostly consumes requests. In agentic AI, the system can initiate action through tools, which means severity now depends on what actions the agent can trigger, not just what data it can read. This is the point where application security and identity governance overlap, because authorisation has to follow action capability, not just interface exposure. Practitioners should align severity scoring with effective permissions.

Multi-agent coordination creates cascading failure conditions that legacy scoring models do not describe well. When one agent’s output becomes another agent’s input, a single defect can propagate into a larger chain of decisions, retries, or unintended actions. That makes observability, delegation boundaries, and runtime control part of the risk model. The implication is clear: agentic AI needs governance that understands interaction effects, not isolated component scores.

The emerging governance gap is not a missing metric, but a missing behaviour lens. Traditional vulnerability scoring assumes the system is mostly predictable once deployed. Agentic AI breaks that assumption because execution path, tool choice, and timing can all vary at runtime. NHI Mgmt Group’s position is that security leaders should stop treating agentic risk as an application-only problem and start treating it as a governance problem spanning identity, action, and accountability.

From our research library:

• Only 13% of organisations feel extremely prepared for the reality of agentic AI despite the majority racing toward autonomous adoption, according to the 2026 Infrastructure Identity Survey.
• Read next: Agentic AI Identity Guide

What this signals

runtime risk amplification: Agentic AI changes vulnerability management because the key question is no longer only how severe a flaw is, but how much the agent can amplify it once tools, memory, and coordination are available. Teams that keep using static severity alone will continue to mis-rank the issues that matter most.

The practical shift is from code-centric triage to behaviour-centric triage. That means scoring execution paths, delegated actions, and cross-agent dependencies alongside the defect itself, especially where a moderate issue can become a high-impact operational event.

Only 13% of organisations feel extremely prepared for the reality of agentic AI despite the majority racing toward autonomous adoption, according to the 2026 Infrastructure Identity Survey. That gap explains why scoring models now need to describe what agents do, not only what code allows.

For practitioners

• Score agent behaviour separately from code severity Use CVSS as the starting point, then add a behaviour layer for autonomy, memory, tool access, and multi-agent coordination before setting prioritisation.
• Review tool permissions as part of severity analysis Document which tools an agent can invoke, which actions those tools expose, and whether a moderate code flaw becomes high impact once tool execution is available.
• Map cascading agent dependencies Identify where one agent’s output feeds another agent’s decision path, then score those chains as a single risk surface rather than isolated events.
• Adjust triage for live exploit conditions Weight scores more heavily when the issue is already being exploited or discussed in active campaigns, because live threat context changes the practical urgency.

Key takeaways

• Agentic AI makes vulnerability scoring a behaviour problem as much as a code problem, because autonomy and tool use can magnify ordinary flaws.
• The article’s core evidence is that CVSS needs an agent-aware layer to reflect memory, multi-agent interaction, and live exploit context.
• Security teams should prioritise scoring models that measure runtime action, delegated privilege, and chained impact rather than defect severity alone.

Key terms

• Agentic AI Risk Score: A supplementary risk layer that adjusts vulnerability severity for agent behaviour. It captures how autonomy, memory, tool use, and coordination can amplify the effect of a flaw beyond what code-centric scoring shows.
• Threat Multiplier: A scoring modifier that raises urgency when an exploit is active, widely circulating, or likely to be used in the wild. In agentic settings, it helps separate theoretical weaknesses from issues that are already being exploited against systems with runtime authority.
• Runtime risk amplification: The increase in practical impact that occurs when a system can act at runtime instead of only executing predetermined logic. For agentic AI, this means the same flaw can have a larger blast radius because the agent can combine tools, memory, and timing.
• Agentic AI Risk Score: A score that adjusts ordinary vulnerability severity for how an AI agent can magnify harm at runtime. It accounts for autonomy, memory, delegation, and multi-agent behaviour so practitioners can judge the likely operational impact, not just the defect on paper.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.