NIST AI 100-2 Adversarial ML Taxonomy Guide

Teams that test, buy or regulate AI systems keep talking past each other because "poisoning", "jailbreak" and "prompt injection" mean different things to different people. NIST AI 100-2 E2025, "Adversarial Machine Learning: A Taxonomy and Terminology of Attacks and Mitigations", is NIST's answer: a shared vocabulary that classifies attacks on predictive and generative AI by lifecycle stage, attacker goal, capability and knowledge, with stable identifiers such as NISTAML.015 for indirect prompt injection. This guide explains how the taxonomy is built, what each attack class means in practice, how to use it for threat modelling, test plans and contracts, and how it lines up with MITRE ATLAS and OWASP. It is for AI security engineers, red teams, assurance teams and buyers. For the attack technique knowledge base see the MITRE ATLAS Guide.

Key takeaways

It is a taxonomy, not a control standard. NIST AI 100-2 defines attack classes and terms and discusses mitigations and their limits; it sets no compliance requirements.
Four dimensions classify every attack. Lifecycle stage (training or deployment), attacker goal (availability, integrity, privacy, plus misuse for generative AI), attacker capability and attacker knowledge.
The 2025 edition puts generative AI and agents in scope. It adds identifiers for prompt injection, indirect prompt injection, prompt extraction and compromising connected resources, and a section on the security of agents.
NIST is candid about mitigation limits. The report describes many mitigations as empirical and limited, and possibly vulnerable to new attack techniques, so testing must be adaptive.
Use the NISTAML identifiers as a common key. Tag threat models, test cases, findings and vendor questions with them, then cross-reference ATLAS techniques for detail.

What it is and who it applies to

NIST AI 100-2 is part of NIST's Trustworthy and Responsible AI report series. The current edition, E2025, was published as Final on 24 March 2025 (a corrected PDF followed on 1 April 2025). Its authors are from NIST, Northeastern University, Cisco, the UK AI Security Institute and the US AI Safety Institute. It follows the E2023 edition published in January 2024. On 3 June 2025 NIST noted an error on page x and published a list of potential updates for a future revision, so check the publication page for errata.

Status: voluntary guidance. No regulator mandates it, but it is the vocabulary NIST uses in its other AI work and is widely cited in standards and procurement.
Audience: anyone who needs to describe AI attacks precisely: model developers, application builders, red teams, assessors, standards writers and policy makers.
Scope: predictive AI (classifiers, regressors, detectors) and generative AI (large language models and multimodal models, including retrieval-augmented and agentic applications).
Out of scope: it does not prescribe a risk management process (that is the NIST AI RMF Guide territory) or a control baseline.

Structure and key requirements

The report is organised in four parts: an introduction, a predictive AI taxonomy (Section 2), a generative AI taxonomy (Section 3), and key challenges and discussion (Section 4), followed by a glossary.

The classification dimensions

Dimension	Values in the taxonomy	Why it matters to defenders
Stage of learning	Training time (poisoning) or deployment time (evasion, privacy, prompting)	Tells you whether the defence belongs in the data and training pipeline or at inference
Attacker goal	Availability breakdown, integrity violation, privacy compromise; for generative AI also misuse	Maps to impact and to which owner cares (operations, safety, privacy, trust and safety)
Attacker capability	Training data control, model control, testing data control, label limit, source code control, query access	Each capability corresponds to an access path you can restrict
Attacker knowledge	White box, black box, grey box	Sets realistic test assumptions; most deployed systems face black-box or grey-box attackers
Data modality (predictive AI)	Image, text, audio, video, cyber security data, tabular, multimodal	Attacks and mitigations differ by modality

Predictive AI attack classes

Evasion (NISTAML.022, black-box evasion NISTAML.025): crafted inputs at deployment that cause misclassification, for example malware or phishing that slips past an ML detector. The report discusses white-box and black-box attacks, transferability between models and real-world cases. Mitigations covered include adversarial training, randomised smoothing and formal verification.
Poisoning: availability poisoning (data poisoning NISTAML.013, clean-label NISTAML.012), targeted poisoning (NISTAML.024), backdoor poisoning (NISTAML.023, clean-label backdoor NISTAML.021) and model poisoning (NISTAML.011, NISTAML.026), including supply chain model poisoning (NISTAML.051).
Privacy compromises (NISTAML.03): model extraction (NISTAML.031), data reconstruction (NISTAML.032), membership inference (NISTAML.033) and property inference (NISTAML.034).
Energy-latency (NISTAML.014): an availability attack that drives up compute cost or response time.

Generative AI attack classes

Section 3 covers supply chain attacks (data and model poisoning), direct prompting attacks including information extraction, indirect prompt injection with availability, integrity and privacy outcomes, the security of agents, and benchmarks for measuring these vulnerabilities. The identifiers that matter most for application teams are below.

