How should security teams score AI findings that do not fit CVSS?

Why a separate scoring model is needed for AI findings

AI findings often describe behaviour, exposure, or policy failure rather than a conventional software flaw. A model can produce unsafe, misleading, or prohibited output without there being a single exploitable vulnerability in the CVE sense, so the scoring method needs to reflect the operational outcome, not just the presence of an exploit chain.

That distinction matters because the same AI issue can be trivial in a lab, material in a regulated workflow, and severe when it is exposed to customers or decision makers. A useful score therefore needs to encode audience, repeatability, and consequence, not just technical elegance.

When you do need a vulnerability lens, use FIRST CVSS for the technical side and keep AI-specific harmful behaviour in a separate scoring track so the two do not blur together.

What an outcome-based score should measure

An outcome-based model should answer a different question from CVSS: what harm can this behaviour cause if it is reached in practice? The score should weigh who can trigger the behaviour, whether it can be repeated reliably, how easy it is to provoke across prompts or sessions, and whether the result is mere inconvenience, policy breach, financial loss, or legal exposure.

The best scoring systems also distinguish between direct user harm and indirect enterprise harm. For example, a hallucinated answer that causes a single bad recommendation should not be scored the same way as a repeated failure that exposes customer data, undermines a workflow, or produces regulated decisions at scale.

Teams that need a practical baseline for vulnerability-style risk can anchor technical exposure in the NIST National Vulnerability Database, then score the AI behaviour separately when the issue is not a classic vulnerability.

How to keep AI scoring usable in the triage queue

AI risk scoring fails when every odd output is treated as equally severe. The triage rule should be simple: if the issue is a technical weakness in the system, score it like a vulnerability; if the issue is harmful model behaviour, score the impact of the behaviour itself and the conditions under which it becomes repeatable.

That usually means using different severity bands, different ownership, and different remediation paths. A prompt injection that reaches a protected tool, a policy breach that exposes regulated content, and an unsafe recommendation in a consumer workflow may all need different controls even if they were all generated by the same model.

For teams formalising this split, a broader operating model can help align the scoring method with remediation, inventory, and exception handling, as described in AI Security Maturity Model and AI Security Platform Buyer's Guide.

Practitioner Guidance

What to prioritise: Score the exposure first, not the novelty of the finding. If the behaviour can reach customers, regulated decisions, or privileged workflows, treat it as more serious than a technically interesting but contained failure.

Decision rule: Use CVSS only when the issue is a genuine technical vulnerability. If the concern is unsafe output, policy violation, or harmful interaction, use a separate rubric that captures audience, repeatability, and worst-case business impact.

What to verify: Confirm whether the finding is reproducible under realistic conditions, whether it affects one user or many, and whether it can be triggered deliberately or only in edge cases. Without that evidence, severity is easy to inflate or suppress incorrectly.

Practitioner takeaway: The key is to score AI behaviour by consequence and repeatability, so teams do not bury dangerous outputs inside a vulnerability scale built for exploitability.

Related resources from NHI Mgmt Group

• Guide: CVSS v4 Guide
• How should organisations prioritise fixes for AI agent security findings?
• Should organisations let AI write remediation code directly from security findings?
• How should security teams use an AI trust score in production governance?
• How should security teams evaluate whether legacy email security is still fit for AI-driven attacks?