AI risk scoring and vendor assessment platforms mapped to OWASP LLM Top 10 and NIST AI RMF

Most AI risk and vendor assessment platforms claim framework alignment. The ones that actually deliver it are doing something structurally different from the ones that don't, and the gap between those two groups is wider than most procurement teams realize.

The core issue is this: traditional third-party risk management was built to assess operational, financial, and broad cybersecurity risk. Questionnaires, point-in-time audits, compliance checklists. That architecture was designed for a world where you're trying to understand whether a vendor has a patch management policy or encrypts data at rest. It was never designed to assess whether a vendor's deployed LLM can be manipulated through indirect prompt injection, whether their agentic system is operating with permissions far exceeding what the task requires, or whether their RAG pipeline is vulnerable to embedding poisoning.

Self-attestation measures what a vendor says about themselves. It does not measure observable AI behavior. And vendor ecosystems are expanding quickly enough, with each new model, plugin, agent, and connector adding to the attack surface, that the gap between what questionnaires capture and what is actually happening in production keeps widening. The uncomfortable operational consequence is that an organization can satisfy every documentation requirement in the NIST AI Risk Management Framework without deploying a single runtime control. The RMF's voluntary, governance-layer nature makes that entirely possible. Understanding why requires understanding what these two frameworks actually cover.

What OWASP LLM Top 10 Actually Covers and Why the 2025 List Is the Relevant Baseline

OWASP's LLM Top 10 is not a certification and not a compliance standard. Its value is more fundamental than either: it's a shared, named vocabulary for AI security risk. When two security engineers in different organizations talk about LLM01, they mean the same thing. That common language is what makes the list useful for vendor assessments, where you need a consistent, auditable basis for comparison.

The current baseline is the 2025 edition, version 2.0, published in November 2024. If you're working from the original list, you're assessing against a threat model that predates production-scale RAG systems and autonomous agents. Two entirely new categories were added. Five existing categories were renamed and expanded. The full list was reprioritized. Two prior categories were removed. The list now lives within the broader OWASP GenAI Security Project, which explicitly covers LLMs, agentic AI, and AI-driven applications as a unified surface.

Here's what the ten categories actually represent when you're assessing vendor AI deployments. LLM01, Prompt Injection, holds the top position. Both direct and indirect variants matter; indirect injection, where malicious instructions are embedded in documents or external data sources a model retrieves, is the variant most commonly underestimated in vendor assessments. LLM02, Sensitive Information Disclosure, moved from sixth to second in the 2025 ranking. It covers PII, intellectual property, and proprietary algorithm exposure through model outputs. The upward movement reflects how frequently this category surfaces in practice. LLM03, Supply Chain, addresses the risks introduced by third-party model components, pre-trained weights, and data pipelines, which is precisely where most enterprise vendor relationships introduce AI risk without anyone explicitly deciding to accept it.

LLM04, Data and Model Poisoning, covers corruption of training or fine-tuning data to manipulate model behavior. LLM05, Improper Output Handling, addresses downstream systems consuming LLM output without validation, a problem that compounds quickly in multi-step agent workflows. LLM06, Excessive Agency, is broken into three root causes: excessive functionality, excessive permissions, and excessive autonomy. These are the three failure modes that allow agentic systems to cause harm beyond their intended scope.

The two new 2025 additions are worth specific attention. LLM07, System Prompt Leakage, covers the exposure of confidential system-level instructions through adversarial inputs. LLM08, Vector and Embedding Weaknesses, targets RAG pipelines and embedding-based retrieval through data injection or embedding poisoning. Their addition isn't theoretical; it reflects the fact that RAG systems and autonomous agents are now mainstream production deployments, not experiments.

LLM09, Misinformation, addresses model-generated false outputs presented as factual. LLM10, Unbounded Consumption, covers uncontrolled resource use enabling denial of service or financial exploitation, a category amplified significantly in pay-per-use cloud environments.