Identifier	Name in the index	Goals it appears under	Practical example
NISTAML.018	Prompt Injection	Availability, integrity, privacy, misuse	A user crafts input that overrides system instructions or safety training
NISTAML.015	Indirect Prompt Injection	Availability, integrity, privacy	Instructions hidden in an email or web page the assistant retrieves
NISTAML.035	Prompt Extraction	Privacy	Recovering the system prompt
NISTAML.036	Leaking information from user interactions	Privacy	One user's conversation data surfacing to another
NISTAML.037 and NISTAML.038	Training Data Attacks; Data Extraction	Privacy	Extracting memorised training data
NISTAML.039	Compromising connected resources	Privacy	An agent's tools or data stores reached through the model
NISTAML.027	Misaligned Outputs	Integrity	Outputs that diverge from intended behaviour
NISTAML.013, .023, .024	Data, backdoor and targeted poisoning	Integrity (and others)	Poisoned fine-tuning data or a backdoored open-weight model

The index has no separate entry for "jailbreak"; jailbreaking falls under direct prompting and prompt injection (NISTAML.018) with a misuse goal. Using NIST's terms in your test plans avoids arguments about whether a finding is a "jailbreak" or an "injection".

Key challenges NIST calls out

Section 4 discusses trade-offs between attributes of trustworthy AI (for example robustness against accuracy), theoretical limits on adversarial robustness, the difficulty of evaluation, scale, supply chain challenges, multimodal and quantised models, and how to manage risk given that no defence is complete. NIST's Center for AI Standards and Innovation showed the evaluation problem concretely in January 2025: in AgentDojo tests, new red team attacks raised hijacking success on held-out tasks from 11% to 81%, and allowing 25 attempts per attack raised average success from 57% to 80%.

Identity and NHI requirements

The report does not set identity requirements, but its capability dimension maps directly onto non-human identities. Each capability an attacker needs is usually granted by a credential.

Query access: inference API keys and tokens. Extraction and membership inference need many queries, so per-key rate limits, quotas and anomaly detection on query patterns are real controls. Stolen keys also enable cost abuse. See the LLMjacking Guide.
Training data control: write access to data lakes, labelling platforms and dataset repositories. Scope service accounts that feed training pipelines and log every write.
Model control and source code control: tokens for model registries, Hugging Face organisations, CI pipelines and repositories. A leaked registry token is a model poisoning path (NISTAML.051).
Compromising connected resources (NISTAML.039): the agent's own OAuth tokens and API keys. Indirect injection turns the agent's credentials into the attacker's, which is why agent identities need least privilege and short lifetimes. See the Agent Identity and Access Guide.

Implementation steps

Inventory AI systems by type: mark each as predictive or generative, and note whether it retrieves external content, holds tools or is retrained on user data. This decides which half of the taxonomy applies.
Threat model with the dimensions: for each system, record which attacker capabilities are realistic (query access is almost always present) and which knowledge level to assume. Tag each threat with its NISTAML identifier. The AI Agent Threat Modelling Guide shows the agent side.
Cross-reference ATLAS: attach the matching ATLAS techniques to each NISTAML class for procedure detail and mitigations (see the mapping table below).
Close capability paths first: restrict and monitor the credentials behind each capability (training data writes, registry tokens, inference keys, agent tool credentials). These are deterministic controls that do not depend on model robustness.
Write test cases per class: build a test plan that names the NISTAML class, the goal tested and the knowledge assumption. Include repeated attempts and adaptive attacks, as CAISI's work shows single-shot tests understate risk.
Pilot, then gate releases: run the plan against one system, fix findings, then make the plan a release gate for models and AI applications. Keep the previous model version available to roll back if a new one fails.
Use the vocabulary in contracts: ask suppliers which NISTAML classes they test against and how. See the AI Procurement Checklist.

Which classes apply to which system

System type	Priority classes	Realistic attacker capability	First controls
ML detector (fraud, malware, spam)	Evasion, availability and targeted poisoning	Query access; testing data control; sometimes training data control through feedback loops	Robustness testing, feedback-loop data review, drift monitoring
Model trained on customer or personal data	Membership inference, reconstruction, model extraction	Query access, black box	Rate limits per key, output minimisation, privacy testing before release
Chat assistant on a hosted LLM	Prompt injection, prompt extraction, misuse	Query access	No secrets in system prompts, abuse monitoring, refusal testing
Retrieval-augmented assistant	Indirect prompt injection, leaking information from user interactions	Control of content the system retrieves	Source trust labelling, per-user retrieval permissions, output link filtering
Agent with tools	Indirect prompt injection, compromising connected resources	Control of any content the agent reads	Least-privilege tool credentials, approval gates, tool-call logging
Fine-tuned or open-weight model	Data, backdoor and supply chain model poisoning	Training data control, model control	Provenance checks, model signing, registry access control

Small organisations that only consume hosted models can usually focus on the last four rows and push the training-time classes to the provider through contract questions. Organisations that train or fine-tune models own the whole table.

Evidence and assessment

