Notifications
Clear all
Topic starter
18/08/2026 2:19 pm
TL;DR: AI security findings can often still be scored with CVSS, but AI safety issues such as harmful outputs, unsafe tool use, and policy-violating behaviour need customer-specific, outcome-based severity models, according to INTIGRITI. The article argues that context, worst-case harm, and regulatory exposure matter more than exploit elegance when prioritising what to fix first.
NHIMG editorial — based on content published by INTIGRITI: Beyond CVSS: rethinking scoring systems amidst AI Safety and Security
Questions worth separating out
Q: How should security teams score AI findings that do not fit CVSS?
A: Use CVSS for technical vulnerabilities and a separate outcome-based model for harmful behaviour, policy violations, or user harm.
Q: Why do AI safety issues need different treatment from AI security vulnerabilities?
A: AI security vulnerabilities usually affect confidentiality, integrity, or availability through a technical flaw.
Q: What do organisations get wrong about AI-driven cyber risk?
A: They often assume the main change is autonomous attackers, when the immediate change is faster and more variable abuse of existing identity pathways.
Practitioner guidance
- Separate AI security from AI safety scoring Keep CVSS for defects that map to technical compromise, but add a distinct severity model for harmful outputs, unsafe recommendations, and policy violations.
- Calibrate severity to business context Define worst-case harm by audience, sector, and regulatory exposure.
- Treat tool permissions as part of AI safety Review the credentials, scopes, and delegated actions available to AI-enabled workflows.
What's in the full article
INTIGRITI's full article covers the operational detail this post intentionally leaves for the source:
- The article explains how CVSS v4.0 handles exploitability and environmental metrics for AI security findings.
- It contrasts technical vulnerabilities with harmful AI behaviour that needs customer-specific outcome scoring.
- It gives concrete examples of when brand damage, regulatory exposure, or user harm should drive severity.
- It discusses why choosing the right worst-case scenario matters when building a custom scoring table.
👉 Read INTIGRITI's analysis of why AI safety findings need outcome-based scoring →
AI safety scoring gaps: what security teams are missing?
Explore further
18/08/2026 3:11 pm
Outcome-based scoring is now a governance requirement, not a nice-to-have. CVSS still has value for AI security defects, but it fails when the risk is harmful model behaviour rather than technical compromise. Security leaders need a separate severity model for AI safety that reflects audience, context, and worst-case harm. That should be treated as part of control governance, not as an afterthought in triage.
A question worth separating out:
Q: Who should own AI safety severity decisions in regulated environments?
A: Security should not own them alone. The right decision often needs security, product, legal, compliance, and trust and safety input because the risk may be regulatory, reputational, or customer-facing rather than purely technical. Shared ownership keeps severity aligned to actual operational harm and accountability.
👉 Read our full editorial: AI safety findings need outcome-based scoring, not CVSS alone
