NIST adversarial ML taxonomy (AI 100-2e2025) explained

What NIST AI 100-2e2025 is and whether your team must use it

NIST AI 100-2e2025 is a free, published taxonomy and terminology of attacks and mitigations against machine learning systems, released in March 2025. It is not a certification, an accreditation scheme or a required control set, so no regulator or assessor can certify a team against it. Customers and internal programs ask for it because it gives security, risk and procurement teams a shared vocabulary for adversarial ML attacks and the mitigations NIST associates with them. The publication sits alongside the AI Risk Management Framework, which NIST describes as voluntary. NIST does not validate or endorse any organization's use of the AI RMF, and the taxonomy does not change that. Its value is practical: it names attack classes, identifies attacker objectives and lists mitigations with their limits, so your team can write threat models, control descriptions and test cases in terms a customer or auditor will recognize. The organization still owns its controls, and only an independent assessor or auditor issues any report on them. If a contract asks for adversarial ML coverage, confirm in writing what the customer means by coverage, whether a mapping to specific controls is expected, and which evidence they will accept.

Your team does not have to use the taxonomy, but a documented decision not to use it should be explained. Ask who will own the mapping from your AI systems to the attack classes, which predictive and generative systems fall in scope, and how mitigations will be tested rather than assumed. Plan for the publication to be revised, since NIST says it intends to update the report as new attacks and mitigations emerge, so record the version you used. For organizations building on an AI RMF program, the taxonomy feeds the Measure and Manage work, where you decide which risks to test and how to respond. An implementation partner can prepare systems, test plans and evidence against your chosen vocabulary, but the organization decides what is accepted as sufficient.

How attacker objectives and NISTAML identifiers organize the attacks

NIST AI 100-2e2025 sorts generative AI attacks by what the attacker wants and gives each attack class a stable identifier. Together these two layers let a security team describe a finding precisely, route it to the right control owner and track it across test cycles.

Availability breakdown

The first generative AI attacker objective is availability breakdown, where an attacker degrades or stops the system from serving its intended users. For a deployed model this can mean resource exhaustion through crafted prompts, or inputs that drive the system into long or failing responses. When you review a test result, check whether the finding actually reduces service for legitimate users, and record the measured effect on latency, error rates or throughput so the impact is not left to judgment.

Integrity violation

An integrity violation objective means the attacker causes the system to produce outputs or behavior that the owner did not intend, while the service still appears to run normally. Prompt-driven manipulation of answers, tool calls or retrieved content can all fall here. For each finding, confirm which output or action changed, what the expected behavior was, and whether a downstream system trusted the altered result without a check.

Privacy compromise

A privacy compromise objective covers attacks that extract information the attacker should not have, such as training data, personal data or confidential instructions held by the system. Tests in this group ask whether the model can be induced to reveal stored content, and whether retrieval or logging exposes data to users outside their permissions. Record the data categories involved, since they determine the notification and legal review that follows.

Misuse enablement

Misuse enablement is the objective that NIST treats as specific to generative AI: the attacker uses the system to produce content or capabilities that help with harmful activity against others. Because the model may function as intended while producing the harmful output, this objective sits closer to content and use policy than to classic security defects. Ask whether your acceptable use terms, output filters and monitoring address it, and who decides what counts as misuse in your environment.

NISTAML.05 for supply chain attacks

The identifier NISTAML.05 labels supply chain attacks, meaning compromise through third-party data, pre-trained models or other components that the AI system depends on. When a finding involves a poisoned dataset or a tampered model artifact, tag it with this identifier so it reaches the procurement and model intake owners. Pair the tag with the component name and version, which lets the team check every other system that uses the same artifact.

NISTAML.018 and NISTAML.015 for prompt attacks

NISTAML.018 labels direct prompting attacks, where the user supplies the malicious instruction, and NISTAML.015 labels indirect prompt injection, where the instruction arrives inside content the system reads, such as a web page, document or tool output. Separating the two in a ticket matters because the direct case is handled at the input boundary, while the indirect case also needs controls on retrieved content and tool permissions. Confirm the identifier against the current NIST AI 100-2e2025 text before a report is finalized.

What the taxonomy leaves out and where to look instead

The taxonomy has three explicit boundaries, and the first one matters most for scoping. NIST AI 100-2e2025 focuses on attacks that exploit the statistical, data-based nature of machine learning systems. Attacks on the platforms AI runs on, such as the servers, containers, identity systems and networks around a model, are treated as covered by traditional cybersecurity taxonomies. Security teams should therefore map those infrastructure risks to their existing control catalogs instead of expecting the report to classify them. A practical check is to list each AI asset and mark which failure modes are statistical (poisoned training data, evasion inputs, inference leakage) and which are conventional (host compromise, credential theft, misconfigured storage).

