26/10/2026

NIST AI 100-2: The Attack Taxonomy as AI Act Evidence

NIST AI 100-2 is the US reference vocabulary for attacks on machine learning: evasion, poisoning, privacy breaches, prompt injection and the newer agent hijacks. European security and compliance teams use it as a threat catalogue, yet the document itself says nothing about the EU AI Act. This guide explains what the 2025 edition contains, what changed since 2023, what it deliberately leaves out, and how to turn its attack identifiers into the evidence Article 15 of the AI Act will require.

NIST AI 100-2 attack taxonomy as an open wooden specimen drawer with labelled compartments, brass keys, a cracked lens and a broken wax seal

Key takeaways

NIST AI 100-2 E2025 (March 2025) classifies adversarial machine learning attacks on predictive and generative AI and gives each one a stable <code>NISTAML</code> identifier: we count 5 violation categories and 25 attack identifiers.
It is voluntary and, by our count, never mentions the EU AI Act or any ISO/IEC standard. NIST says it deliberately leaves aside how organisations should decide in light of the attacks.
Article 15(5) of the AI Act names the same attack classes, so the identifiers make a natural key for a threat register, a test plan and a technical file.
The European standards that will give Article 15 its technical content moved in 2026: ETSI EN 304 223, ISO/IEC 27090 and the prEN 18282 enquiry. CRA vulnerability reporting has applied since 11 September 2026.
NIST web pages now say “Super Intelligence” after a US executive order of 29 September 2026, but the document identifier is unchanged.

What NIST AI 100-2 is, and what it is not

NIST AI 100-2 is the short name of “Adversarial Machine Learning: A Taxonomy and Terminology of Attacks and Mitigations”, a report in the NIST Trustworthy and Responsible AI series. The current edition, NIST AI 100-2e2025, was approved by the NIST Editorial Review Board on 20 March 2025 and announced on 24 March 2025. Its authors come from NIST, Northeastern University, Cisco, the US AI Safety Institute and the UK AI Security Institute, which explains why the vocabulary is now shared on both sides of the Atlantic.

NIST AI 100-2 does three things. It defines a taxonomy of attacks against AI systems, it describes known mitigations and their limits, and it closes with a glossary. By our count, the 2025 text runs to 127 pages and cites 449 references. It is a literature-backed map of the field, not a control catalogue: you will not find “shall” statements, maturity levels or audit criteria.

NIST is explicit about the legal status. A footnote states that the report “does not establish any legal standard or any other legal requirement or defense under any law”, and the executive summary adds that it makes no recommendation on risk tolerance. It borrows its security and resilience concepts from the NIST AI Risk Management Framework, covered in our NIST AI RMF guide, and it sits alongside the generative AI profile explained in our NIST AI 600-1 article.

What changed between E2023 and E2025

The first final edition, NIST AI 100-2e2023, was published in January 2024. Comparing the two PDFs, we found five changes that matter to practitioners:

Stable attack identifiers (<code>NISTAML.xxx</code>) appear for the first time: 30 codes in total, of which 5 are violation categories and 25 are attack types. E2023 had none.
The generative AI violation once called “abuse” is now “misuse”.
Supply-chain attacks on generative AI get a dedicated section and their own category.
New sections cover the security of agents and the benchmarks used to test models.
The reference list grows from 354 to 449 entries, and the page count from 107 to 127.

The Super Intelligence relabelling

On 29 September 2026 a US executive order, summarised in the White House fact sheet, told federal agencies to say “Super Intelligence” instead of “Artificial Intelligence” in their official communications. NIST followed. Its NCCoE project page is now titled “Super Intelligence: Adversarial Machine Learning”, and on 20 October 2026 its control overlay project was renamed COSIS, with the note that “Previously issued documents and publications have not been altered”. The identifier NIST AI 100-2e2025 therefore stands, and the order creates no obligation for private companies. As of 22 October 2026 we found no 2026 edition, although NIST said in March 2025 that it intends to update the report annually.

How the taxonomy is built: five dimensions, five categories

