Yes. AI security defects are usually about compromise of the system, data, or permissions and can often be scored with CVSS. AI safety outcomes are about the harm the model or workflow produces, so organisations need a separate severity model that captures business impact, audience, and regulatory exposure.
Why AI safety scores need a different severity model
AI security defects and AI safety outcomes fail in different ways, so they should not be forced into the same severity scale. Security defects are about unauthorized access, compromise, or misuse of the system. Safety outcomes are about the model or workflow producing harmful, misleading, discriminatory, or non-compliant outputs even when no attacker is present. That makes business impact the primary yardstick, not just exploitability.
Once you separate those categories, the scoring logic becomes clearer. A credential leak, privilege bypass, or exposed endpoint can often be assessed as a security event with established control language, while a harmful recommendation, false refusal, or unsafe automation result needs a severity model that accounts for audience, decision criticality, and whether the output reaches regulated or high-stakes use cases. This is where NIST AI Risk Management Framework is useful as a governance reference, because it treats AI risk as broader than pure system compromise.
Severity also changes with context. The same model defect can be low severity in a sandbox and high severity in a customer-facing or operational workflow. A harmful output that influences health, finance, employment, or safety decisions has different consequences from a broken prompt filter or a noisy false positive. Organisations that use one score for both classes usually understate one problem and overstate the other.
How security defects and safety harms should be separated operationally
Security scoring should answer, “Can an attacker break the system, steal secrets, expand privileges, or alter execution?” Safety scoring should answer, “What harm can the model cause when it behaves as designed or when a workflow amplifies its output?” Those are related, but they are not the same decision. A good program keeps a security severity scale for compromise and a safety severity scale for harmful outcomes, then relates them only where they overlap.
That separation is especially important when the issue is an AI workflow rather than the model alone. An unsafe output that reaches an autonomous action path can become a much larger problem than the text itself, because downstream tooling can turn a bad recommendation into a real-world action. For agentic systems, the control question is not only whether the model is accurate, but whether its authority, tool access, and escalation path are bounded. OWASP Agentic AI Top 10 is a useful companion here because it distinguishes identity, privilege, tool misuse, and other agent-specific failure modes that can turn one defect into a larger incident.
Organisations should also avoid scoring safety issues as if they were just content-quality bugs. A model that gives an incorrect answer in a casual setting is not equal to a model that gives a wrong instruction in a regulated process, signs off the wrong transaction, or suppresses a required warning. Severity should therefore include the business process, the affected population, and the degree to which humans can still detect and override the output.
What a practical scoring model should measure
In practice, the scoring rubric should include at least three dimensions: the harm domain, the blast radius, and the reversibility of the outcome. Harm domain asks whether the issue creates misinformation, discrimination, unsafe action, legal exposure, or physical risk. Blast radius asks how many users, decisions, or systems are exposed. Reversibility asks whether the mistake can be corrected before it causes lasting damage.
That model works better than a single vulnerability score because it reflects how AI systems fail in the real world. Security defects tend to be measurable through access paths, exposure, and attack feasibility. Safety outcomes require judgment about who receives the output, what they will do with it, and whether the organisation has a human review step or other containment. Where the workflow handles regulated data or regulated decisions, legal and regulatory exposure can move the severity even when no compromise occurs.
For organisations already using security tooling, the right stance is not to replace CVSS everywhere. It is to reserve CVSS-like scoring for compromise conditions and use a separate rubric for harmful model outcomes. That keeps remediation priorities honest and helps teams avoid the common mistake of treating “no attacker involved” as “low severity.”
Risk and Threat Considerations
When safety outcomes are scored too lightly, organisations may ship a model that is technically secure but still capable of causing operational, legal, or reputational harm at scale. The risk is highest when the model is embedded in customer service, decision support, moderation, or autonomous workflows, because repeated use can multiply a single bad behavior across many users and cases.
Failure mechanism: A security defect enables compromise of credentials, data, prompts, or execution paths; a safety failure produces harmful output or action even without compromise, and the two can reinforce each other when unsafe output is later automated.
Impact: Teams may under-prioritise the wrong issue, leaving a high-consequence safety problem unresolved while spending effort on a lower-impact technical defect, or vice versa. In regulated or public-facing settings, that can translate into customer harm, audit findings, or regulatory scrutiny.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Agentic AI Top 10 addresses the attack and risk surface, while NIST AI RMF and NIST SP 800-53 Rev 5 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST AI RMF | AI Risk Management Framework | AI safety severity depends on harm, context, and governance, which AIRMF directly structures. |
| Recommendation — Use AI RMF functions to score harmful output by context, impact, and governance consequences. | ||
| OWASP Agentic AI Top 10 | ASI03 — Identity & Privilege Abuse | Agent authority and privilege can convert a safety defect into an execution-impact incident. |
| ASI02 — Tool Misuse | Unsafe workflow outcomes often arise when an agent uses tools incorrectly or too broadly. | |
| Recommendation — Bound agent authority and score any output that can trigger privileged actions as higher severity. Assess tool reach and constrain any workflow where bad output could drive harmful tool use. | ||
| NIST SP 800-53 Rev 5 | SI-2 — Flaw Remediation | Security defects still need conventional remediation and prioritisation as compromise risks. |
| Recommendation — Triage and remediate compromise-prone defects using normal vulnerability management discipline. | ||
Practitioner Guidance
What to prioritise: Separate the intake path. Route compromise, privilege, and exposure issues through security triage, and route harmful-output issues through a safety severity model that includes audience, decision criticality, and downstream actionability.
What to verify: Confirm that each finding records both the technical defect and the business consequence. If the defect is security-related, verify exploit path and access impact. If it is safety-related, verify who sees the output, whether it can trigger action, and whether human review can intercept it.
Common mistake: Do not let a low exploitability score hide a high-impact harmful outcome, and do not let an alarming safety narrative inflate a simple security bug that has no realistic path to compromise.
Practitioner takeaway: The best scoring model is dual-track, because AI systems can fail through both compromise and harmful behavior, and the remediation priority changes materially depending on which one is driving the risk.
Related resources from NHI Mgmt Group
- Why is single-provider AI agent governance not enough for enterprise security?
- How should security teams handle risks from AI browser extensions?
- How should security teams govern API keys used for generative AI access?
- How do security AI and automation change breach outcomes when organisations are facing AI-powered cybercrime?