The second boundary is decision-making. The report deliberately leaves aside how organizations decide what level of AI risk they will accept, so it does not tell you who approves a deployment or when a system must be stopped. For that, use the AI RMF Govern function, which covers accountability, policies and risk culture, and the Manage function, which covers go or no-go determinations, risk treatment and residual risk documentation. For assessing risks such as adversarial attacks in a generative AI setting, NIST points to its Generative AI Profile (NIST AI 600-1), which maps to the AI RMF. Confirm with the profile's suggested actions which ones apply to your system before writing those actions into your risk register.

The report also makes no claim to be an exhaustive survey. NIST notes that the adversarial machine learning literature is very large, with more than 11,354 references on arXiv.org since 2021 as of July 2024, and that the taxonomy is a snapshot NIST intends to update. Treat it as a shared vocabulary and a starting point for threat modeling, not as a complete inventory of attacks. Before relying on a specific attack or defense in a control design or a customer answer, confirm that it is still current in NIST's latest publication and in the research your security team tracks.

Why NIST says mitigations remain empirical and what that means for testing

AI 100-2e2025 notes that widely used machine learning algorithms have no information-theoretic security proofs. In practice, a mitigation against evasion, poisoning, privacy or prompt injection attacks is a measured claim about observed behavior, and that claim can stop holding when an attacker finds a new technique. Engineers therefore treat each mitigation as a hypothesis to retest rather than a closed control.

Test against the attack classes named in the taxonomy: Map each deployed mitigation to the NISTAML attack class it targets, then run attacks from that class against the live configuration.
Retest after every change: Model updates, retraining, new data sources, prompt template edits and tool additions can each invalidate earlier results, so keep the test suite runnable on demand.
Track adaptive attacks: Include attacks designed to defeat the specific mitigation, not only generic attacks, because a defense tuned to known inputs is the weakest point in an empirical result.
Record negative results: Keep failed attacks, partial bypasses and false positive rates with the test version, so later reviews can see what was tried.
Use public benchmarks as a starting point: Benchmarks show known weaknesses but do not prove a system safe, so add tests for the system's own data and tools.

Confirm with your testing lead which attack classes your deployed system exposes before setting the suite scope.

How security teams use the taxonomy in an AI security program

The sequence turns NIST AI 100-2e2025 from a reference document into a working record: which AI systems face which attack classes, which mitigations were chosen and how far they are known to hold, and what risk remains for the AI RMF Measure and Manage functions to govern. Each step ends with a named artifact that an assessor or internal reviewer can inspect.

Build the AI system inventory
The security or AI governance lead, working with the teams that build and run models, lists every AI system in scope, including predictive models, generative AI applications, third-party APIs and pre-trained models pulled into pipelines. For each entry, record the system's purpose, data sources, hosting location, owners and whether it accepts untrusted input. The step is complete when the inventory is reviewed against the cloud accounts, repositories and data platforms it draws from, so that no system is known only to one team. The output is the AI system inventory, which feeds the AI RMF Map function.
Map systems to attack classes
Security engineers read the taxonomy section that matches each system's architecture. A predictive model is checked against evasion, poisoning and privacy attacks. A generative system is checked against supply chain poisoning, direct prompting and indirect prompt injection, and against the attacker objectives the report lists, including misuse enablement. Each relevant class is recorded with its NISTAML identifier, such as NISTAML.05 for supply chain attacks or NISTAML.015 for indirect prompt injection. The step is complete when every system has a documented set of applicable classes and a short note on why the others were excluded. The output is the attack-class register.
Select mitigations and record their limits
For each attack class in the register, the security lead chooses the mitigation families the report describes and records the limits it states alongside them. The report says most mitigations for adversarial ML are empirical and can be defeated by new techniques, so the record should say what each control reduces, what it does not, and how the team will know it has weakened. Platform-level threats such as compromised hosts or container images remain under traditional cybersecurity controls and are tracked there. The output is a mitigation decision record for each system, reviewed by the system owner and the risk owner.
Test mitigations with self-hosted tooling
Testers run attacks from the taxonomy against each system in a controlled environment, usually one the organization hosts itself, so that prompts, datasets, model artifacts and logs stay under its control. They use the tools the team has selected and record the version, configuration, test inputs and results so the run can be repeated. Testing should cover both the mitigations and the system's ability to detect attempted attacks, since the taxonomy treats these as separate questions. The step is complete when each mitigation has a test result, including failures. The output is a test record per system and attack class. Confirm with the testing vendor or open-source project which attack types its tooling supports before relying on it.
Document residual risk in Measure and Manage
The AI risk owner takes the test records and the mitigation decisions and states the residual risk for each system: what attack classes remain, how likely the owner judges them and what impact they would have. The Measure function is used to set the metrics and evaluations that track whether the residual risk changes, and the Manage function is used to set the go or no-go determination, treatment priorities and monitoring plans. The residual risk statement must name who accepted it and when it will be reviewed. The output is a residual risk register entry for each system, linked to the Measure and Manage records in the organization's AI RMF program.
Recheck when NIST revises the report
NIST states that it intends to update AI 100-2e2025 as new attacks and mitigations emerge, so the team assigns an owner to watch for new versions and to compare them against the register. When a revision is published, that owner checks each NISTAML identifier and mitigation entry for changes, adds any new attack classes to the register and reruns affected tests. The owner also records whether any change alters a residual risk decision. The step is complete when the change log shows what was reviewed and what was updated. The output is a dated revision review, kept with the attack-class register so auditors can see how the program followed the source.

