Two of the most useful documents in AI security never reference each other. The OWASP Top 10 for LLM Applications names the specific things that go wrong when you ship a large language model into production. The NIST AI Risk Management Framework names the organizational functions you need to manage that risk over time. A senior team reads both and instinctively connects them. This post writes that connection down. It maps the OWASP LLM Top 10 to NIST AI RMF, risk by risk, so the named technical failures sit inside the four functions that an AI governance program is actually organized around.
We will keep the scope honest, because this post is the easiest one to misread. A crosswalk between a risk catalog and a voluntary management framework is a thinking aid, not a compliance artifact. It helps a team see where each LLM risk lives in their governance structure and what kind of work answers it. It does not certify anything, and it cannot, because NIST AI RMF has no certification to give. The value here is the reasoning, not a checkbox.
Why map OWASP LLM Top 10 to NIST AI RMF
The OWASP LLM Top 10 is a list of risks. It tells you that prompt injection is real, that your model can leak sensitive data, that a poisoned training set or a compromised dependency can sit quietly inside your stack. What it does not tell you is who in your organization owns each of those risks, when the risk gets examined, and what kind of activity reduces it. That is a structural gap, and it is exactly the gap a governance framework is built to fill.
NIST AI RMF answers the structural questions. Its four functions, Govern, Map, Measure, and Manage, describe the lifecycle of managing any AI risk. Govern sets the policy and accountability. Map establishes the context and identifies risk in that context. Measure analyzes and monitors the risk. Manage allocates resources and acts on what the other functions surface. Drop a concrete OWASP risk into that structure and a vague worry becomes an assignable piece of work.
The practical payoff is shared language across two audiences who rarely use the same words. Your application security engineers speak in OWASP terms. Your risk, legal, and executive stakeholders speak in framework terms. A crosswalk lets a single finding, say a prompt injection exposure, travel cleanly from an engineer’s test result to a governance owner’s risk register without losing meaning. That translation is most of what governance readiness actually is.
There is one more reason to do this deliberately. A poorly drawn mapping invents false precision, pinning a risk to a single function as if the assignment were mechanical. Real LLM risks rarely live in one function. They are governed in policy, identified in context, measured in testing, and managed in response. The honest version of this crosswalk names the best-fit function or functions and explains the reasoning, which is the part you can actually defend to an auditor or a board.
The two frameworks at a glance
The OWASP Top 10 for LLM Applications, in its 2025 edition, names ten risk categories specific to applications built on large language models. The list reflects how these systems actually fail in production, from manipulation of the model through its inputs, to leakage through its outputs, to weaknesses in the data and supply chain that feed it. The ten categories are the canonical reference point for anyone testing or securing an LLM application, and they are stable enough to plan around.
NIST AI RMF 1.0, published as NIST AI 100-1, is a voluntary framework for managing risks across the AI lifecycle. Its core is four functions. Govern is the connective tissue: organizational culture, oversight, accountability, roles, and policy. Map is about context and framing: understanding where the system operates and identifying the risks and impacts that context creates. Measure is the analytical function: assessing, benchmarking, and monitoring risk and the trustworthiness characteristics of the system. Manage is the action function: allocating resources, prioritizing, and responding to and recovering from the risks that Map and Measure surface.
Those four functions break down further into categories and subcategories. We deliberately map at the function level in this crosswalk rather than citing subcategory codes. Mapping to Govern, Map, Measure, and Manage is defensible and stable. Asserting that a given OWASP risk lands on a specific numbered subcategory invites false precision and is the kind of detail a real readiness engagement works out against your actual system, not a blog post. NIST also publishes companion resources, including the AI RMF Playbook and the Generative AI Profile (NIST AI 600-1), which go deeper on generative systems specifically and are worth reading alongside this crosswalk.
One framing note before the table. OWASP gives you the risks. NIST gives you the functions for managing them. Neither is a control checklist in the audit sense, and stitching them together does not produce one. It produces a map of where work lives.
Control-by-control mapping (Govern, Map, Measure, Manage)
The table below maps each OWASP LLM Top 10 (2025) risk to the NIST AI RMF function or functions that best fit it, with the reasoning. A pattern holds across the list and is worth stating up front. Almost every risk is identified in Map (you cannot manage a risk you have not framed in context), measured in Measure (testing, monitoring, benchmarking), and acted on in Manage (response, mitigation, recovery). Govern appears wherever the primary lever is policy, accountability, or human oversight rather than a technical test. We name the dominant function or functions for each risk and explain why, rather than tagging all four every time, which would be true but useless.
| OWASP LLM risk | Primary NIST AI RMF function(s) | Reasoning |
|---|---|---|
| LLM01:2025 Prompt Injection | Measure, Manage (Map for context) | Injection is found by adversarial testing (Measure) and contained by input handling, privilege limits, and human review (Manage). Map frames where untrusted input enters the system, which determines the blast radius. |
| LLM02:2025 Sensitive Information Disclosure | Govern, Measure, Manage | Data handling and disclosure policy is a Govern question (what may the model see and emit). Measure tests for leakage through outputs and logs. Manage enforces redaction, output filtering, and access controls. |
| LLM03:2025 Supply Chain | Map, Govern, Manage | Supply chain risk starts with knowing your dependencies, models, plugins, and MCP tool surfaces (Map). Govern sets vendor and provenance policy. Manage maintains pinning, drift gating, and update review. This is the MCP supply chain surface discussed in the sibling work below. |
| LLM04:2025 Data and Model Poisoning | Map, Measure, Manage | Poisoning risk depends on data provenance and training context (Map). Measure detects anomalous data and degraded model behavior. Manage governs data sourcing, validation, and retraining response. |
| LLM05:2025 Improper Output Handling | Manage, Measure | Treating model output as trusted input is an integration failure handled by encoding, validation, and least privilege at the boundary (Manage). Measure tests downstream systems for injection and unsafe execution paths. |
| LLM06:2025 Excessive Agency | Govern, Manage (Map for scope) | Excessive agency is fundamentally a policy and design question: what is the agent permitted to do, and who approved it (Govern). Map scopes the agent’s tools and authority. Manage enforces permission boundaries, human-in-the-loop gates, and tool restrictions. |
| LLM07:2025 System Prompt Leakage | Measure, Manage, Govern | Measure tests whether the system prompt can be extracted. Manage removes secrets and authority from the prompt so leakage is non-fatal. Govern sets the standing rule that system prompts are never a security boundary. |
| LLM08:2025 Vector and Embedding Weaknesses | Map, Measure, Manage | Retrieval and embedding risk depends on understanding the RAG architecture and trust boundaries of the vector store (Map). Measure tests retrieval for poisoning and access leakage. Manage enforces access controls, tenant isolation, and source validation. |
| LLM09:2025 Misinformation | Govern, Measure, Manage | Acceptable accuracy and the consequences of a confidently wrong answer are a Govern decision tied to use context. Measure benchmarks factuality and grounding. Manage adds grounding, citations, human review, and disclosure to users. |
| LLM10:2025 Unbounded Consumption | Manage, Measure (Govern for limits) | Resource exhaustion and denial of wallet are operational controls: rate limiting, quotas, and cost caps (Manage). Measure monitors consumption and anomalies. Govern sets the policy thresholds that those controls enforce. |
A few reasoning threads run through the whole table and are worth pulling out.
Govern shows up wherever the real fix is a decision, not a test. Excessive agency, sensitive data disclosure, and misinformation are not primarily things you scan for. They are things you set a policy about, assign an owner to, and then test against. That is why those rows lead with Govern. The technical work in Measure and Manage is downstream of a governance call that someone has to make on purpose.
Map shows up wherever the risk depends on context you have to establish first. Supply chain, poisoning, and embedding weaknesses all assume you know what is in your system: which models, which data sources, which tools, which trust boundaries. If you have not mapped that, the measurement and management steps have nothing to act on. This is the same reason an AI inventory is the prerequisite for everything else, which the sibling post on shadow AI discovery covers directly.
Measure and Manage carry the operational load for almost every risk. Prompt injection, output handling, system prompt leakage, and unbounded consumption are found through testing and contained through controls. This is where a real security test lives, and it is the part a checklist scan tends to do shallowly.
Where the mapping is judgment, not a lookup
The table looks tidy. The work behind it is not, and pretending otherwise is the failure mode this whole post is trying to avoid. Several of these assignments are genuine judgment calls, and a different senior team could defend a different split. That is a feature of the frameworks, not a flaw in the crosswalk.
Consider LLM03 Supply Chain. We lead it with Map and Govern because, for most teams, the binding constraint is not a clever test but simply knowing what they depend on and having a policy for vetting it. A team that already maintains a tight, pinned, drift-gated dependency surface might reasonably argue the live risk has shifted to Manage, because identification is solved and the work is now ongoing enforcement. Both readings are correct for the team that holds them. The function assignment follows where the risk actually bites in your environment, which is why this is a conversation, not a lookup.
Consider LLM06 Excessive Agency in an agentic system. Read narrowly, it is a Govern question about permissions. Read in a multi-tool agent that chains actions across an MCP surface, it becomes a Map problem (what is the full reachable action space), a Measure problem (can the agent be steered into actions outside its intended scope), and a Manage problem (enforce the boundaries at runtime). The more capable the system, the more functions a single OWASP risk legitimately touches. A crosswalk that forced one answer would be lying about that.
The honest stance is this. The function assignment is a default starting point, defensible on its face, that a readiness engagement then adjusts against your specific architecture, data flows, and threat model. The reasoning column matters more than the function column, because the reasoning is what you reuse when your system differs from the assumed case. Treat the table as a structured opinion, not an answer key.
What this crosswalk is / What it is not
What it is: A practitioner alignment aid that connects the OWASP LLM Top 10 (2025) risks to the four NIST AI RMF functions (Govern, Map, Measure, Manage), with the reasoning a senior team uses to place each risk. It is meant to give application security and governance stakeholders shared language and a defensible starting point for organizing LLM risk inside a governance structure.
What it is not: It is not an official OWASP-to-NIST mapping, and neither organization publishes or endorses this crosswalk. It is not a certification, a conformity assessment, or evidence of compliance with any standard. NIST AI RMF is a voluntary framework with no certification program, so no document can certify alignment to it. We map at the function level by design and do not assert specific subcategory codes, because that level of precision belongs to a real engagement against a real system, not a general reference. Use this to think and to organize, not to claim.
Using the crosswalk for readiness (not certification)
Readiness is the goal, and readiness is a posture, not a stamp. A team is ready when each LLM risk has a named owner, a place in the governance structure, a way it gets tested, and a planned response when testing finds something. The crosswalk is useful precisely because it produces those four things for every risk in one pass. That is the work it does, and it is honest about not doing more.
Here is a concrete way to use it. For each row in the table, ask four questions and write down the answer for your system. Who owns this risk (the Govern answer). Where does it live in our architecture and what context shapes it (the Map answer). How do we test for it and how would we know it is present (the Measure answer). What do we do when we find it (the Manage answer). Ten risks, four questions each, and you have the skeleton of a governance posture mapped to a recognized framework, with the gaps visible as blank cells.
The blank cells are the point. A risk with a strong Measure answer and no Govern owner is a risk that gets tested by an engineer and then dropped, because no one is accountable for acting on the result. A risk with a clear Govern policy and no Measure method is a policy no one can verify. The crosswalk surfaces these mismatches as structure, which is far easier to act on than a flat list of worries.
What the crosswalk will not do is make a compliance claim on your behalf, and you should be wary of any vendor or tool that says it does. Mapping LLM risks to NIST AI RMF functions supports readiness. It does not produce certification, because there is none to produce. The right output of this exercise is a clear-eyed picture of where you are organized and where you are exposed, expressed in language your engineers and your board both understand. That picture is what an AI Governance Readiness engagement is built to produce and then close the gaps in.
FAQ
Is there an official OWASP-to-NIST AI RMF mapping? No. Neither OWASP nor NIST publishes an official crosswalk between the OWASP LLM Top 10 and the NIST AI RMF functions. The two are independent documents from independent organizations. The mapping in this post is a practitioner alignment aid that connects them by reasoning, and it should be treated as a structured opinion you adjust to your own system, not an endorsed standard.
Does mapping to NIST AI RMF mean my system is compliant or certified? No. NIST AI RMF is a voluntary framework and has no certification program, so no document or mapping can certify alignment to it. Connecting your LLM risks to the Govern, Map, Measure, and Manage functions supports readiness by organizing the work and surfacing gaps. It is not a compliance claim, a conformity assessment, or certification of any kind.
Why map at the function level instead of citing specific subcategories? Mapping to the four functions (Govern, Map, Measure, Manage) is defensible and stable across systems. Asserting that a given OWASP risk lands on a specific numbered subcategory invites false precision, because the right subcategory depends on your actual architecture, data flows, and threat model. That level of detail is the output of a real readiness engagement, not a general reference, so we map at the function level by design.
Which NIST AI RMF function carries most LLM risks operationally? Measure and Manage carry most of the day-to-day operational load. Most LLM risks are found through testing and monitoring (Measure) and contained through controls and response (Manage). Govern leads where the primary lever is policy, accountability, or human oversight rather than a test, such as excessive agency or acceptable accuracy. Map leads where the risk depends on context you must establish first, such as supply chain and embedding weaknesses.
Where should a team start with this crosswalk? Start with Map and an inventory. Most of the risks that lead with Map (supply chain, data poisoning, embedding weaknesses) assume you already know what is in your system. If you do not have a current AI inventory, build that first, because measurement and management have nothing to act on without it. From there, work each row through the four ownership questions to expose where your governance posture is strong and where it is blank.
If you need this crosswalk applied to your own systems, the AI Governance Readiness engagement does exactly that. It works each LLM risk through the NIST AI RMF functions against your actual architecture, names the owners, identifies the testing methods, and turns the blank cells into a prioritized plan. Learn more at /ai-governance-readiness.html. If your priority is the adversarial testing side that feeds the Measure function, see how the AI Security X-Ray treats LLM risk as a tested attack surface at /ai-security-assessment.html.
Key facts
- This practitioner crosswalk maps all ten OWASP LLM Top 10 (2025) risks to the four NIST AI RMF functions (Govern, Map, Measure, and Manage) at the function level, deliberately avoiding subcategory codes that invite false precision (DSE, 2026).
- NIST AI RMF is a voluntary framework with no certification program, so no document or mapping can certify alignment to it; the crosswalk supports readiness and shared language, not a compliance claim (DSE, 2026).