Unified Scoring Workflows That Reconcile OWASP LLM Top 10 Controls With NIST AI RMF Govern Map Measure and Manage Functions

Unified scoring bridges two frameworks that separately leave teams without a single risk assessment.

· 9 min read
Cover illustration for “Unified Scoring Workflows That Reconcile OWASP LLM Top 10 Controls With NIST AI RMF Govern Map Measure and Manage Functions”
Evaluation Criteria · October 25, 2026 · 9 min read · 2,023 words

AI vendor risk assessment mapped to OWASP LLM Top 10 and NIST AI RMF needs a shared evidence trail. A unified scoring workflow assigns each OWASP control to the Govern, Map, Measure, or Manage function where it produces evidence, then uses that evidence to score residual risk and direct action. Continuous monitoring keeps the assessment tied to how the system behaves in production.

Why two frameworks that both claim to govern LLM risk still leave teams with two separate audit trails

A team can finish its NIST governance work and its OWASP security review and still struggle to give an auditor a single risk score that makes sense. Its AI inventory and risk register describe accountability and organizational exposure. Its engineering records track prompt injection and supply chain weaknesses. Both contain useful evidence, but neither explains how a technical finding changes the organization’s risk decision.

The disconnect starts with the questions being asked. NIST AI Risk Management Framework (AI RMF 1.0, January 2023) is voluntary and organizes how an enterprise governs AI risk. OWASP LLM Top 10 identifies attack patterns and mitigations at the vulnerability layer. NIST specifies no prescriptive runtime controls, while OWASP supplies no enterprise process for prioritizing, tracking, or escalating findings. To join their records, teams therefore need a rule for how technical evidence feeds into governance decisions, since completing the frameworks does not prove a system is safe.

What each NIST AI RMF function actually asks a team to produce

Govern establishes organizational accountability, roles, policies, and culture for AI risk. Its outputs include ownership decisions, escalation paths, and acceptable-risk thresholds. It spans the organization. Map uses that policy for each AI system to record what it is for, its context, its stakeholders, and the risks that come with it. Together, these functions establish who answers for risk and what is being assessed.

Measure produces assessments, benchmarks, and monitoring evidence using qualitative and quantitative methods. Its task is to establish risk. Manage then prioritizes responses and documents the actions taken to address identified risks. A requirement belongs in Govern, evidence of its effectiveness belongs in Measure, and a decision to correct its failure belongs in Manage.

NIST’s GenAI Profile (NIST AI 600-1, July 2024) extends the RMF with twelve generative AI risk categories and suggested actions across all four functions. Data Privacy, Information Security, and Value Chain and Component Integration matter most here for the risks they cover in LLM security. The profile provides a more specific screening vocabulary. Its Information Security category mentions logging, access management, and output filtering, but does not prescribe their implementation. A mapping must therefore distinguish the risk being addressed from the evidence that a control works.

What the 2026 OWASP LLM Top 10 actually covers and where it stops

OWASP’s 2026 LLM Top 10, released August 4, 2026, gives votes from the practitioner community roughly three-quarters of the weight and data from real incidents one quarter. It drew on thousands of real-world AI security incidents, most with enough detail to classify. The ranking changes require older mappings to be revisited. Excessive Agency went up from sixth to third, Unbounded Consumption went up four places, and Improper Output Handling went down from fifth to tenth.

LLM01 Prompt Injection covers hostile instructions, while LLM02 Sensitive Information Disclosure covers how sensitive information can be exposed. LLM03 Excessive Agency covers what the system has the authority to do. LLM04 Supply Chain and LLM05 Data and Model Poisoning cover risks that come from components, data, and models. LLM07 Misinformation, LLM09 Vector and Embedding Weaknesses, and LLM10 Improper Output Handling extend the assessment to information reliability, retrieval-related weaknesses, and downstream use of model output.