What teams need in place before mapping attacks to their systems

AI 100-2e2025 gives teams a shared vocabulary of attack classes, but the taxonomy only helps once someone can say which systems exist, what they are built from, who answers for them, and how findings get recorded. The cards below cover the six prerequisites that connect the taxonomy to real systems and to evidence that an assessor can check.

Current inventory of AI systems

Every attack class in the taxonomy applies to a specific system, so the first check is a register of AI systems in use, built, or bought, including shadow deployments by business units. For each entry, confirm the model type (predictive or generative), the data it trains or retrieves from, the interfaces that accept input, and the systems it can call. An inventory that omits a chatbot or an embedded vendor feature leaves prompt injection and poisoning questions unanswered for that system.

Data and model provenance

Poisoning and supply chain attacks start before deployment, in training data, pre-trained weights, fine-tuning sets and plugins. For each component, record where it came from, who supplied it, the version or hash used, and how it was validated on intake. Ask vendors for documentation on data sources and training provenance. Where provenance is unknown, the taxonomy's supply chain classes should be treated as open risks until a mitigation is documented.

A named owner for each system

Each AI system needs one accountable owner who can accept or reject a finding, approve a mitigation, and decide whether a system keeps running while a problem is open. The owner should be named in the inventory and in the findings log. Check that the owner can actually change the system's configuration or data, since a mitigation that no one can implement will not appear as evidence.

A test environment that reproduces attacks

Teams need a non-production environment that mirrors the deployed model, retrieval sources, tools and access controls closely enough that an evasion, poisoning or prompt injection test means the same thing it would in production. Confirm that test data is isolated from live data, that model and configuration versions are pinned, and that test runs can be repeated. NIST notes that mitigations are empirical, so reproducibility is what lets a team show that a mitigation still holds after a change.

A findings log tagged with NISTAML identifiers

Each finding should be recorded with the attack class it matches, such as NISTAML.05 for supply chain attacks, NISTAML.018 for direct prompting or NISTAML.015 for indirect prompt injection, along with the system, the attacker objective (availability breakdown, integrity violation, privacy compromise or misuse enablement), the mitigation chosen and its stated limits. Check that the log can be filtered by identifier and by owner, so that the same class of finding across several systems can be reviewed together.

A review cadence tied to NIST updates

NIST states that it intends to update the report as new attacks and mitigations emerge, so the taxonomy and the mappings built on it will change. Set a scheduled review of the attack classes, the log entries and the mitigations in use, and add an unscheduled review when NIST publishes a new edition. Record which edition each mapping was built against, so an assessor can see whether the team's view was current when a decision was made.

Questions teams ask about the NIST adversarial ML taxonomy

Is the NIST adversarial machine learning taxonomy mandatory for our AI systems?

No requirement in the supplied material makes NIST AI 100-2e2025 a legal or contractual obligation. The publication is a taxonomy and terminology reference that NIST published in March 2025, and it is free of charge. Its parent framework is also voluntary: NIST's AI RMF FAQ says neither private nor public sector organizations are required to use the AI RMF. Whether a regulator, customer or contract expects adversarial ML coverage is a separate question. Ask the party requesting evidence which document and clause they mean, and read the requirement against the taxonomy's own terms before you scope the work. Effort depends on the number and complexity of AI systems in scope.

Does the adversarial ML taxonomy come with a certification or audit?

No. The supplied facts describe no certification, accreditation or conformity assessment program for this taxonomy. The AI RMF has none either, and NIST states that it does not validate or endorse any organization's approach to using the framework. Any evidence that your controls work has to be assessed by an independent party that you select. DeployOpen prepares systems, controls and evidence for assessments, but it does not issue audit reports, attestations or certifications. Independent auditors and certification bodies do that work. If a provider offers a certificate against this taxonomy, ask for the name of the issuing body and its accreditation.

