Mapping your AI to the OWASP LLM Top 10

Most AI security programmes start the same way: someone pastes the OWASP Top 10 for LLM Applications into a spreadsheet, writes "covered" next to eight rows, and files it. The document is worthless within a quarter, for two reasons. It maps categories to products instead of to surfaces, and it does not distinguish a control that prevents a failure from a control that sometimes notices one.

What the list actually is

The 2025 edition names ten failure modes, maintained in the open at the project repository:

• LLM01 Prompt Injection
• LLM02 Sensitive Information Disclosure
• LLM03 Supply Chain
• LLM04 Data and Model Poisoning
• LLM05 Improper Output Handling
• LLM06 Excessive Agency
• LLM07 System Prompt Leakage
• LLM08 Vector and Embedding Weaknesses
• LLM09 Misinformation
• LLM10 Unbounded Consumption

These are categories of outcome, not of attack. A single technique routinely lands in several: an indirect injection (LLM01) that pulls text out of a poisoned corpus (LLM08, LLM04), causes the assistant to reveal its instructions (LLM07), and exfiltrates a customer record through a rendered link (LLM02, LLM05). A map that assigns each incident to exactly one row will misrepresent your exposure.

The renumbering trap

The 2025 edition reordered and renamed most of the list relative to the 2023 one. The identifiers were reused, which means an old map is not merely stale, it is actively misleading:

• Excessive Agency was LLM08 in 2023. It is LLM06 in 2025.
• Sensitive Information Disclosure was LLM06. It is now LLM02.
• Insecure Output Handling (LLM02 in 2023) became Improper Output Handling at LLM05.
• Supply Chain moved from LLM05 to LLM03; Training Data Poisoning broadened into Data and Model Poisoning at LLM04.
• Three entries are effectively new in 2025: System Prompt Leakage, Vector and Embedding Weaknesses, and Unbounded Consumption.

A mapping method

Map surfaces, not products. The unit of analysis is a place where untrusted data meets authority:

1. Inventory the surfaces. Every model endpoint, retrieval corpus, memory store, tool or function the model can call, and every rendering surface that displays model output. Shadow deployments count, and are usually where the gaps are.
2. For each surface, ask which categories are reachable. Not in general, in your system. A retrieval corpus that only ever ingests internally authored documents has a different LLM01 exposure than one that crawls the public web, and the difference belongs in the map.
3. Name the specific control per pair. "Guardrails" is not a control. "Outbound URLs containing model-derived data are refused at the gateway" is.
4. Record what you cannot currently see. An empty cell is information. A cell marked "covered" with nothing behind it is a liability.

Rating a control honestly

The single most useful column in the map is not the category. It is what kind of control you have:

• Preventive and deterministic. A capability gate, an allow-list, a policy evaluated outside the model. Its behaviour does not change when the attacker rephrases.
• Detective and probabilistic. A classifier or heuristic. Useful, measurable, and evadable. Nasr and colleagues bypassed twelve published defences of this kind at over 90% success once the attacker was allowed to adapt, against defences that had reported near-zero rates on static tests.
• Evidentiary. It does not stop anything; it proves what happened. This is what an audit actually consumes.

A row covered only by a probabilistic control is not closed. It is monitored. Writing that distinction down is what separates a map that survives an incident from one that gets quietly rewritten after it.

Cross-mapping to ATLAS and NIST

The Top 10 tells you what can go wrong. Two other frameworks answer the questions your reviewers will ask next.

MITRE ATLAS catalogues the adversary techniques that produce those outcomes, in the same tactic-and-technique structure as ATT&CK. Mapping your red-team coverage to ATLAS techniques and your risk register to OWASP categories gives you both halves: what was tested, and what it would have caused.

The NIST AI RMF supplies the governance wrapper: its Govern, Map, Measure and Manage functions are the language most enterprise reviewers and, increasingly, regulators expect. Measure is the function most programmes under-serve, because it demands numbers rather than coverage claims.