Every attack in NIST AI 100-2 is located along five dimensions. The first is the type of system: predictive AI (classifiers, scoring models, computer vision) or generative AI (large language models, image generators and the applications built on them). The second is the stage of the life cycle at which the attack is mounted, from training-time data collection to deployment and inference. The third is the attacker’s goal, expressed as the system property they want to break: availability, integrity or privacy, with misuse added for generative AI. The fourth is capability: what the attacker can actually touch, such as training data, labels, model weights, source code, query access or, for generative applications, the resources a model retrieves and the tools it can call. The fifth is knowledge, from white-box (full access to the model) to black-box (query access only), with gray-box cases in between.

The goals become five violation categories, each with a code:

<code>NISTAML.01</code> availability violations, which degrade or deny the service.
<code>NISTAML.02</code> integrity violations, which make the system produce the outputs the attacker wants.
<code>NISTAML.03</code> privacy compromises, which extract data, prompts or the model itself.
<code>NISTAML.04</code> misuse violations, which turn a generative model against its own usage policy.
<code>NISTAML.05</code> supply-chain attacks, which compromise models or data before you receive them.

Below these sit the 25 attack identifiers. They are the most useful thing in NIST AI 100-2 for a compliance team, because they are stable references that survive changes of tooling, vendor and wording. A threat register keyed on <code>NISTAML.022</code> (evasion) or <code>NISTAML.015</code> (indirect prompt injection) can be cross-referenced with MITRE ATLAS techniques and with the OWASP Top 10 for LLM applications without being rewritten every time one of those lists changes. Our adversarial AI primer explains the underlying attack mechanics for readers new to the field.

Predictive AI attacks: evasion, poisoning, privacy

For predictive models, NIST AI 100-2 groups attacks into three families.

Evasion (<code>NISTAML.022</code>, and <code>NISTAML.025</code> for black-box variants) means crafting inputs that a model misclassifies while a human sees nothing unusual. NIST AI 100-2 recalls real-world cases such as stop signs read as speed-limit signs and adversarial glasses that defeat face recognition. It also covers transferability: an attack built against one model often works against another, which is why “our model is private” is not a defence.

Poisoning happens before deployment. Availability poisoning (<code>NISTAML.013</code> data poisoning, <code>NISTAML.011</code> model poisoning, <code>NISTAML.012</code> clean-label poisoning, <code>NISTAML.014</code> energy-latency) degrades the whole model. Targeted poisoning (<code>NISTAML.024</code>) changes predictions for chosen inputs. Backdoor poisoning (<code>NISTAML.023</code>, and the clean-label backdoor <code>NISTAML.021</code>) plants a trigger that activates hidden behaviour. Model poisoning (<code>NISTAML.026</code>) tampers with the parameters directly, and <code>NISTAML.051</code> covers the same move through the supply chain.

Privacy attacks extract what the model knows: model extraction (<code>NISTAML.031</code>), data reconstruction (<code>NISTAML.032</code>), membership inference (<code>NISTAML.033</code>), which reveals whether a record was in the training set, and property inference (<code>NISTAML.034</code>).

For each family NIST AI 100-2 lists mitigations: adversarial training, randomized smoothing and formal verification against evasion; data sanitisation, training-time defences and model inspection against poisoning; differential privacy and query controls against privacy attacks. It is equally clear about their limits. Most defences are empirical, there are no information-theoretic security proofs for widely used machine learning algorithms, and several published defences were later broken. For an auditor this has a direct consequence: a mitigation alone is not evidence. What counts is the test showing how it behaves against the attack you modelled, which is where AI red teaming earns its place.

Generative AI attacks: supply chain, prompting, injection and agents

The generative AI half of NIST AI 100-2 is where the 2025 edition grew most. It distinguishes four entry points.

Supply-chain attacks target the data and models you import: poisoned web-scale training data, compromised pre-trained weights, malicious fine-tuning sets. If your product builds on third-party foundation models, this is the section to map against your AI bill of materials.

Direct prompting attacks come from the user. Prompt injection (<code>NISTAML.018</code>) covers jailbreaks that bypass safety training and instructions that override the system prompt. Information-extraction attacks reveal the system prompt (<code>NISTAML.035</code>), data from other users’ interactions (<code>NISTAML.036</code>), training data (<code>NISTAML.037</code>, <code>NISTAML.038</code>) or misaligned outputs the developer tried to suppress (<code>NISTAML.027</code>).