LLM02 and LLM04 surface most frequently in Map and Measure gap analysis, and the reason is consistent: they connect directly to undocumented data access boundaries and unmonitored training or feedback pipelines. Most vendors can't readily document what data their model was trained on, how their feedback loops work, or what the retrieval boundaries of their RAG system actually are. That's not evasion; it's a genuine visibility problem. But it's exactly the visibility problem a platform needs to surface.

How the NIST AI RMF Structures What Platforms Must Govern

The AI RMF's four functions, Govern, Map, Measure, and Manage, form an accountability loop. The test for any platform isn't whether it mentions the RMF in its marketing. The test is whether it produces evidence that closes that loop.

Govern covers policies, roles, and organizational accountability for AI risk. Map is about identifying AI systems, their contexts, and the risks they introduce. Measure is quantifying and evaluating those risks through testing, scoring, and monitoring. Manage is treating risks through controls, mitigations, and ongoing oversight. Each function depends on the ones before it; a program that's strong on Govern documentation but thin on Measure produces well-organized ignorance.

The operationally relevant companion document is NIST AI 600-1, the Generative AI Profile, published in July 2024. The base RMF is deliberately high-level. AI 600-1 names twelve specific risk areas, including Data Privacy, Information Security, Confabulation, and Value Chain and Component Integration, and provides more than two hundred suggested actions organized by RMF function. That's a substantially more actionable document than the base framework. It explicitly calls for third-party model and supply chain risk assessment: model cards, system cards, training data provenance. For vendor assessments, AI 600-1 is where the rubber meets the road.

The voluntary nature of the framework is both its strength and its structural weakness. Organizations can satisfy the RMF entirely through documentation without deploying runtime controls. That gap is not a flaw in the framework's design; the RMF was never intended to be a prescriptive technical standard. But it means that purpose-built AI risk platforms have a specific job: turning governance documentation into observable, continuously monitored controls. Without that translation layer, you have a well-documented risk program that doesn't actually know what's happening in the systems it governs.

Regulatory gravitational pull is already bending procurement behavior even without a legal mandate. Federal agencies operating under OMB M-24-10 use the GenAI Profile as their reference architecture. Enterprise procurement teams and auditors cite it in vendor questionnaires and SOC 2 scoping calls. The framework's de facto authority in enterprise contexts is real, even where its legal authority is limited.

There is a genuine gap in the current framework around agentic systems. The RMF and AI 600-1 were conceived before autonomous, tool-using agents became production systems. Neither document fully addresses agent autonomy, delegation chains, or runtime behavioral governance. The Cloud Security Alliance's proposed NIST AI RMF Agentic Profile, aligned with CSA's AI Controls Matrix and published in mid-2025, is a supplement, not a replacement; it signals where the framework will need to extend as agentic deployments scale.

How OWASP and NIST Fit Together — and What Sits Alongside Them

These two frameworks operate at different layers and serve different audiences, which is why treating them as alternatives is a category error.

The NIST AI RMF is the governance and accountability loop, designed for risk, compliance, and AI leadership teams who need to demonstrate organizational accountability for AI risk. OWASP LLM Top 10 is the named-risk and technical evidence layer, designed for security engineers, developers, and assessors who need to populate that governance loop with real findings. In a complete program, NIST provides the structure; OWASP provides the evidence.

The mapping between them is specific and practically useful. Sensitive Information Disclosure (LLM02) and Data and Model Poisoning (LLM04) connect directly to Map and Measure gaps in the RMF. Prompt Injection findings (LLM01) feed into Manage-function controls and incident response. Supply Chain risks (LLM03) map to AI 600-1's Value Chain and Component Integration risk area almost exactly. The frameworks weren't designed in coordination, but they interlock in practice.

A mature program also draws on three additional frameworks, each serving a distinct purpose. MITRE ATLAS, at version 5.1.0 as of November 2025, provides threat modeling and red teaming infrastructure with sixteen tactics and eighty-four techniques, including two AI-specific tactic additions not present in ATT&CK and new techniques addressing agentic AI. ISO/IEC 42001 provides external verification and management system certification for organizations that need third-party attestation of their AI governance posture. The EU AI Act, particularly Articles 9 and 15 on risk management, cybersecurity, and robustness, creates legal obligations for which OWASP findings serve as technical evidence; that relationship makes OWASP documentation directly relevant to regulatory compliance for any organization in scope.