That scope has a clear boundary. OWASP covers model-layer vulnerabilities in applications and supplies specific attack patterns and mitigations, but no scoring formula or assignment to governance functions. What changes when a model can act? OWASP instructs teams to use the separate Agentic Applications Top 10 when tools, persistent memory, and execution rights turn the model into an actor. The model-layer list remains relevant, but is no longer sufficient.

How the 2026 OWASP Appendix A maps each LLM risk to NIST AI 600-1 categories — and where it leaves gaps

OWASP’s 2026 Appendix A provides a published crosswalk to the GenAI Profile’s risk categories. It maps Prompt Injection and Excessive Agency to Information Security. Sensitive Information Disclosure maps to Data Privacy and Information Security, while Supply Chain maps to Value Chain and Component Integration and Information Security. These are useful connections, but they classify risk. They do not assign work.

The same appendix maps Data and Model Poisoning to Information Integrity, Value Chain and Component Integration, and Information Security. Misinformation maps to Information Integrity, Confabulation, and Human-AI Configuration. Improper Output Handling has no mapping in Appendix A. A team must therefore supply that association itself, while also deciding which function owns each piece of control evidence. Even when a category is mapped, teams still have to decide whether a finding belongs in Map, Measure, Manage, or several functions.

The practical bridge starts with Govern and Map under the core RMF. The profile’s twelve categories then screen for applicable risks, and matching suggested actions feed into Measure and Manage. NIST’s Cybersecurity Framework Profile for Artificial Intelligence (NIST IR 8596), published December 16, 2025, as an initial preliminary draft, offers additional crosswalk material between cybersecurity and AI risk. It does not remove the central distinction. A risk category describes what could go wrong, while an RMF function identifies the work needed to address it.

A step-by-step scoring workflow that assigns each OWASP LLM control to its governing RMF function

To assess an AI supplier through both frameworks, the workflow should assign controls according to where they generate evidence. The first step is Govern. Organization-wide policy should name every OWASP LLM risk category as a required control domain and establish ownership, escalation paths, and acceptable-risk thresholds. These decisions precede system assessment so that severity judgments have an agreed basis.

The second step is Map, which takes place when a system enters intake. For each supplier AI system, the team should screen the profile’s twelve categories and identify the OWASP attack surfaces activated by its architecture. A system that augments generation with retrieved information activates LLM09 Vector and Embedding Weaknesses. An agentic system with tool access activates Excessive Agency and Prompt Injection at elevated severity. Architecture determines applicability, rather than a requirement to score every system identically.

The third step is Measure against four dimensions, namely exposure, control coverage, detection, and residual risk. Exposure records the inputs a system reads, the tools it invokes, and the data it accesses. Control coverage requires verifiable mitigation evidence. For Prompt Injection, that includes keeping credentials out of model context, validating responses, labeling outside inputs by source, and requiring human approval for irreversible actions. Detection assesses logging, monitoring, and alerts, while residual risk expresses the severity remaining after controls and detection are considered.

OWASP’s Agentic AI Vulnerability Scoring System (AIVSS), released at v0.8 ahead of RSAC 2026, offers a numeric option. Its Agentic AI Risk Score formula is AARS = (10 − CVSS Base) × (Factor Sum ÷ 10) × Threat Multiplier. Its final formula is AIVSS = (CVSS Base + AARS) × Mitigation Factor. This is a conditional option. It requires a CVE with a CVSS v4.0 base score and a completed AI threat model.

The fourth step is Manage. For each entry above the Govern threshold, the team should name a remediation owner, set a deadline and retest date, and record the decision and outcome. For the unmapped Improper Output Handling entry, the workflow should assign Measure evidence under Information Security by analogy, assessing whether output is treated as untrusted, encoded for its destination, and passed through parameterized queries. The resulting register has an OWASP entry in each row and an RMF function in each column. Each cell holds evidence or a gap that has been scored.

Where the workflow breaks down in practice and how to handle the gaps