Indirect prompt injection (<code>NISTAML.015</code>) is the class most enterprise deployments underestimate. The attacker never talks to the model: they plant instructions in a web page, an email or a document that a retrieval-augmented application will read. The report lists availability effects (NISTAML.016, including time-consuming background tasks, <code>NISTAML.017</code>), integrity effects and privacy compromise, up to <code>NISTAML.039</code>, compromising connected resources.

Agents raise the stakes. When a model can call tools, run code or send messages, a successful injection becomes code execution or data exfiltration. NIST notes that security research focused specifically on agents “is still in its early stages”, which matches what we see in practice and in our agentic AI security guide.

NIST AI 100-2 closes the section with the benchmarks and tools teams use to test exposure: JailbreakBench, HarmBench, StrongREJECT and AgentDojo for evaluation, Garak and PyRIT for automated probing. Naming the tool and its version in a test record is a small habit that makes results reproducible for an assessor.

What the taxonomy deliberately leaves out

The most useful sentence in NIST AI 100-2 for a European reader is in section 4.2.5: “A key question that this taxonomy deliberately leaves aside is how organizations can make decisions about the development and use of AI systems in light of evidence about the increasing diversity of AML attacks and the efficacy and limitations of available mitigations.”

That choice is consistent throughout. By our count, the 127-page E2025 text never mentions the EU AI Act, never cites ISO/IEC 42001 or any other ISO/IEC standard, and uses the word “compliance” once and “regulation” twice. It also excludes, by design, three things a regulator will ask about:

Traditional cybersecurity attacks on the platform hosting the model, which NIST leaves to existing cyber taxonomies.
Design and implementation flaws that cause failures without an adversary, such as plain inaccuracy.
Risk tolerance, meaning the level of residual risk an organisation may accept.

None of this is a weakness of the document. A taxonomy that tried to be a law would date quickly and travel badly. But it means that adopting NIST AI 100-2 answers the question “what can go wrong?” and leaves open “what did you decide, on what evidence, and who signed?”. The EU AI Act asks precisely the second question. The rest of this guide builds that bridge, using the identifiers as the common key between your threat model, your tests and your AI security documentation.

NIST AI 100-2 and EU AI Act Article 15(5): the crosswalk

Article 15 of Regulation (EU) 2024/1689 requires high-risk AI systems to achieve an appropriate level of accuracy and cybersecurity, among other properties. Its paragraph 5 first requires resilience against attempts by unauthorised third parties to alter use, outputs or performance by exploiting vulnerabilities, then lists the AI-specific attacks to address: “The technical solutions to address AI specific vulnerabilities shall include, where appropriate, measures to prevent, detect, respond to, resolve and control for attacks trying to manipulate the training data set (data poisoning), or pre-trained components used in training (model poisoning), inputs designed to cause the AI model to make a mistake (adversarial examples or model evasion), confidentiality attacks or model flaws.”

Each of those terms has a home in NIST AI 100-2. The table below is our crosswalk; it is an interpretation, not an official mapping.

Article 15 term	NIST AI 100-2 classes and identifiers	Evidence to keep in the file
Data poisoning	<code>NISTAML.013</code>, <code>.012</code>, <code>.024</code>, backdoors <code>.021</code> and <code>.023</code>	Training data provenance, sanitisation records, poisoning tests, link to Article 10 data governance
Model poisoning (pre-trained components)	<code>NISTAML.011</code>, <code>.026</code>, supply chain <code>.051</code>	AI bill of materials, model hashes and provenance, supplier attestations
Adversarial examples or model evasion	<code>NISTAML.022</code>, <code>.025</code>; prompt injection <code>.018</code> and <code>.015</code> for generative systems (our reading)	Adversarial test plan and results, attack success rates, Annex IV testing section
Confidentiality attacks	<code>NISTAML.031</code> to <code>.039</code>	Extraction and inference tests, rate limiting and output filtering evidence, link to the GDPR impact assessment
Model flaws	Mostly outside the taxonomy (non-adversarial flaws are out of scope)	Accuracy and performance testing under Article 15(1) to (4)
Feedback loops (Article 15(4))	Poisoning through live inputs, <code>NISTAML.013</code> and <code>.024</code>	Input and drift monitoring, post-market monitoring and incident plan

