AI safety findings need outcome-based scoring, not CVSS alone

At a glance

What this is: This is INTIGRITI’s analysis of where CVSS still works for AI security and where AI safety requires a different, outcome-based severity model.

Why it matters: It matters to IAM and security practitioners because AI systems increasingly sit inside identity, access, and workflow decisions, where harm can arise even when no classical vulnerability is present.

👉 Read INTIGRITI's analysis of why AI safety findings need outcome-based scoring

Context

AI security and AI safety are often discussed together, but they do not fail in the same way. CVSS remains useful when the issue is a technical vulnerability that affects confidentiality, integrity, or availability, yet it becomes less useful when the concern is harmful model behaviour, unsafe tool use, or business impact tied to context rather than exploit mechanics. The first step for practitioners is separating system security from outcome harm.

That distinction matters for identity and access programmes because many AI workflows now rely on credentials, delegated access, and tool permissions to operate. Once an AI system can call tools, retrieve data, or act inside business workflows, governance must account for both technical compromise and harmful but technically permitted behaviour. That is why AI scoring and identity control need to be considered together, not as separate programme silos.

Key questions

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. The score should reflect who is exposed, what the model did, how repeatable the behaviour is, and what the worst-case business or regulatory impact would be. That prevents unsafe outputs from being misclassified as low risk simply because they are not exploit chains.

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. AI safety issues can create harm without a traditional exploit, such as misleading advice, biased content, or policy-violating responses. Because the harm is contextual, the severity model must account for brand, user, and regulatory exposure rather than only exploit mechanics.

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. That mistake pushes attention toward speculative defenses instead of scoped access, strong telemetry, and response readiness. The operational risk is already here, even if full autonomy is not.

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.

Technical breakdown

Why CVSS still fits AI security vulnerabilities

CVSS remains appropriate when the finding is a conventional technical weakness in an AI system. If a prompt injection causes a chatbot to call an order lookup tool and return another customer’s data, the issue is still an access-control failure with confidentiality impact. The weakness can be described in exploitability, impact, and environmental terms just like other software defects. The key is to judge whether the finding maps to a technical vulnerability, not whether the affected system happens to use AI.

Practical implication: score AI system flaws that expose data, privilege, or execution paths with existing vulnerability processes.

Why AI safety outcomes break standard severity models

AI safety findings can be harmful even when no classical security control is bypassed. A model that produces hateful, misleading, biased, or policy-violating content may create reputational, regulatory, or user harm without touching CIA properties in a direct technical sense. CVSS was not designed to rank harm categories like brand damage or customer trust erosion. For these cases, severity must reflect the real-world consequences of the output, the audience exposed to it, and the likelihood of repeatability.

Practical implication: create a separate severity path for harmful outputs, unsafe recommendations, and policy violations.

Why deployment context changes the score

The same AI behaviour can carry very different risk depending on where it appears. Offensive or hateful output in a public children’s product has a different exposure profile from the same output inside an internal workflow. That context includes audience, regulation, sector sensitivity, and the customer’s worst-case business harm. Outcome-based scoring therefore has to be co-designed with the operating environment rather than treated as a universal number.

Practical implication: calibrate severity to the business setting, not just the model defect.

Threat narrative

Attacker objective: The objective is to induce harmful AI behaviour or misuse tool access in a way that creates business, regulatory, or user harm.

1. Entry occurs when an attacker or tester reaches an AI-enabled workflow that can call tools or process prompts without sufficient controls.
2. Escalation happens if prompt injection or unsafe delegation lets the system use authorised tools in ways the business did not intend.
3. Impact follows when the AI produces harmful, misleading, or policy-violating outcomes that damage trust, regulatory standing, or operations.

NHI Mgmt Group analysis

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.