How does the adversarial ML taxonomy relate to the NIST AI RMF?

The taxonomy describes attacks, attacker objectives and mitigations, and it deliberately leaves aside how organizations make decisions about AI risk. For that decision-making, it points to NIST's Generative AI Profile (NIST AI 600-1, July 26, 2024), which maps to AI RMF subcategories and lists suggested actions, including for adversarial attacks. In practice, the AI RMF supplies the governance and risk process across Govern, Map, Measure and Manage. The taxonomy supplies the shared attack vocabulary that teams use when they identify, test and record adversarial risks inside that process. Most organizations use both together rather than choosing one.

Can our own security team apply the taxonomy without outside help?

Yes, for much of the work. Because the report is free, internal teams can use its attack classes, NISTAML identifiers and attacker objectives to build threat models, risk registers and test plans. Internal teams usually handle the inventory of predictive and generative systems and the mapping of each system to relevant attack classes. Harder tasks include designing tests for poisoning, evasion and prompt injection, and checking whether a mitigation holds, because NIST says most mitigations are empirical. Teams that lack adversarial testing experience often choose external help for those steps. Effort depends on the number and complexity of AI systems in scope.

What does outside help cover for adversarial ML work, and what does it not cover?

An implementation partner can help with scoping, preparing systems and documentation, mapping evidence to attack classes, AI and agent security testing, red teaming and remediation. DeployOpen works this way under fixed-scope engagements, where scope, deliverables and timelines are agreed in writing before work starts. Outside help does not cover the organization's own risk acceptance decisions, legal conclusions about which requirements apply, or the issuance of an audit report. It also cannot guarantee that a mitigation will hold against future attacks, because NIST says mitigations may be defeated by new attacker techniques. Ask each quote to list the systems in scope, the test types, the deliverables and who signs off.

How often does NIST update the adversarial ML taxonomy?

NIST says it intends to update the report as new attacks and mitigations emerge. The supplied material gives no fixed release schedule, so do not assume an annual or periodic cycle. The report is also not an exhaustive survey: the literature it draws on included more than 11,354 adversarial ML references on arXiv.org since 2021, as of July 2024. Before you write evidence or test cases against it, confirm the current edition on NIST's publication site and record the edition number in your documentation. Changes in attack classes or identifiers can affect existing test coverage, so review your mapping whenever a new edition appears.

Which attacks does the taxonomy cover, and which does it leave out?

For predictive AI, the taxonomy covers evasion, poisoning and privacy attacks. For generative AI, it covers supply chain poisoning, direct prompting and indirect prompt injection, with mitigations and their limits for each. Identifiers include NISTAML.05 for supply chain attacks, NISTAML.018 for direct prompting and NISTAML.015 for indirect prompt injection. It focuses on attacks that exploit the statistical, data-based nature of ML systems. Attacks on the platforms AI runs on are treated as part of traditional cybersecurity taxonomies, so hardening your hosting, identity, network and pipeline controls still needs its own coverage.

How DeployOpen prepares AI security evidence and testing

DeployOpen works on the NIST adversarial machine learning taxonomy as an implementation and testing partner, not as an assessor. We help your team turn the taxonomy's attack classes into scoped security testing, self-hosted controls and documented evidence inside your own infrastructure. Your organization owns its risk decisions and controls throughout.

How we scope

Engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts.
We map which predictive and generative attack classes apply to your specific AI systems and deployment environment.
Your written scope states which attacker objectives, such as misuse enablement, are tested and which are excluded.

How we build

We run security testing against in-scope AI systems, covering evasion, poisoning, privacy and prompt injection where agreed.
Self-hosted open-source platforms are deployed in your cloud accounts, data centers or air-gapped networks as scoped.
Mitigations are implemented and then tested, since NIST describes most defenses as empirical and open to new techniques.

How we hand over

Deliverables include test results, configuration records and documented evidence mapped to the scoped attack classes.
Documentation records known limits of each mitigation so your team can explain residual risk to reviewers.
Your staff receive handover sessions so they can run and repeat the tests after the engagement closes.

How we support

Ongoing support, upgrades and continuous testing are available as retainers when your AI systems change.
Retainers can track updates to the taxonomy, since NIST says it intends to revise the report as attacks evolve.
Questions about independent assessment, including which auditor or assessor to engage, should go to that party directly, as DeployOpen does not issue reports or certificates.

NIST adversarial machine learning taxonomy (AI 100-2e2025) explained