Timing matters. After the Digital Omnibus, Regulation (EU) 2026/1744, Article 15 binds high-risk systems listed in Annex III from 2 December 2027 and those covered by Annex I product legislation from 2 August 2028. For general-purpose AI models with systemic risk the clock has already run: Article 55(1)(a) requires model evaluation “including conducting and documenting adversarial testing”, Article 55(1)(d) requires “an adequate level of cybersecurity protection”, both have applied since 2 August 2025, and the Commission has been able to fine providers since 2 August 2026. The Safety and Security chapter of the GPAI Code of Practice describes how signatories run those evaluations.

The European standards that will carry Article 15

NIST AI 100-2 gives the vocabulary; European standards will give Article 15 its testable content. Four instruments moved in 2026.

prEN 18282. The CEN-CENELEC JTC 21 draft European standard on cybersecurity for AI systems, written to support Article 15, completed its public enquiry between 15 May and mid-July 2026. Publication is targeted between the end of 2026 and early 2027, and it will only confer a presumption of conformity once cited in the Official Journal. The draft is confidential, so we refer to it by name and status only.

ETSI EN 304 223. Published on 14 January 2026, it sets 13 principles across five life-cycle phases (secure design, development, deployment, maintenance and end of life), building on ETSI TS 104 223. ETSI has announced TR 104 159 to apply it to generative AI.

ISO/IEC 27090:2026. The first edition of the ISO/IEC guidance on threats to AI systems was published in October 2026: 56 pages, guidance rather than certifiable requirements, covering poisoning, weight manipulation, evasion, extraction, membership inference, model inversion and prompt injection, as heise reported. It plugs into an ISO/IEC 27001 or ISO/IEC 42001 stack.

The Cyber Resilience Act route. Under Article 12 of Regulation (EU) 2024/2847, a high-risk AI system that is also a product with digital elements is deemed to meet the Article 15 cybersecurity requirements when it meets the CRA essential requirements and the protection level is shown in the CRA declaration of conformity; accuracy stays under the AI Act. The CRA reporting duty has applied since 11 September 2026: an early warning within 24 hours of becoming aware of an actively exploited vulnerability, a notification within 72 hours and a final report within 14 days of a corrective measure. AI Act Article 42(2) adds a separate presumption for systems certified under a Cybersecurity Act scheme.

All four enumerate the same attack classes as NIST AI 100-2, as does the older ENISA catalogue Securing Machine Learning Algorithms. Our reading: a register keyed on NISTAML identifiers can be relabelled for each standard instead of rebuilt, which is the cheapest way to stay ready for whichever one becomes harmonised first.

Turning NIST AI 100-2 into an evidence file

The procedure below is the one we recommend to teams preparing a conformity assessment or a GPAI model file. Each step produces a record an assessor can read.

Inventory and classify. List every AI system and component in a registry, then mark each as predictive, generative or agentic, and as high-risk, general-purpose or other. The part of NIST AI 100-2 you need follows from that classification.
Threat-model against the identifiers. For each system, go through the NISTAML identifiers and record which ones are plausible given realistic attacker capabilities: query access only, a fine-tuning API, retrieval from untrusted content, tool access. Discard the rest with a one-line reason.
Map identifiers to controls. For each retained identifier, name the controls that address it and the MITRE ATLAS techniques or OWASP entries that describe it in more detail.
Test. Run adversarial tests and red-team exercises scoped to the retained identifiers, with the tools NIST cites where they fit. Record method, scope, tool versions, success rates and fixes.
Decide the residual risk. For each identifier, write down the remaining exposure and who accepted it. This is the decision NIST AI 100-2 leaves aside and Article 9(5) requires.
Write the file. Annex IV point 2(h) asks the technical documentation to describe “the cybersecurity measures put in place”. Reference the identifiers there and in the Article 15 part of the declaration of conformity.
Monitor and report. Feed the register into post-market monitoring (Article 72) and serious incident reporting (Article 73), wire the CRA 24-hour early warning for exploited vulnerabilities, and review the whole set once a year, in step with the NIST update cycle.