The practical implication for platform evaluation is clear: a tool that covers only one layer, whether NIST governance documentation without OWASP-level detection, or OWASP scanning without governance workflow support, leaves the program incomplete on both sides. The two frameworks need each other to be operationally useful.

The Capabilities That Determine Whether a Platform Genuinely Covers the OWASP Categories

The distinction that actually separates purpose-built tools from checklist overlays is this: citing a framework versus detecting the risks it names. Those are not the same thing, and the difference becomes obvious the moment you ask a vendor to show you evidence rather than documentation.

What real coverage of each major category requires is more specific than most platform evaluations acknowledge. For LLM01, Prompt Injection, real coverage requires active testing against both direct and indirect injection vectors. A policy field stating that the vendor monitors for prompt injection is not coverage. For LLM02, Sensitive Information Disclosure, it means runtime monitoring of model outputs for PII, intellectual property, and proprietary data patterns, not a vendor self-attestation checkbox. For LLM03, Supply Chain, it means provenance tracking of model components, pre-trained weights, and third-party plugins, combined with model card and system card review against AI 600-1 requirements. Self-reported questionnaire responses don't get you there.

LLM04, Data and Model Poisoning, requires assessment of training data pipeline integrity and feedback loop monitoring. These are capabilities that most vendors themselves struggle to provide visibility into, which is precisely why a platform needs to ask for evidence, not assertions. LLM06, Excessive Agency, requires evaluation of agent permission scope, tool access boundaries, and human-in-the-loop controls. LLM07, System Prompt Leakage, requires probing for exposure of system-level instructions through adversarial inputs. LLM08, Vector and Embedding Weaknesses, requires assessment of RAG pipeline integrity, embedding data sources, and retrieval boundaries. LLM10, Unbounded Consumption, requires monitoring for resource usage anomalies and rate-limit enforcement in cloud-deployed models.

The continuous-versus-point-in-time distinction is where many platforms that look adequate at procurement time fall apart in practice. A vendor's posture on LLM01 or LLM06 changes when they update their model, add a plugin, or extend agent permissions. A single assessment at procurement time does not hold. The attack surface you evaluated at contract signing may look substantially different six months later.

Scoring transparency is a related and often overlooked requirement. A defensible risk score needs observable evidence mapped to specific categories, not an aggregate number without an auditable basis. When an auditor asks which specific RMF subcategories were assessed and how, the answer cannot be a dashboard number.

Agentic AI raises the coverage bar further still. The OWASP ASI Top 10, scoped for 2026, introduces attack vectors that require runtime behavioral visibility by definition. Agent Goal Hijack (ASI01, which merges LLM01 and LLM06 in the agentic context), Insecure Inter-Agent Communication (ASI07), and Rogue Agents (ASI10) cannot be assessed through static questionnaire review. They require platforms to see what agents are actually doing at runtime, not what their developers documented about what they intended them to do.

How Platforms Satisfy the NIST AI RMF's Four Governance Functions in Practice

For each of the four RMF functions, the right question is whether a platform produces evidence that satisfies the function, not whether it mentions the function in its interface.

Govern: does the platform support policy definition, role assignment, and accountability documentation for AI vendor relationships? Many platforms do this reasonably well; it's the closest to traditional GRC functionality, and GRC is a mature discipline. Map: does the platform identify and catalog all AI assets in the vendor ecosystem, including models, plugins, agents, and connectors, not just approved software? This is where gaps start to appear. Shadow AI and undocumented model integrations are endemic in enterprise vendor ecosystems; a platform that only inventories what procurement already approved is missing a significant portion of the actual surface.

Measure: does the platform produce scored, auditable risk assessments tied to named risk categories, specifically OWASP categories and AI 600-1 risk areas, rather than pass/fail questionnaire responses? This is where the evidence-versus-citation distinction becomes operationally consequential. Manage: does the platform surface treatment recommendations, track remediation, and re-assess after vendor changes? The Manage gap is a common failure mode; many platforms identify risk at assessment time but do not monitor for changes. A vendor that fine-tunes a model or adds an agentic capability between assessments resets the risk picture without triggering re-evaluation.

