Scoring the risk of AI agents and large language models is one of the hardest problems in vulnerability management right now. CVE-based methods were not built for it, and a wave of new AI risk scoring frameworks is trying to fill the gap.
In a previous post, we covered how CVEs are becoming a trailing indicator and walked through 20 years of CVE enrichment, from the Common Vulnerability Scoring System (CVSS) to the NIST Likely Exploited Vulnerabilities (LEV) metric. Each step added enrichment on top of an existing vulnerability, searching for the metric that best tells organizations which CVEs are most urgent or impactful if left unpatched. The conclusion: absent runtime telemetry, too many CVEs are published for any organization to patch or mitigate them all, let alone the unknowns that exist before a CVE is ever published.
Then AI arrived in the enterprise. By this point in 2026, most organizations have adopted AI in some form, from the "anything goes" crowd to teams blocking anything that resembles AI. Whatever the risk appetite, compliance teams are trying to classify the risk while security teams face an expanding attack surface that is harder to assess and protect. Traditional vulnerability assessment was not built to classify these risks. Accurate AI risk scoring depends on what a given agent or tool can do and what it can access, not just whether a CVE is present. Can the new frameworks close the gap, or will they widen it?
This post looks at newly introduced frameworks, scoring methods, and policy guidance built specifically for AI risk. We focus on OWASP AIVSS, MITRE ATLAS, and OWASP's newer Top 10 for AI agents. For each, we outline the core mechanics, then give our view on where AI vulnerability and risk scoring is heading and why runtime exposure management matters more now than ever.
Traditional scoring rates a flaw in isolation, but the risk of an AI agent depends on its abilities and access in a specific environment. The way the industry scores vulnerabilities and classifies attacker tactics does not line up with how AI agents and LLMs operate. That gap is why several new frameworks and hypothesis-driven scoring models have appeared, each trying to classify and prioritize these risks.
OWASP AIVSS (AI Vulnerability Scoring System) is an open framework that adapts CVSS to the dynamic risks of AI agents and large language models. It combines a published CVE's CVSS v4.0 base score with an Agentic AI Risk Score (AARS), a threat multiplier, and a mitigation factor, so the final severity reflects what an AI agent can actually do and access in a specific environment. AIVSS is early-stage software, at version 0.8 as of mid-2026.
CVSS is still the primary way to rate the severity of a given CVE, and even the current version 4.0 does not account for the dynamic nature of AI agents and LLMs. The risk of a vulnerability tied to an agent depends on that agent's abilities and access in each environment, not just on the presence of a CVE. That reality, plus new requirements to assess AI risk such as the NIST AI Risk Management Framework (AI RMF), is what led OWASP to introduce AIVSS.
Like every iterative change to CVE scoring before it, AIVSS depends on the existence of a published CVE and an associated CVSS v4.0 score. One distinction sets it apart: it leaves the AI-specific calculation to the organization, which makes it one of the few methods focused on individualized risk. That stands in contrast to EPSS, NIST LEV, and the various known-exploited-vulnerability lists, which assign static prioritization at a much broader level.
An AIVSS score builds on the CVSS base in three moves. First, the technical baseline: the CVSS v4.0 base score (0.0 to 10.0) sets the floor. Second, the agentic amplification: each of ten Risk Amplification Factors is scored 0.0, 0.5, or 1.0, and the Factor Sum (0 to 10) captures how much capability the agent adds. Third, threat and mitigation status adjust the result. The Agentic AI Risk Score (AARS) is the AI-specific uplift:
AARS = (10 − CVSS Base) × (Factor Sum ÷ 10) × Threat Multiplier
AIVSS = (CVSS Base + AARS) × Mitigation Factor
The Threat Multiplier (ThM) reflects the status of the vulnerability: Attacked (1.00), Proof-of-Concept (0.97), or Unreported (0.50). The Mitigation Factor reflects the state of any mitigation: None or Weak (1.00), Partial (0.83), or Strong (0.67). AIVSS then maps to four severity bands: Low (0.1 to 3.9), Medium (4.0 to 6.9), High (7.0 to 8.9), and Critical (9.0 to 10.0).
The ten Risk Amplification Factors that make up the Factor Sum:
These amplification factors are what AIVSS applies to the threats it catalogs separately as the Agentic AI Core Security Risks, such as tool misuse, access-control violations, memory and context manipulation, and goal or instruction manipulation. That Core Security Risks catalog is a different list from OWASP's newer Top 10 for Agentic Applications (ASI01 to ASI10), so the two should not be confused.
In this example, a CVE that started at 6.0 lands at an AIVSS score of 7.2 (High) once agentic capability, threat status, and partial mitigation are applied. To make the math easier, OWASP provides an AIVSS-SSVC calculator that also incorporates Stakeholder-Specific Vulnerability Categorization (SSVC) outcomes.
Based on the relationships in the AIVSS reference documentation, the intended workflow for putting the framework into practice looks like this:
MITRE ATT&CK (Adversarial Tactics, Techniques, and Common Knowledge) catalogs real-world attacker behaviors to help organizations identify, detect, and defend against threats. The knowledge base is organized into Tactics, Techniques, Defenses (mitigations, assets, detections), and cyber threat intelligence (groups, software, campaigns).
MITRE ATLAS (Adversarial Threat Landscape for Artificial-Intelligence Systems) is a knowledge base that uses the same tactics-and-techniques structure as ATT&CK but focuses on threats to AI and machine learning systems. Where the two overlap, ATLAS links back to the relevant ATT&CK reference for added context. For example, the ATLAS tactic AML.TA0002 (Reconnaissance) references the Enterprise ATT&CK tactic TA0043 (Reconnaissance).
OWASP has long been known for its "Top 10" risk lists. These are informed by several inputs, mainly threat models and expert review. For the newer AI lists, OWASP leans heavily on a reference architecture and a base threat model. On methodology, the project states plainly: "we do not follow a specific methodology, but we focus on the use of our reference architecture to identify and explain threats, their attack scenarios, relationship to applicable LLM." Informed threat modeling is a good start and a useful reference when you are reasoning through potential risks, but at its core it is still hypothetical and subjective.
The three frameworks are not equally ready to use. The table below summarizes where each one stands and how we treat it today.
We are always assessing the most effective ways to represent risk from telemetry and the runtime exposure management views we provide to customers. That means tuning and building detections, and also representing risk the way the industry does, so teams have a common language for AI-related risk whether they use our data directly or feed it into other systems and reports. For that reason, we already use MITRE ATLAS and the OWASP Top 10 to categorize AI-related detections. Here is an example of an AI-related detection inside Spektion:
In its current form, we do not believe most organizations can put AIVSS to effective use. The prerequisites it lists set a high barrier to entry:
On top of that, an organization needs a well-defined, AI-focused threat model to identify the risks in its own environment. For that, OWASP recommends the CSA MAESTRO framework, which carries its own set of prerequisites and expertise before it becomes useful.
We expect the only practical users of this scoring model, in its current form, will be the developers building the AI product, not the organizations deploying it. That is a problem, because the organization is the party responsible for the scoring amplifiers. Without that input, the model cannot do what it set out to do: make CVSS v4.0 more tailored to AI risks and vulnerabilities.
We do not believe the release cadence of modern AI tools will scale to the calculations the model requires. AIVSS recommends a reassessment "whenever changes occur that may alter the system's risk profile." An internal team would need to know when those changes happen and what they are, then complete the scoring calculation in line with its own prioritization policy. We have already seen how well that scales with standard CVSS scoring, and we are not confident most organizations can implement the scoring rationale this framework needs.
As an example, we compared the release cadence of two prominent AI tools against two applications in a category long viewed as fast-moving: web browsers.
Source: public release notes for each product, counted by Spektion as of July 2026.
If we assume, for the sake of argument, that 3 of every 100 of Codex's 555 releases carried a substantive change that required an AIVSS reassessment, an organization would have re-scored a single vulnerability at least 15 times in six months. Between the barrier to entry and this cadence problem, we are not using AIVSS for AI vulnerabilities today.
The new AI risk frameworks are not equally ready to use. MITRE ATLAS and the OWASP Agentic and LLM Top 10 are practical today and fit into existing security workflows, and we already use both to categorize AI-related detections. OWASP AIVSS is a promising step toward scoring what an AI agent can actually do, but in its current form it carries a high barrier to entry and is difficult to keep current against the release cadence of modern AI tools, so most organizations cannot yet operationalize it.
The industry is still working out how to express the risk a vulnerability represents once AI agents and LLMs are involved. Some of this work is easy to fold into existing workflows, such as the OWASP Top 10 and MITRE ATLAS. Other parts carry a high barrier to entry that keeps teams from using them outside the strategies laid out in the source documentation.
It is a good sign that the industry is starting to recognize that knowing how something operates matters more than knowing a given piece of software is present. We take that a step further by surfacing insecure AI agent behavior and pre-CVE weaknesses from runtime telemetry, before a vulnerability is ever published.
Spektion is a runtime exposure management company. Our sensor detects vulnerable and exploitable software behavior, including insecure AI agent activity and pre-CVE weaknesses, from runtime telemetry across your endpoints.
Many exploitable weaknesses never get a CVE. Book a runtime exposure assessment and Spektion will show what's actually exploitable across your endpoints.
