AIVSS, explained

AIVSS is the OWASP AI Vulnerability Scoring System, a way to put a number on how dangerous a flaw is once an AI agent is holding it. It starts from the CVSS v4.0 base score, the familiar 0 to 10 severity rating for a software vulnerability, then adds an uplift for how much the agent's deployment amplifies that flaw. The final number is reported on the same 0.0 to 10.0 scale. The piece that has shipped so far is the agentic scoring system, written against OWASP's ten Agentic AI Core Security Risks (OWASP AIVSS).

The premise fits in one sentence: the same bug is worth more to an attacker when the thing holding it acts on its own, carries tools, remembers across sessions, and talks to other agents. CVSS scores the flaw. AIVSS scores the flaw in the deployment you actually run.

Why CVSS alone underserves agents

The spec's own worked examples make the case better than an argument does. Take agent goal and instruction manipulation, where an attacker steers an agent away from the task it was given. The underlying technical flaw scores a CVSS base of 2.1, low enough that most triage queues would never reach it. Scored through AIVSS with the agent's real autonomy, tool access, and persistence counted, it comes out at 7.1, which lands in the High band. Agent memory and context manipulation makes the same move, from a CVSS base of 5.8 to an AIVSS score of 8.9. At the other end, agentic tool misuse starts at a CVSS base of 9.4 and finishes at 9.9, because there was very little headroom left to add (AIVSS v0.8, section 3.7).

How the scoring works

An assessor scores ten Agentic Risk Amplification Factors, each one 0.0 for absent, 0.5 for partial, or 1.0 for full: Autonomy, Tools, Language, Context, Non-Determinism, Opacity, Persistence, Identity, Multi-Agent, and Self-Modification. They sum to somewhere between 0.0 and 10.0.

From there the arithmetic is deliberately plain. Subtract the CVSS base score from 10 to get the headroom the spec calls the agentic risk gap. The uplift is that gap multiplied by the factor sum over ten, then by a threat multiplier: 1.00 if the flaw is being exploited in the wild, 0.97 if functional proof-of-concept code exists, 0.50 if nothing is known. Add the uplift to the CVSS base, multiply by a mitigation factor of 1.00 for weak or absent controls, 0.83 for partial, 0.67 for validated and consistently enforced, then round to the nearest tenth. Severity bands follow CVSS convention: Critical at 9.0 and above, High from 7.0 to 8.9, Medium from 4.0 to 6.9, Low from 0.1 to 3.9.

Two design choices are worth knowing before you read anyone's score. The defaults are pessimistic on purpose: 0.97 for the threat multiplier and 1.00 for mitigation, on the reasoning that an agentic proof-of-concept is usually plain language and needs no compiling, so the distance to a live attack is short. And the mitigation factor floors at 0.67, meaning the best controls you can demonstrate cut the score by a third at most. OWASP calls that floor a provisional anchor, set by design consensus and open to revision once real deployment data comes back.

Version status and timeline

Version 0.8 was published on March 19, 2026, after roughly 1,900 industry comments on the previous draft, and a public review period opened on April 16, 2026. Version 1.0 is targeted before the end of 2026, so v0.8 is what you are scoring against today. The v0.8 release added mappings to the OWASP Top 10 for Agentic Applications, the Cloud Security Alliance's MAESTRO layers, the AIUC-1 standard, and the NIST AI Risk Management Framework (release announcement by project lead Ken Huang). A published crosswalk turns high-severity AIVSS findings into specific AIUC-1 requirements, dated February 27, 2026 (OWASP AIVSS).

What to do with a score

• Read the factor breakdown, not just the number. A large uplift over a small CVSS base is the signal that your deployment, not the code, is the risk driver.
• When that is what the breakdown says, the spec's own guidance is to constrain the agent rather than patch: narrow tool access, reduce autonomy, shorten memory retention, add a human approval step. Patching alone will not move the number much.
• Record your inputs alongside the score. A 9.7 computed on defaults and a 9.7 computed on evidence are different claims, and only one of them survives an auditor.
• Claim 0.67 for strong mitigation only when you can show the control was validated and fails closed. That is what the spec asks for, and it is the single largest lever on the result.
• Do not average scores across findings. The spec is explicit that averaging ordinal values produces a number with no meaning. Score each finding and use its band.
• Ask vendors which AIVSS version they scored against, and whether they publish the ten factor scores or only the final number. A vendor who will not show the factors is asking you to trust their view of your deployment, which they have not seen.
• Feed the scores into the risk register you already keep, and set a band that triggers deeper pre-release review. AIVSS is built to slot into that process rather than replace it.