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

Why This Matters for Security Teams

CVSS is designed to describe technical software vulnerabilities, so it works well when a finding maps to a clear exploit path. AI findings often do not. A model may generate unsafe advice, leak sensitive context, or violate policy without exposing a traditional vulnerability chain. That is why teams need a separate scoring method that measures harmful behaviour, likely exposure, and business consequence instead of forcing every issue into a vulnerability lens. Current guidance from NIST Cybersecurity Framework 2.0 supports outcome-driven risk treatment, which fits this problem better than score inflation or guesswork.

The practical risk is not just inaccurate ranking. If unsafe output is scored as low severity because it is not exploitable in the usual sense, it may be deferred, accepted, or buried among routine bugs. That creates governance blind spots for AI safety, privacy, fraud, and compliance. Security teams also need to distinguish between model defects, prompt injection exposure, and downstream process harm, because those are managed differently. In practice, many security teams encounter the real impact only after an unsafe answer has already reached users, auditors, or production workflows, rather than through intentional AI risk scoring.

How It Works in Practice

A workable approach is to score AI findings with an outcome-based model that preserves technical detail while adding business context. Start by classifying the finding: is it a model behaviour issue, an application integration issue, a data exposure issue, or a control failure around access and oversight? Then assign a rating using factors that describe the harm, not just the defect. The most useful dimensions are exposure, repeatability, scope, user impact, and worst-case regulatory or operational consequence.

For example, a model that occasionally gives a wrong answer in a low-stakes sandbox should not score the same as a system that repeatedly reveals customer data, approves disallowed content, or enables policy bypass in a production workflow. Teams often pair this with a simple scale such as low, moderate, high, and critical, but the label matters less than the definitions behind it. NIST’s AI guidance, including the AI Risk Management Framework, is useful here because it treats risk as a function of likelihood and impact across the AI lifecycle rather than as a software-only defect score.

• Score who is exposed: internal tester, customer, regulated user, or public audience.
• Score what the model did: hallucination, policy breach, disclosure, manipulation, or unsafe instruction.
• Score how repeatable it is: one-off, intermittent, or reliably triggered.
• Score worst-case impact: privacy loss, financial loss, compliance breach, or safety harm.

Teams should also tag whether the issue can be triggered through prompt injection, poisoned context, weak output filtering, or inadequate human review, because those tags help route remediation to the right owners. The scoring model should be documented in the AI risk register and used consistently across product, security, legal, and model governance functions. These controls tend to break down when organisations mix experimental models, fast-moving prompts, and loosely governed integrations because the same finding can behave differently in each deployment path.

Common Variations and Edge Cases

Tighter scoring often increases process overhead, requiring organisations to balance consistent triage against speed of delivery. That tradeoff becomes sharper when AI is embedded in multiple products, because a single model issue may have different severity depending on the workflow, user population, and downstream automation. Best practice is evolving, and there is no universal standard for this yet, so teams should treat their scale as a governance instrument rather than a compliance checkbox.

One common edge case is a finding that is technically low risk but legally or operationally serious. A harmless-looking prompt leak may still expose regulated data, or an output quality issue may become critical if it drives customer decisions. Another is the opposite: a dramatic-looking model failure that occurs only in a lab condition and cannot be triggered in production. That is why AI scoring should separate inherent model behaviour from realised business harm. Where agentic AI is involved, the score should also reflect tool access and execution authority, because a small output issue can become a larger incident once the agent can act on the result.

For teams building governance around this, the OWASP Top 10 for Large Language Model Applications is useful for categorising common failure patterns, while the MITRE ATLAS knowledge base helps map adversarial techniques that may influence how repeatable or exploitable a finding really is.

Related resources from NHI Mgmt Group

• 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?
• How should security teams score vulnerabilities in agentic AI systems?
• How should security teams validate AI-assisted bug bounty findings?