Direct comparison
NIST AI 100-2 vs OWASP LLM Top 10
A taxonomy of adversarial ML attacks vs a ranked list of LLM app risks: what each covers, where they overlap, and when to reach for which.
Written and maintained by CASRAI Editorial Board
Last updated
Ask CASRAI · free to try
Ask about NIST AI 100-2 vs OWASP LLM Top 10
Ask your first 2 questions free below. Subscribers get 150 a day for $29 a month.
An AI assistant specialized in research administration. It cites the sources behind every answer, labels web answers and says when it can't answer.
Answers draw on CASRAI's guides and dictionary plus the federal and funder documents we index: Federal Register, Grants.gov, Regulations.gov and UKRI.
Works on this site and inside Claude, Cursor and the AI tools you already use.
Everything CASRAI publishes — this page, the dictionary, the guides and the news — stays free to read, with no account and no card.
How do NIST AI 100-2e2025, OWASP Top 10 for LLM Applications (2026) compare side by side?
The table below compares NIST AI 100-2e2025, OWASP Top 10 for LLM Applications (2026) across 19 procurement-relevant dimensions, from what it actually is through reach for it when.
Side-by-side comparison
| Dimension | NIST AI 100-2e2025 | OWASP Top 10 for LLM Applications (2026) |
|---|---|---|
| What it actually is | A taxonomy and terminology reference. It names and defines the attack classes established in the adversarial machine-learning literature and standardises the language used to describe them. It ranks nothing. | A ranked list of the ten risks the OWASP GenAI Security Project judges most critical in LLM and generative-AI applications, with prevention guidance and example attack scenarios attached to each entry. |
| Full title and identifier | NIST AI 100-2e2025, "Adversarial Machine Learning: A Taxonomy and Terminology of Attacks and Mitigations", published in the NIST Trustworthy and Responsible AI series. | "OWASP Top 10 for LLM Applications 2026", published by the OWASP GenAI Security Project. Entries carry year-versioned identifiers, so an entry is properly cited as LLM01:2026 rather than LLM01. |
| Current edition | The e2025 edition, published March 2025. NIST has said it intends to revise the report as the field develops; as of September 2026 no later edition has appeared, so the March 2025 text is still current. | The 2026 edition, published August 2026, superseding the 2025 edition. A new edition is the norm rather than the exception here, and the numbering changes with it. |
| Who wrote it | A named, cross-institutional author team: Apostol Vassilev of NIST, Alina Oprea of Northeastern University, Alie Fordyce and Hyrum Anderson of Cisco, Xander Davies of the UK AI Security Institute and Maia Hamin of the US AI Safety Institute, working from an extensive academic literature review. | An open community project with hundreds of contributing practitioners. No named author team sets the ranking; it comes out of a structured vote combined with incident data. |
| Scope of AI systems covered | Both predictive AI and generative AI, across supervised, unsupervised, semi-supervised, federated and reinforcement learning, and across multiple data modalities. It reaches down to the model and the training process, not just the deployed product. | Generative AI only, and specifically applications built on large language models: the deployed product, its retrieval layer, its tool integrations and its agents. It does not attempt to cover predictive machine learning at all. |
| Organising principle | Classification. Attacks are sorted along several axes at once: the type of AI system targeted, the lifecycle stage at which the attack lands, the attacker’s objective, the attacker’s capabilities and access, and the attacker’s knowledge of the learning process. | Prioritisation. The list is ordered by judged criticality, so it answers "what should we look at first" rather than "what kinds of attack exist". Ordering is the product, not an accident of presentation. |
| Attacker-objective classes | Availability breakdown, integrity violation and privacy compromise for predictive AI, with misuse enablement added as a fourth objective class for generative AI. Every attack in the taxonomy is placed against one of these. | No equivalent abstraction. Each entry is a concrete failure mode observed in real applications, and a single OWASP entry can span several NIST objective classes at once. |
| How prompt injection appears | As a named attack class inside the generative-AI taxonomy, split into direct prompt injection, where instructions arrive through the user interface, and indirect prompt injection, where they are planted in external content the model later retrieves. | As LLM01, the top-ranked entry in both the 2025 and 2026 editions. The 2026 edition widened it to take in cross-modal injection carried in images and audio rather than text alone. |
| Treatment of autonomous agents | The 2025 edition extended the taxonomy to autonomous agents for the first time, covering indirect prompt injection against agents, agent memory poisoning and supply-chain attacks on the tools an agent calls. | Excessive Agency rose from LLM06 in 2025 to LLM03 in 2026. OWASP also maintains a separate Top 10 for Agentic Applications, and in September 2026 a donated Agent Control Standard was added to the project. |
| The 2026 list, in order | Not applicable. NIST publishes no ranking, on the position that which attack matters most depends on the system, the data and the deployment context rather than on a general judgement. | LLM01 Prompt Injection, LLM02 Sensitive Information Disclosure, LLM03 Excessive Agency, LLM04 Supply Chain, LLM05 Data and Model Poisoning, LLM06 Unbounded Consumption, LLM07 Misinformation, LLM08 Hidden Context Exposure, LLM09 Vector and Embedding Weaknesses, LLM10 Improper Output Handling. |
| What changed in the latest revision | The 2025 edition broadened generative-AI coverage substantially, adding supply-chain attacks, direct and indirect prompt injection, misuse violations and agent security, and expanded the underlying literature review considerably over the previous edition. | No entry was added or removed. System Prompt Leakage was renamed Hidden Context Exposure and widened from the system prompt alone to everything placed in front of the model without the user seeing it. Eight of the ten entries changed position; the largest single move was Improper Output Handling falling from LLM05 to LLM10. |
| How the ordering is derived | Not applicable — there is no ordering to derive. | Reported as a weighted blend, with the community vote carrying roughly three quarters of the weight and incident data the remainder, drawn from a corpus of several thousand documented AI security incidents in public vulnerability and AI-harm databases. Reporting on the process notes that prompt injection ranked first on the vote but far lower on incident data alone. |
| What it says about mitigations | Mitigations are discussed per attack class, and the report is candid that for several classes no reliable mitigation exists. It documents the state of the research rather than promising that the problem is solved. | Every entry carries prevention and mitigation guidance written for engineers, at the level of a control you can actually implement in an application. |
| Standing and compliance status | Voluntary guidance from a US federal agency. It is not a regulation, it is not certifiable, and there is no defined notion of complying with it. It is a reference work, and citing it is not evidence of anything. | A voluntary community artefact with no standards-body status. It is widely written into procurement language and penetration-test scopes, but nothing certifies against it and no body audits conformance. |
| Relationship to other frameworks | Sits alongside the NIST AI Risk Management Framework and its Generative AI Profile, supplying the attack vocabulary those documents lean on rather than duplicating their governance structure. | The 2026 edition publishes explicit mappings to NIST, MITRE ATLAS, CWE and OWASP’s own Top 10 for Agentic Applications, which makes it a reasonable bridge document between security engineering and AI governance vocabulary. |
| How this maps to NIKOLAI | NIST’s attack classes are the kind of vocabulary NIKOLAI’s threat-model element expects: a structured statement of who could cause which harm, by what means, with what role played by the AI system. NIKOLAI is CASRAI’s own independent dictionary and is unendorsed, so any correspondence drawn between NIST’s terms and NIKOLAI elements is a shadow mapping — NIST has filed no Mapping Declaration. | Individual OWASP entries sit at the granularity of NIKOLAI’s risk-pathway element: a specific causal route from model behaviour or misuse to harm, finer-grained than a threat model. The same caveat applies — OWASP has filed no Mapping Declaration, so treat any crosswalk as a shadow mapping rather than an agreed equivalence. |
| Research-administration relevance | Useful to university research-computing and information-security teams writing a defensible threat model of a campus AI deployment, and it carries the weight that a NIST publication carries in institutional policy. It is not a control set, though: it maps to no sponsored-research security requirement and satisfies no award term. | The more practical list once something is actually deployed — a retrieval assistant over grant documents, an IRB triage aid, an export-control screening tool. Sensitive Information Disclosure and Hidden Context Exposure bite hardest where the retrieval corpus holds unpublished protocols, participant data or controlled technical information. |
| Where each one is weak | It offers no prioritisation and no test procedures. A team can read it end to end and still not know what to do on Monday morning. | A top-ten list is a forcing function, not a map. Risks outside the ten are genuinely out of scope, and the ordering reflects one community’s judgement at one moment, not your system’s threat profile. |
| Reach for it when | You are naming threats and need definitions that survive scrutiny: writing a threat model, a safety case, the security section of a framework document, or policy language other people will read literally. | You are testing or hardening a system that already exists, and need an ordered starting list of what to probe and what to fix first. |
Common questions
Common questions about NIST AI 100-2e2025 vs OWASP Top 10 for LLM Applications (2026)
Do these two documents contradict each other?
+
No, and it is worth being precise about why. They do different jobs at different altitudes. NIST classifies attacks without ranking them because it takes the view that priority depends on the system in front of you. OWASP ranks ten risks because an ordered list is what an engineering team can act on. Where they describe the same phenomenon — prompt injection is the clearest case — they agree on the substance and differ only in whether they tell you it is the most important thing.
Which one should we adopt?
+
Neither is adoptable in the sense that ISO/IEC 42001 is adoptable. There is no certification, no audit and no conformance statement for either. The useful question is which one you cite where. Use NIST AI 100-2 vocabulary in documents that define threats, and use the OWASP list to scope testing and to order remediation work. Most teams that get value out of both end up using NIST terms in their threat model and OWASP entry numbers in their test plan.
We cited the 2025 OWASP numbering. Do we have to update it?
+
Yes, if the citation needs to stay accurate. The 2026 edition moved eight of ten entries, so an unversioned reference to LLM05 now points at Data and Model Poisoning where it used to point at Improper Output Handling, and LLM06 now means Unbounded Consumption where it used to mean Excessive Agency. The year-versioned form — LLM05:2025 or LLM05:2026 — exists precisely to stop this, and is worth using in anything that will be read later.
Does NIST AI 100-2 cover prompt injection at all?
+
It does, and in more structural detail than the reputation of a taxonomy document suggests. The 2025 edition treats prompt injection as a named class within the generative-AI taxonomy and separates direct injection, where the instruction arrives through the user interface, from indirect injection, where it is planted in external content the model later retrieves. That direct-versus-indirect split is the distinction most useful when writing a threat model, because the two have different trust boundaries and different mitigations.
Why does NIST refuse to rank anything?
+
Because a ranking is a claim about a population of systems, and NIST is writing for a population that includes image classifiers, fraud models, federated learning deployments and chat applications. What threatens one of those barely touches another. A taxonomy stays correct across that range; a ranking would have to pick a representative system and would then be wrong for most readers. OWASP can rank because it scoped itself to one kind of system.
Does using both create duplicated work?
+
Less than you would expect, because they feed each other. NIST gives you the classes; OWASP tells you which of those classes are currently showing up in deployed applications and in what order. The 2026 OWASP edition publishes mappings to NIST among other frameworks, which removes most of the translation work. The duplication risk is real only if you try to use one of them for the other’s job.
Are either of these binding on a federally funded research institution?
+
No. Neither document creates an obligation. NIST AI 100-2 is voluntary guidance and is not part of the NIST SP 800-171 control set that flows into research security requirements, and OWASP has no regulatory standing at all. An institution may choose to reference either in its own AI use policy, and some award terms or sponsor requirements may reference AI security practices generally, but that is the institution’s or the sponsor’s choice rather than anything these documents impose.