AI safety exposes a control gap that identity teams cannot ignore: authorised does not mean safe. An AI system may be fully authenticated, properly issued credentials, and still produce damaging output or take an unwanted action inside a permitted toolchain. That is the governance problem here. The intersection with IAM and NHI is direct because delegated access, service accounts, and tool credentials expand what AI systems can do, but not necessarily what they should do.

Context-sensitive severity is the right named concept for this class of risk. The same model behaviour can move from nuisance to reportable incident depending on who sees it and where it appears. That means the scoring model must encode sector, audience, and regulatory exposure. Practitioners should stop assuming a single universal severity score can describe AI harm across business lines.

Exploit elegance should never outrank real-world harm in AI safety reviews. A clever jailbreak that looks impressive but causes no meaningful exposure is less important than a blunt prompt that crosses a high-impact boundary. This shifts prioritisation away from technical novelty and toward consequences. Teams should reward findings that demonstrate repeatable, material harm.

AI governance is converging with access governance. As AI systems gain tool use, retrieval, and delegated execution, scoring cannot live only in model-risk workflows. Identity governance, privilege boundaries, and workflow authorisation become part of the risk score itself. Practitioners should align AI safety review with IAM and PAM controls before harmful actions become routine.

What this signals

Context-sensitive severity is the concept practitioners should carry forward from this discussion. AI risk programmes will keep failing if they treat every harmful output as either a pure security issue or a pure safety issue. The more AI systems connect to tools and delegated identities, the more severity scoring has to reflect both technical control failure and downstream harm.

For identity teams, the practical signal is that access governance now extends into model behaviour. If an AI workflow can act through a service account or delegated token, the permission boundary becomes part of the safety boundary. That makes lifecycle control, scope review, and auditability relevant to AI governance even when the original issue looks like a content problem.

For practitioners

• 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. Make the decision rule explicit so triage does not collapse both classes into one score.
• Calibrate severity to business context Define worst-case harm by audience, sector, and regulatory exposure. A model defect in a public-facing product, a regulated workflow, or an internal assistant should not receive the same business severity if the downstream harm differs materially.
• Treat tool permissions as part of AI safety Review the credentials, scopes, and delegated actions available to AI-enabled workflows. If an agent or chatbot can call tools, its safety profile depends on the permissions attached to that runtime identity as much as on the model itself.
• Build a separate review path for harmful content Create an intake route for findings that do not map cleanly to CIA but still create customer harm. Include legal, product, trust and safety, and security stakeholders so the severity decision reflects actual exposure rather than exploit cleverness.

Key takeaways

• AI security flaws can often be scored with CVSS, but AI safety harms need a separate severity model grounded in business context.
• The biggest mistake is treating harmful output as low risk just because it does not resemble a classic exploit chain.
• Identity, permissions, and delegated tool access are now part of AI safety governance because authorised actions can still produce unsafe outcomes.

Key terms

• AI Safety: AI safety is the discipline of preventing an AI system from taking unintended or harmful actions on its own. It focuses on the behaviour the system generates, even when no external attacker is involved. For identity teams, safety is about limiting what the agent can do once it is already operating.
• AI security by design: AI security by design means building security, privacy, and access controls into AI systems from the start instead of adding them after deployment. In practice, it combines data governance, human oversight, documentation, and continuous monitoring so that model behaviour is auditable and bounded.
• Outcome-Based Scoring: Outcome-based scoring ranks AI findings by the real-world harm they can cause, not by exploit cleverness alone. It accounts for audience, sector, regulatory exposure, repeatability, and worst-case business impact, which makes it better suited to safety issues than a pure technical metric.
• Contextual Severity: Contextual severity is a risk-ranking approach that judges findings by their real exposure, not just by how many sensitive records are present. It combines content, access, lifecycle, and business relevance so teams can focus on what could actually cause harm.

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.

👉 INTIGRITI's full article breaks down where CVSS still applies and where custom AI safety severity tables are needed.

Deepen your knowledge

NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security, and secrets management. It helps practitioners align identity controls with the broader security and governance work their programmes depend on.