Our AI risk management software keeps this chain (system, identifier, control, test, decision) in one record per system, so the evidence is ready when an assessor asks.

FAQ

Is NIST AI 100-2 mandatory in Europe?

No. NIST AI 100-2 is a voluntary US publication and states that it creates no legal requirement. In the EU the binding texts are the AI Act, mainly Article 15 for high-risk systems and Article 55 for general-purpose models with systemic risk, and the Cyber Resilience Act for products with digital elements. The taxonomy is still worth adopting because it gives precise names to the attack classes those laws describe in general terms, and assessors recognise them.

What changed between the 2023 and 2025 editions?

The 2025 edition added stable NISTAML identifiers (5 categories and 25 attack types by our count), renamed the generative “abuse” category to “misuse”, gave supply-chain attacks their own section, and added sections on agent security and benchmarks. Its reference list grew from 354 to 449 entries. The core structure, predictive versus generative AI and the attacker goals, capabilities and knowledge, is unchanged, so registers built on the 2023 edition can be upgraded rather than rebuilt.

Does NIST AI 100-2 cover AI agents?

Partly. The 2025 edition has a short section on the security of agents and treats indirect prompt injection and the compromise of connected resources as the main routes to hijack them. NIST itself says agent-specific security research is still at an early stage. For agentic deployments, combine the taxonomy with the OWASP agentic work and with tests built on agent benchmarks such as AgentDojo, and document tool permissions as part of your controls.

How does it relate to MITRE ATLAS and the OWASP Top 10 for LLM applications?

They work at different levels. NIST AI 100-2 defines classes and terminology; MITRE ATLAS catalogues concrete adversary tactics, techniques and case studies; the OWASP Top 10 ranks the most common weaknesses in LLM applications. In practice, use the NISTAML identifiers as the stable key of your register and attach ATLAS techniques and OWASP entries as detail. That way your file survives the regular revisions of both lists.

Is following NIST AI 100-2 enough for Article 15 of the AI Act?

No. The taxonomy tells you which attacks to consider, but Article 15 also expects appropriate and declared levels of accuracy and cybersecurity, resilience to errors and feedback loops, and documented measures. Article 9 requires a judgement that residual risk is acceptable, and Annex IV requires a written description of the cybersecurity measures. NIST AI 100-2 is a strong input to that file, not a substitute for it.

Why do NIST pages now say “Super Intelligence”?

A US executive order of 29 September 2026 told federal agencies to use “Super Intelligence” instead of “Artificial Intelligence” in their communications. NIST has relabelled web pages accordingly, including the NCCoE adversarial machine learning page, and renamed its control overlay project COSIS on 20 October 2026. NIST states that previously issued publications are unchanged, so NIST AI 100-2e2025 keeps its title and identifier. The order binds neither private companies nor European regulators.

Conclusion

NIST AI 100-2 is the closest thing the field has to a shared dictionary of attacks on AI systems, and the 2025 edition made it usable as a register key by giving every attack a stable identifier. What it does not do, by design, is tell you what to decide. The EU AI Act does: Article 15(5) names the same attack classes, Article 9 demands a residual risk decision and Annex IV demands a written account of your measures. Teams that key their threat model, tests and technical file on NIST AI 100-2 identifiers will be able to relabel that work for prEN 18282, ETSI EN 304 223 or ISO/IEC 27090 instead of starting again. Start with the inventory and the threat model this quarter: the GPAI duties already apply, and the high-risk deadline of 2 December 2027 leaves less time than it seems.

Dr. Sarah Mitchell

AI Governance & Risk Lead at AI Sigil. Sarah holds a PhD in Computer Science from Imperial College London with a thesis on machine learning model interpretability. Before joining AI Sigil she spent six years in Deloitte's AI Risk Advisory practice, leading high-risk AI system audits across financial services and healthcare. She is IAPP AIGP certified and a frequent contributor to industry working groups on the EU AI Act and NIST AI Risk Management Framework. Based in London.