The hardest step is usually Measure. Organizations can write policies, make inventories, and document context even when they lack the infrastructure to benchmark risks in a consistent way. When that infrastructure is missing, assessment stops after Govern and Map. Manage then becomes whatever happens during an incident. Adding more fields to a unified register will not fix this.

AIVSS also has substantial entry barriers at v0.8. A published CVE with a CVSS v4.0 base score, deep system knowledge, and a completed AI threat model are prerequisites most enterprise teams cannot meet for every risk across a vendor portfolio. For teams in that position, qualitative severity tiers of critical, high, medium, and low provide a Measure proxy. Architecture should determine which entries receive priority. The profile’s suggested actions can provide a minimum assessment of whether each action is applicable and implemented.

Evidence quality creates a separate problem. A rubric that rewards model cards and governance documents can score documentation fluency. Full credit should therefore require response-specific evidence. The frameworks do answer different questions, but that does not make their evidence incompatible. The workflow routes vulnerability evidence into the governance process that decides what happens next.

Why agentic deployments require a third tier in the scoring workflow

The Agentic AI Governance Assurance and Trust Engine (AAGATE), published in October 2025, offers a template for the work each function does in agentic systems. It integrates the MAESTRO framework for Map, a hybrid of AIVSS and SEI’s SSVC for Measure, and the Cloud Security Alliance’s Agentic AI Red Teaming Guide for Manage. Its design illustrates the additional layer required. Agent-specific assessment must sit above the model-risk crosswalk.

For that third tier, Map should distinguish a component that reads and returns from an actor that reads, reasons, and executes. Actor deployments should trigger the full agentic risk screen. Measure should assess Excessive Agency by checking both permission scope and whether each tool invocation needs human confirmation for irreversible actions. That confirmation control is present or absent. Manage should require an audit trail for every tool call, attributed to the triggering user identity.

NIST’s Center for AI Standards and Innovation launched the AI Agent Standards Initiative in February 2026 to fill gaps in how agents are governed, including runtime behavior, tool-use risk, and delegation chain accountability. Initial deliverables were projected for late 2026 but remained uncommitted, with finalized standards not expected until 2027 at the earliest. The scoring workflow cannot depend on those future deliverables. For agentic deployments, workflow exposure already requires assessment of who can trigger the system, what it can access, and which safeguards constrain its actions.

How continuous monitoring closes the enforcement gap the static scoring workflow leaves open

A completed crosswalk establishes risk at a point in time. On its own, it cannot show where documented controls differ from how the system behaves in production, and neither framework directly enforces controls on live inference traffic. Monitoring gives teams the feedback they need to see that gap. It does not substitute for control enforcement, but supplies evidence that can change scores and trigger action. Without that feedback, a successful Measure audit can coexist with ungoverned production tool calls.

For teams assessing suppliers in one platform, the relevant capability comparison is therefore between assessment records and ongoing operational evidence. Continuous monitoring should spot Prompt Injection attempts and anomalies in Improper Output Handling as they happen, in real time. Under Supply Chain, vendor AI asset monitoring should track what changes in third-party models, plugins, and connectors. Alerts about new CVEs or OWASP list updates should trigger rescoring when earlier Manage decisions are no longer sound. These capabilities connect technical change to the owners and thresholds already recorded in the register.

For TPRM, InfoSec, Privacy, and Legal teams, this makes monitoring part of supplier oversight. Claims that the RMF is in use need the backing of clear performance thresholds, regular checks on output quality, and a process for incident response. Manage is intended to be ongoing. The practical requirement is to connect emerging evidence to reassessment and response, because an unmonitored scoring crosswalk is only a snapshot of a risk landscape that has already moved.

Sources

  1. NIST Internal Report NIST IR 8596 iprd Cybersecurity Framework Profile for
  2. AI RMF Core - AIRC - NIST AI Resource Center

More in Evaluation Criteria