AI 600-1 compliance requirements that platforms must operationalize for vendor relationships include collecting and reviewing model cards, system cards, and training data provenance from third-party AI vendors; assessing the Value Chain and Component Integration risk area, which aligns directly with LLM03; and documenting Data Privacy and Information Security risk treatment in terms the AI 600-1 suggested actions recognize. These are specific, auditable requirements. A platform that supports them operationally is doing something qualitatively different from one that lists them on a coverage matrix.

Key Platforms and How Their Framework Coverage Compares

The useful evaluation lens here isn't feature count or market position. It's OWASP category detection depth, NIST RMF function coverage, continuous monitoring capability, agentic AI readiness, and vendor ecosystem scope. Those five dimensions map directly to the gaps that legacy TPRM approaches leave open.

The market broadly organizes into three platform categories. Legacy TPRM platforms extended with AI modules offer broad vendor ecosystem coverage and mature questionnaire workflows, but AI-specific detection is shallow. They satisfy Govern documentation requirements reasonably well. Their coverage of Measure and Manage for AI-specific risks is typically thin; the AI module is an extension of a system that wasn't designed for AI behavior assessment. The questionnaire infrastructure is the same infrastructure that produces the confidence gap the brief describes: a large share of organizations acknowledge that questionnaire responses don't accurately reflect a vendor's real security posture.

AI governance and compliance platforms are strong on policy and documentation workflows, covering Govern and Map functions with genuine depth. Their scoring, however, is frequently tied to self-attestation rather than observable behavior. Runtime detection capability is limited. For organizations that need governance documentation for auditors and executives, these platforms serve a real purpose. For organizations that need to know what's actually happening in vendor AI systems, they leave the most important questions unanswered.

Purpose-built AI risk intelligence platforms are designed around AI-specific attack surfaces from the ground up. The best of them combine vendor assessment with continuous monitoring and produce OWASP-mapped, auditable findings that can feed all four RMF functions. That's the structural difference that matters.

Looking at specific platforms: OneTrust AI Governance brings broad GRC integration and is genuinely strong on policy and documentation workflows. Its coverage of NIST Govern and Map functions is real. Runtime OWASP detection depth is more limited, which reflects its heritage as a privacy and compliance platform. Prevalent and ProcessUnity represent the legacy TPRM category with AI extensions; wide vendor ecosystem reach, questionnaire-driven architecture, and AI risk treated as an add-on module rather than a native capability. The ecosystem breadth is a real advantage; the AI detection depth is the honest limitation.

Credo AI is focused on model governance and bias assessment, with genuine depth on NIST Measure and AI 600-1 risk areas including harmful bias. Its orientation is toward internal model governance rather than third-party vendor assessment at scale; real-time threat detection across vendor ecosystems isn't its primary design target. Hidden Layer specializes in model security and adversarial attack detection, with strong coverage of LLM01 and LLM04 in particular. Its orientation is toward protecting internally deployed models rather than third-party vendor assessment programs; organizations running their own models will find more native fit there.

Cranium operates as an AI security posture management platform, mapping AI assets and their connections across an environment. Its OWASP coverage is growing, and its Map and Measure function maturity is meaningful. Continuous Manage-function capability is still developing relative to its asset discovery and mapping strengths.

The honest observation across all of these is that no single platform in the current market achieves deep coverage across all five evaluation dimensions simultaneously. The closest approximations are the purpose-built AI risk platforms that treat OWASP detection as a first-class capability rather than a documentation layer. The selection decision ultimately comes down to which gaps your organization can tolerate versus which ones your regulatory context and threat model make unacceptable.

What's worth watching is how quickly the agentic AI category is forcing every platform to extend. ASI-class attack vectors require runtime behavioral visibility that most current architectures weren't built to provide. The platforms that are investing in that capability now, rather than waiting for the OWASP ASI Top 10 to finalize and enterprise demand to crystallize, are the ones most likely to close the framework coverage gap that currently exists across the category.