Because AI 100-2 is a taxonomy, assessment means showing that your threat models, tests and monitoring cover its classes. Evidence an assessor can check:

Threat model records: each AI system has threats tagged with NISTAML identifiers and stated capability and knowledge assumptions.
Test reports: red team and evaluation results per class, with attack success rates, number of attempts and model version. See the AI Red Teaming Guide.
Telemetry: logs of inference queries per key, retrieved content sources for retrieval-augmented systems, agent tool calls, and dataset and model registry writes.
Supply chain records: provenance and integrity checks for datasets and models.

Metric	What it shows
Share of AI systems with a NISTAML-tagged threat model	Coverage of the taxonomy across the portfolio
Attack success rate per class, single attempt and best of N attempts	Robustness trend per release, not a one-off score
Indirect prompt injection success on agent tasks with write tools	Residual risk where impact is highest
Inference keys with rate limits and anomaly alerts	Protection against extraction and inference attacks
Models and datasets with verified provenance before deployment	Supply chain poisoning exposure

Mapping to other frameworks

NIST AI 100-2 class	MITRE ATLAS	OWASP Top 10 for LLM Applications 2025	NIST SP 800-53 Rev. 5 controls
Evasion (NISTAML.022, .025)	AML.T0015 Evade AI Model; AML.T0043 Craft Adversarial Data	Not a primary LLM risk	SA-11 Developer Testing and Evaluation, CA-8 Penetration Testing
Data and backdoor poisoning (NISTAML.013, .021, .023, .024)	AML.T0020 Poison Training Data; AML.T0018.000 Poison AI Model	LLM04 Data and Model Poisoning	SI-7 Software, Firmware, and Information Integrity
Supply chain model poisoning (NISTAML.051)	AML.T0010 AI Supply Chain Compromise	LLM03 Supply Chain	SR-3 Supply Chain Controls and Processes, SR-11 Component Authenticity
Model extraction (NISTAML.031)	AML.T0024.002 Extract AI Model	LLM10 Unbounded Consumption (model theft through queries)	AC-6 Least Privilege, SC-7 Boundary Protection
Membership inference and reconstruction (NISTAML.033, .032)	AML.T0024.000 Infer Training Data Membership; AML.T0024.001 Invert AI Model	LLM02 Sensitive Information Disclosure	RA-3 Risk Assessment
Prompt injection (NISTAML.018)	AML.T0051.000 Direct; AML.T0054 LLM Jailbreak	LLM01 Prompt Injection	SI-10 Information Input Validation
Indirect prompt injection (NISTAML.015)	AML.T0051.001 Indirect	LLM01 Prompt Injection, LLM06 Excessive Agency	AC-4 Information Flow Enforcement
Prompt extraction (NISTAML.035)	AML.T0056 Extract LLM System Prompt	LLM07 System Prompt Leakage	AC-3 Access Enforcement (keep secrets and authorisation logic out of prompts)
Energy-latency (NISTAML.014)	AML.T0029 Denial of AI Service	LLM10 Unbounded Consumption	SC-5 Denial-of-Service Protection

The EU AI Act's Article 15 on accuracy, robustness and cybersecurity of high-risk systems names data poisoning, model poisoning, adversarial examples and confidentiality attacks, which line up with the poisoning, evasion and privacy classes here. See the AI Security Frameworks Crosswalk Guide for the wider map.

Common pitfalls

Treating the taxonomy as a checklist of controls: it names attacks; you still need a control set and risk process around it.
Testing only white-box or only single-shot: results then misstate real exposure. Use the knowledge dimension and repeat attempts as CAISI did.
Ignoring predictive AI: fraud models, malware classifiers and spam filters face evasion and poisoning even when no LLM is involved.
Missing the connected-resources class: teams test whether a model says something harmful but not whether indirect injection can use its tools. In EchoLeak 2025 an email carrying hidden instructions caused Microsoft 365 Copilot to place internal data into an image URL.
Trusting allowlisted channels: ForcedLeak 2025 exfiltrated CRM data through an expired domain still on a content security policy allowlist, a privacy compromise through indirect injection.
Citing the wrong edition: E2023 has no agent section and fewer generative AI identifiers. Reference E2025 and check the errata list.

Practitioner checklist

Reference NIST AI 100-2 E2025 (DOI 10.6028/NIST.AI.100-2e2025) and track its errata and revisions.
Classify every AI system as predictive or generative and note retrieval, tools and retraining.
Tag every AI threat, test case and finding with a NISTAML identifier.
State capability and knowledge assumptions in every threat model and test plan.
Map each NISTAML class to ATLAS techniques and to your controls.
Restrict and monitor the credentials behind each attacker capability, especially agent tool tokens and model registry tokens.
Measure attack success per class with repeated and adaptive attempts at each release.
Ask suppliers which NISTAML classes they test and request the evidence.

Adversarial ML Taxonomy Guide: Using NIST AI 100-2 to Classify and Defend Against AI Attacks