NIST AI 100-2e2025,Adversarial Machine Learning: A Taxonomy and Terminology of Attacks and Mitigations, is a U.S. federal report published inMarch 2025in the NIST Trustworthy and Responsible AI series. Its authors includeApostol Vassilev (NIST), Alina Oprea (Northeastern University), Alie Fordyce and Hyrum Anderson (Cisco), Xander Davies (U.K. AI Security Institute) and Maia Hamin (U.S. AI Safety Institute). It is free of charge and explicitly voluntary: the report states it does not establish any legal standard and is not intended to supersede existing regulations, laws or other mandatory guidance. Its scope is adversarial machine learning — attacks that exploit the statistical, data-based nature of ML systems — not the traditional cybersecurity of the platforms those systems run on.
How the taxonomy is structured
The report separates two broad classes of systems: predictive AI and generative AI. It then classifies attacks relative to five things: the AI system type; the stage of the ML life cycle; the attacker'sgoals and objectives; the attacker'scapabilitiesand access; and the attacker'sknowledgeof the learning process.
The life cycle has atraining stage(where poisoning lives) and adeployment stage(where evasion, availability and privacy attacks live). Attacker objectives are the three classic security violations —availability breakdown, integrity violation and privacy compromise— plus a generative-AI-specific fourth:misuse enablement, in which the attacker tries to circumvent restrictions the system owner placed on outputs. Attacker knowledge runs fromwhite-box(full knowledge, including weights) through gray-box to black-box. The volume closes with a glossary and an index of attacks carrying IDs such as NISTAML.022.
Four categories, translated for LLM deployers
The report's own keyword list names exactly four attack terms:evasion, data poisoning, privacy breach and abuse. Below, each is translated into a concrete risk an LLM deployment team should check, and the mitigation direction the document points to.
1. Evasion: the input that flips a model's decision
An evasion attack modifies a test sample at deployment time to create anadversarial examplethat the model misclassifies while often staying imperceptible to humans. The report traces these from the mid-2000s to the 2013 image-classification results that gave the field its name, and to methods such as FGSM, PGD, DeepFool and the Carlini-Wagner attack. Two properties matter operationally:transferability, where examples generated on one model fool another, anduniversalperturbations that work on most inputs.
What to check:if you deploy an ML classifier or a model-based guardrail (spam, fraud, content moderation, prompt-injection detection), assume adversarial inputs can bend its decisions; and because open-weight models give attackers white-box access, triggers learned on them can transfer to your closed API.Mitigation direction:adversarial training, certified techniques such as randomized smoothing, and formal verification — while warning these carry real costs (lower accuracy, higher compute) and must be evaluated against strong adaptive attacks, not weak ones.
2. Data poisoning: corrupting the model before it ships
Poisoning attacks happen at training time. The report distinguishes availability poisoning (degrading the whole model), targeted poisoning, backdoor poisoning (a trigger pattern causes a chosen misclassification) and model poisoning (common in federated learning and in supply chains where a third party supplies the model). For generative AI it adds data poisoning of web-scraped pre-training corpora — including buying expired domains listed in a training set — and model poisoning of third-party foundation models whose backdoors can survive downstream fine-tuning and even additional safety training. Instruction tuning and RLHF are named as further injection points; a poisoned trigger phrase can act, in the report's words, as a universal jailbreak.
What to check:any team that fine-tunes on scraped or crowd-sourced data, or drops in a third-party model, inherits these risks.Mitigation direction:verify web downloads against published cryptographic hashes, use data sanitization and provenance attestation, inspect models before deployment (trigger reconstruction and model-inspection defenses), and treat models as untrusted components.
3. Privacy breach: leaking data through the model
Privacy compromises cover both training data and the model itself. Named attacks include data reconstruction, membership inference, property inference and model extraction. For generative models the report adds training-data extraction, prompt and system-prompt extraction, leakage from user interactions, and compromising connected resources — where an attacker makes the model expose private data it can reach.
What to check:an LLM can memorize and regurgitate training or RAG data, and your system prompt and connectedMitigation direction: differential privacy is the report's strongest named defense against reconstruction and membership inference, complemented by empirical privacy auditing with canaries; also limit and rate-limit queries, and design systems assuming the model may leak whatever it can access. Note the caveats: differential privacy does not protect against model extraction, and machine unlearning and watermarking remain fragile.
4. Abuse: jailbreaks and prompt injection
This is the generative-AI-specific category. Direct prompting attacks come from the system's own user; a jailbreak is a direct prompting attack that circumvents restrictions on outputs. The report catalogues techniques: competing-objectives tricks (prefix injection, refusal suppression, style injection, role-play) and mismatched-generalization tricks (special encoding such as base64, character and word transformation, token smuggling, translation into low-resource languages), plus automated model-based red teaming and multi-turn attacks. Indirect prompt injection is mounted by a third party through the data channel — poisoned RAG knowledge bases, execution triggers, hidden injections and even self-propagating worm-style emails — and can cause availability, integrity or privacy violations in an internet-connected chatbot or agent, including hijacking the agent's tool calls.
What to check: whether your chatbot can be talked out of its safety alignment, and whether any untrusted text it ingests (documents, web pages, emails) can redirect it or exfiltrate data. Mitigation direction: the report stresses defense-in-depth and, critically, designing on the assumption that injection is possible — separating instructions from data (spotlighting, wrapping), detectors and monitoring, safety and adversarial training, continuous red-teaming, and least-privilege agents (multiple models with different permissions and well-defined interfaces). It warns that current mitigations do not offer full protection.
The catch
Two framing warnings carry over from the report. First, advances in mitigation are empirical and limited in nature, and there are no information-theoretic security proofs for the ML algorithms in modern AI systems. Second, mitigations trade off against other trustworthy-AI attributes: robustness versus accuracy, and robustness versus fairness. The report makes no risk-tolerance recommendations because those are application-specific. A taxonomy is a checklist, not a guarantee.
Sources: NIST AI 100-2e2025 (CSRC); full PDF.