NIST AI 100-2 adversarial ML taxonomy for agents

01 · WHAT NIST AI 100-2 IS

A published taxonomy. Not a regulation.

This NIST Trustworthy and Responsible AI report provides a taxonomy of concepts and defines terminology in the field of adversarial machine learning (AML). The taxonomy is arranged in a conceptual hierarchy that includes key types of ML methods, life cycle stages of attack, and attacker goals, objectives, capabilities, and knowledge. This report also identifies current challenges in the life cycle of AI systems and describes corresponding methods for mitigating and managing the consequences of those attacks. NIST AI 100-2e2025 · Abstract · March 2025

One paragraph from the abstract carries the load. The document is a taxonomy and a set of terminology. It is descriptive, not prescriptive. It does not say thou shalt. It says if your AI system is attacked, this is the vocabulary auditors and engineers should be using when you describe what happened and what you did about it.

The lineage matters, and it is usually told wrong. The 2019 draft was a different publication in a different series: NISTIR 8269, A Taxonomy and Terminology of Adversarial Machine Learning, October 2019. The first edition under the AI 100-2 identifier is NIST.AI.100-2e2023, published January 2024, and it already carried both taxonomies — predictive AI in § 2, generative AI in § 3. There is no 2024 edition; the identifier NIST.AI.100-2e2024 resolves to nothing. NIST.AI.100-2e2025 (March 2025) restructured the generative-AI material into supply chain, direct prompting and indirect prompt injection, and dropped abuse as a category.

What it is not. It is not an EU harmonised standard. It is not a NIST-issued conformity scheme. It is not, in itself, a defence in any litigation. What it is, in operational terms, is the closest thing engineering teams currently have to a shared dictionary for AI-specific attacks. That makes it the lowest-friction way to translate Article 15(5) of the EU AI Act into a per-decision evidence pattern.

"A taxonomy is not a regulation. A taxonomy is what makes a regulation operational."Warrant Engineering · 2026-05-11

The taxonomy is organised across three axes. The ML method axis distinguishes predictive AI from generative AI. The life-cycle axis separates training-time attacks from inference-time attacks. The attacker-goal axis names what the attacker is trying to achieve, whether that is integrity violation, availability violation, or privacy violation. The attack classes sit at the intersection of those axes — three for predictive AI in § 2, three for generative AI in § 3.

02 · EVASION

Evasion · adversarial inputs at inference time.

An evasion attack is an inference-time attack on a predictive AI system. The model is already trained. The training pipeline is untouched. The attacker modifies the input so that the model's output is wrong in a way that benefits the attacker.

The canonical example is the adversarial image. A photograph of a stop sign with a precisely calibrated perturbation invisible to humans, classified by a vision model as a speed-limit sign. The mathematics generalises. Tabular features in a credit-scoring model. Tokenised text in a sentiment classifier. Network packets in an intrusion-detection system.

NIST AI 100-2 names the attacker's knowledge on a three-step ladder — § 2.1.4, "There are three main types of attacks: White-box … Black-box … Gray-box". Capability is a separate axis, § 2.1.3, and it has six entries rather than three: training data control, model control, testing data control, label limit, source code control, query access. White-box assumes the attacker has the model architecture and weights. Gray-box assumes partial knowledge, often the architecture but not the weights, or a known training corpus. Black-box assumes only query access through the production interface.

white

Full knowledge of the target model. Gradient-based attacks work directly. Strongest threat model, often used as a benchmark for defensive evaluations. EXAMPLE · projected gradient descent (PGD) crafting against a known weights file.

gray

Partial knowledge. Architecture without weights. Training distribution without parameters. EXAMPLE · transfer attacks crafted on a surrogate model trained on the same dataset.

black

Query-only access via the production API. Decision boundaries are inferred by probing. EXAMPLE · ZOO, square-attack, or model-extraction precursors to a transfer attack.

The engineering implication for the evidence record is direct, and it is a target rather than a description of anything shipped — Warrant carries no such field today, which § 8 states plainly. For any predictive decision an agent takes, an evidence record worth the name would carry the input that produced the decision and a typed indicator of whether that input passed an adversarial-input check. The check itself is layered. Statistical detection on input distribution. Distance from training-set neighbours. Optionally, a model-specific certified-bound check.

What the trace must not claim is immunity. NIST AI 100-2 is explicit that no current defence eliminates evasion. The honest signal is detection coverage with a known false-negative rate, not a binary passed.

03 · POISONING

Poisoning · training-time attacks.

Poisoning is the training-time counterpart to evasion. The attacker has access to the training data, or to some part of it, or to the pipeline that ingests it. The poisoning is in the corpus, not in the request.

NIST AI 100-2 separates poisoning by attacker goal, and the section headings are the names to use. Availability poisoning degrades the model's accuracy generally (§ 2.3.1). Targeted poisoning causes incorrect outputs for specific inputs while leaving general accuracy intact (§ 2.3.2) — NIST's term is targeted, and the phrase "integrity poisoning" occurs nowhere in the publication. Backdoor poisoning installs a hidden trigger pattern such that any input carrying the trigger is misclassified to an attacker-chosen label (§ 2.3.3). Model poisoning modifies the trained parameters directly (§ 2.3.4).

The relevant capability is NIST's training data control — "control of a subset of the training data" (§ 2.1.3) — with label limit distinguishing clean-label from regular poisoning. Full corpus control is the textbook case. Partial contamination is the realistic one in 2026 supply chains: a few percent of an open dataset, or a single internet source that gets scraped.

AVAILABILITY · § 2.3.1

General accuracy degraded. Model becomes unreliable across many inputs. Attacker wants the system removed from service.

TARGETED · § 2.3.2

Specific inputs misclassified. General test accuracy unaffected. Attacker wants a particular decision to fall a particular way. NIST's heading is Targeted Poisoning.

BACKDOOR · § 2.3.3

Hidden trigger pattern installed. Any input carrying the trigger flips to an attacker-chosen label. Discoverable by trigger-search only.

MODEL · § 2.3.4

The trained parameters are modified directly rather than the corpus. Distinct from the three data-poisoning goals above and a separate NIST sub-section.

Supply chain is deliberately absent from that grid. In e2025 the AI supply chain is a top-level class of the generative-AI taxonomy, § 3.2, sitting alongside direct prompting and indirect prompt injection rather than underneath poisoning. Poisoning that arrives through a foundation model, a third-party dataset or a fine-tune from an unknown source is a supply-chain attack in NIST's structure, and the provenance gap is the vulnerability.

The evidence pattern for poisoning is upstream of the per-decision trace. It lives in metadata about the model, not the request. Training-data provenance, dataset hashes, source attestation for fine-tune corpora, the integrity of any retrieval-augmented index. NIST AI 100-2 does not prescribe the artefacts. It names the class so that auditors can ask the right question.

For a 2026 generative-AI deployment, the operational reality is that almost no provider can prove the absence of poisoning in a foundation model. The defensible posture is documented provenance for everything inside the deployer's control, and a contractual chain of attestations for everything outside it. That is the cybersecurity posture Article 15(5) asks for, read alongside the technical documentation under Annex IV.

04 · PRIVACY

Privacy · extracting from the model.

The third class is privacy attacks. The attacker is not trying to misclassify an input or corrupt the training pipeline. The attacker is trying to extract information about the training data, the model parameters, or the individuals whose data was used to train.

NIST AI 100-2e2025 organises § 2.4 into four numbered sub-sections: Data Reconstruction (§ 2.4.1), Membership Inference (§ 2.4.2), Property Inference (§ 2.4.3) and Model Extraction (§ 2.4.4). Its own enumeration of privacy attacks adds training data extraction and attribute inference as named terms. Model inversion is not one of NIST's classes — it is the Fredrikson 2015 attack discussed inside Data Reconstruction, where NIST records that it "cannot directly reconstruct the training data of the model".

recon

Data reconstruction (§ 2.4.1). Infer the content or features of training records from the model. Model inversion is one specific instance, and NIST notes it cannot directly reconstruct training data. RISK · the strongest privacy failure for models trained on identifiable records.

mem

Membership inference (§ 2.4.2). Yes-or-no on whether a record was in the training set. RISK · GDPR Article 4(1) personal data leakage. EU AI Act Article 15(5) confidentiality.

attr

Attribute inference. A named term in NIST's enumeration of privacy attacks rather than a numbered sub-section. Reconstruct one or more sensitive attributes given a partial record. RISK · sensitive special-category data under GDPR Article 9 may be inferred from non-special-category features.

prop

Property inference (§ 2.4.3). Recover a global property of the training distribution rather than a single record. RISK · leaks commercially sensitive facts about the corpus, not necessarily personal data.

mext

Model extraction (§ 2.4.4). Reconstruct a functional copy of the model itself through query access. RISK · intellectual-property loss, and a precursor to a transfer evasion attack against the original.

ext

Training data extraction. Also a named enumeration term. Recover literal training records, often via repeated structured prompting of large generative models. RISK · most acute for foundation models trained on web-scale corpora that include PII.

Capability ranges from query-only access through full model-weights access. Against privacy attacks, differential privacy is the mitigation with the strongest formal guarantee — NIST calls it "a rigorous notion of privacy" that protects against membership inference and data reconstruction — at a measurable cost in utility. It is not the taxonomy's only formal guarantee: certified defences give provable bounds elsewhere, for evasion and for data poisoning. Everything else in the privacy column is empirical hardening: query rate-limiting, output filtering, post-hoc memorisation audits.

The record that would carry this is narrow: whether the action touched a privacy-sensitive surface, and if so, which differential-privacy or output-filtering control was active. No such field exists in a Warrant package today (§ 8). Stated as a design target rather than a feature: an artefact of this kind would not claim the model is private — it would record what privacy posture was in force at the time of the decision.

05 · § 3.3 + § 3.4 · PROMPTING ATTACKS

The prompt surface · where the GenAI attacks live.

This is the material the generative-AI half of the taxonomy has carried since e2023, and in the 2025 edition it occupies two numbered sections rather than one class. With generative AI in widespread production, the attacker stopped trying to break the model and started trying to instruct it.

What these sections cover is adversarial use of generative AI systems. The model is functioning correctly in the predictive-AI sense. The vulnerability is that functioning correctly for a chat or agent system means doing what the input asked. When the input is hostile, the model executes the hostile instruction. The threat surface is the prompt.

DIRECT PROMPTING ATTACK attacks arise when the attacker is the primary user of the system, interacting with the model through query access. A subset of these attacks, in which the main user provides in-context instructions that are appended to higher-trust instructions like those provided by the application designer (such as the model's SYSTEM PROMPT), are known as DIRECT PROMPT INJECTION attacks. NIST AI 100-2e2025 · § 3.3 Direct Prompting Attacks and Mitigations [NISTAML.018] · March 2025

A JAILBREAK is a direct prompting attack intended to circumvent restrictions placed on model outputs, such as circumventing refusal behavior to enable misuse. NIST AI 100-2e2025 · § 3.3 · March 2025

A note on the label. The 2025 edition does not organise this material under a heading called Abuse — that word appears in its keyword list and nowhere in its section structure. The taxonomy splits the same ground into § 3.3 Direct Prompting Attacks and § 3.4 Indirect Prompt Injection Attacks, each carrying its own availability, integrity and privacy sub-cases. Jailbreak is not a third peer class; NIST places it inside direct prompting. Cite the section numbers, not the informal name.

Indirect prompt injection is the same instruction delivered through content the model reads from somewhere else. NIST ties it to runtime context assembly: these attacks "depend on the attacker's ability to modify external sources of information that will be ingested into the model context, even if not provided directly by the primary system user" — § 3.1 Attack Classification, not § 3.4. A retrieved document, a tool's return value, an email body, a web page.

The capability story differs from predictive AI. Black-box is the default. The attacker rarely needs weights. They need the prompt surface, plus, increasingly, any path through which untrusted content reaches the model. For a retrieval-augmented agent, every retrieval source is a prompt-injection vector. For a tool-using agent, every tool's return value is.

The mitigation story is empirical and unsettled. System-prompt hardening, instruction-tuning for resistance, content classifiers on inputs, content classifiers on outputs, structural separation between trusted system instructions and untrusted user or retrieved content. NIST AI 100-2 enumerates the techniques without ranking them. The 2026 honest engineering answer is layered defence with structured per-decision evidence of which defences were in force.

06 · MITIGATIONS

Mitigation taxonomy · what defences map to what attacks.

NIST AI 100-2 pairs the attack taxonomy with a mitigation taxonomy. Three observations matter for engineering teams.

First. Mitigations have capability and knowledge requirements of their own. Adversarial training requires retraining the model on adversarially perturbed examples. Certified defences require model architectures amenable to formal bounds and impose accuracy costs. Differential privacy requires bounded privacy budgets and reduces utility. Data sanitization — NIST's term, alongside label sanitization and model sanitization; "input sanitisation" appears nowhere in the publication — requires distributional knowledge of legitimate inputs. Output filtering requires a classifier downstream of the model.

Second. No mitigation generalises across all six attack classes. A defence that hardens evasion may have no effect on poisoning. A defence that mitigates membership inference may be irrelevant to prompt injection. The taxonomy is explicit on this point.

M·1

Adversarial training. Augment the training set with adversarially perturbed examples. TARGETS · evasion. COST · clean accuracy reduction, training-cost multiplier, no transfer to poisoning or prompting attacks.

M·2

Certified defences. Provable robustness bounds for bounded perturbations. TARGETS · evasion in narrow regimes, and NIST also documents certified defences against data poisoning. COST · model-class restrictions, scalability constraints.

M·3

Differential privacy. Bounded influence of any single training record on the trained model. TARGETS · membership inference, attribute inference, training-data extraction. COST · utility reduction proportional to privacy budget.

M·4

Data sanitization and anomaly detection. Statistical filters on inputs and on training data. NIST's terms are data, label and model sanitization. TARGETS · evasion at inference, some indirect prompt-injection variants. COST · false positives on legitimate edge cases.

M·5

Output filtering and content classifiers. Classifiers downstream of the model. TARGETS · direct prompting attacks, particularly jailbreak. COST · false-negative tail by construction.

M·6

Provenance and watermarking. Cryptographic or statistical marking of model outputs and training corpora. TARGETS · downstream attribution, not direct attack prevention. COST · detection-only.

Third, and most useful for an attestation discipline. The mitigation taxonomy is the natural home for per-decision evidence. The audit question is rarely do you defend against evasion. The audit question is which evasion defence was in force when this decision was taken on this person on this date, and what did it produce. That maps to a structured field in a trace, not a marketing claim in a product page.

07 · EU AI ACT BRIDGE

Article 15(5) · three subparagraphs.

High-risk AI systems shall be resilient against attempts by unauthorised third parties to alter their use, outputs or performance by exploiting system vulnerabilities.

The technical solutions aiming to ensure the cybersecurity of high-risk AI systems shall be appropriate to the relevant circumstances and the risks.

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. Regulation (EU) 2024/1689 · Article 15(5), all three subparagraphs · applies from 2 December 2027 (Annex III high-risk)

Three subparagraphs, three jobs. The first, attempts by unauthorised third parties to alter their use, outputs or performance by exploiting system vulnerabilities, is the threat surface. The second, appropriate to the relevant circumstances and the risks, is the proportionality test the regulator will apply when the provider's defence is challenged. The third is the enumeration, and it is the only operative provision in the Regulation that names AI-specific attack types.

The dating matters. Article 15 sits in Chapter III, Section 2, and applies from 2 December 2027 for AI systems classified as high-risk under Article 6(2) and Annex III, and from 2 August 2028 for Article 6(1) / Annex I systems, under Article 113, third paragraph, point (c), as replaced by Regulation (EU) 2026/1744, Article 1(40)(b). The Annex I limb is subject to the limitation inserted as Article 2(13) by Article 1(3) of the same Regulation, which entered into force 27 July 2026. As of 6 August 2026, Article 15 is not yet in application: everything below is preparation for a duty with a date, not compliance with a live one. Source of record for the deferral status: Warrant's regulation corpus at digest 6871ee8b.

The Regulation names attack families in the third subparagraph but does not define the system vulnerabilities behind them, and it cannot: the literature evolves quarterly. So it points to harmonised standards under Articles 40 and 41 to fill in the technical content over time. Until those harmonised standards are published in the Official Journal, providers and notified bodies fall back on the recognised state of the art.

NIST AI 100-2 is one widely recognised statement of that state of the art for AI-specific threats. It is not cited by name in the Regulation. It is not declared by the Commission to confer presumption of conformity. It is, in 2026, the most defensible single document an engineering team can point to when an auditor asks what system vulnerabilities they have in fact considered.

The other side of the bridge is not a recital — it is the third subparagraph of Article 15(5) itself, quoted in full above. Crediting that enumeration to Recital 76 downgrades operative Article text to a non-binding recital, which is the error that costs most. Across the whole Regulation, adversarial examples, model evasion, confidentiality attacks and model flaws each occur exactly once, all four on the single line that is Article 15(5), third subparagraph, and zero times in Recital 76. Recital 76 is narrower: it gives data poisoning and adversarial attacks or membership inference as examples of attacks that leverage AI-specific assets. The Article 15(5) list maps onto the NIST vocabulary almost without translation — data poisoning and model poisoning to § 2.3, adversarial examples and model evasion to § 2.2, confidentiality attacks to § 2.4. For the wider Article 15 obligation (accuracy, robustness, and cybersecurity together), see the Article 15 reading filed alongside. For the application-layer companion taxonomy, see the OWASP LLM Top 10.

08 · WHAT THE RECORD CARRIES

What Warrant records today — and what it does not.

Warrant defines no typed evidence field for the NIST attack classes. There is no such field path in any Warrant schema, in any of the four pipeline stages, or in any receipt, and the sample package linked below carries none. What follows is what the code does record, read on 6 August 2026.

§ 3.3

Direct prompting attacks · one detector class. A deterministic check runs on every submitted trace before any model call, looking for directives addressed to the analysing pipeline: text naming the pipeline's stages, its output-schema field names or the regulation corpus, coupled in the same string with imperative override language. FIELD · debug.injection_gate — mode, plus findings[] carrying path, target, directive and excerpt. Returned in the debug payload of the attestation response when debug output is requested.

MODE

It reports; it does not refuse. By default a detection is logged and surfaced and the attestation proceeds. Refusal happens only where a deployment is explicitly configured for it. Two domain-realistic benign sentences are known to match the current patterns and are held as red-case tests, which is why report is the default. SCOPE · one class only. An injection that avoids naming the pipeline, splits itself across sibling fields, or persuades rather than instructs is out of scope. Passing this check does not mean a trace is free of injection.

PROV

What produced the verdict. Every receipt records the model each of the four stages ran, a digest over the exact prompt bytes and confidence floors in force, and the digest of the regulation corpus the trace was judged against. FIELD · pipeline_models, pipeline_config_sha256, regulations_corpus_sha256, schema_hash. This is provenance for Warrant's own analysis inputs. It says nothing about the deployer's model supply chain.

GAP

No field exists for evasion, poisoning or privacy attacks against the deployer's model. There is no adversarial-input check, no training-data provenance record and no privacy-attack-surface indicator. STATUS · unbuilt, and stated here rather than implied. A record spanning all six NIST classes is a design target, not a shipped feature.

The § 6 argument holds: the mitigation taxonomy is the natural home for per-decision evidence, and the audit question is which defence was in force when this decision was taken. What Warrant can show today is one narrow slice of that, plus a provenance record of its own analysis. An auditor reading a Warrant package can verify which obligations were mapped to which action, against which corpus, by which models. They cannot read an evasion, poisoning or privacy posture out of it, and this page will not say otherwise until a field exists.

One thing about the package linked below: it is not evidence for the section above it. It is a specimen from a different domain — an EU lending trace from a Frankfurt bank's lending agent, binding EU AI Act Article 12 and Article 13 and FCA Principle 12 among the five regimes it cites. It maps no Article 15 obligation and carries no adversarial-check field of any kind. It is linked here because the shape of the record is the point, not the regime — per-action obligations with named citations, the corpus digest they were judged against, and a verdict a third party can check without contacting Warrant.

Sample package · EU lending trace · Art. 12 + Art. 13 · FCA Principle 12SPECIMEN FROM ANOTHER DOMAIN · 4 WARRANTED ACTIONS · 5 REGIMES CITED · 3 COMPLIANCE GAPS · VERIFIABLE WITHOUT CONTACTING WARRANT

→ /v/7de85ceaeac42a47

09 · OWASP OVERLAP

Cross-reference · NIST taxonomy versus OWASP LLM Top 10.

The OWASP LLM Top 10 is the parallel artefact most engineering teams know by name. The two documents serve different functions. NIST AI 100-2 is the taxonomy. OWASP LLM is the prioritised practitioner list.

Version first, because the identifiers move. The item numbers below belong to the original 2023-24 OWASP Top 10 for Large Language Model Applications. OWASP has published two lists since — a 2025 edition on 17 November 2024, and a 2026 edition on 3 August 2026 — and both renumber. Read what follows as a mapping of that original list, and see the OWASP entry filed alongside for the 2025 list item by item. LLM01 prompt injection sits squarely inside NIST § 3.3 and § 3.4. LLM02 insecure output handling intersects those sections and, where outputs feed downstream classifiers, NIST Evasion. LLM03 training-data poisoning is a one-to-one with NIST Poisoning, § 2.3. LLM06 sensitive information disclosure maps to NIST Privacy, § 2.4.

What OWASP adds that NIST does not, and vice versa, is a useful filter. OWASP is more applied: each item is a category of finding an engineer can fix in code or configuration this quarter. NIST is more structural: each class is a frame an auditor can apply across an entire system. A 2026 posture cites the current OWASP GenAI LLM Top 10 alongside the NIST taxonomy, and states which version of each it is citing.

Once Article 15(5) is in application — 2 December 2027 for Annex III high-risk systems — an auditor is likely to accept either as evidence the team considered AI-specific threats systematically. A team that cites neither will be asked which published reference they did consider. The answer cannot be silence.

10 · FAQ

Questions a security officer asks first.

How does NIST AI 100-2 relate to EU AI Act Article 15(5)?

Article 15(5) will require high-risk AI systems to be resilient against attempts by unauthorised third parties to alter use, outputs, or performance through exploiting system vulnerabilities. It applies from 2 December 2027 for Annex III high-risk systems and from 2 August 2028 (subject to Article 2(13)) for Annex I systems, under Article 113 third paragraph point (c) as replaced by Regulation (EU) 2026/1744, Article 1(40)(b); as of 6 August 2026 Article 15 is not yet in application. NIST AI 100-2e2025 is one widely recognised published taxonomy that translates that abstract phrase into operational categories: evasion, poisoning and privacy for predictive AI, and supply chain, direct prompting and indirect prompt injection for generative AI. It is not cited by name in the Regulation, but it is the engineering-quality reference U.S. and many international auditors apply when assessing AI-specific cybersecurity.

Does NIST AI 100-2 conformity satisfy EU AI Act cybersecurity?

No single publication is declared by the European Commission to confer presumption of conformity for Article 15(5). The harmonised standards process under Articles 40 and 41 is still in progress. Aligning to NIST AI 100-2e2025 is strong evidence of state-of-the-art engineering practice. It is not, on its own, a legal safe harbour.

What is the difference between Evasion and a prompting attack?

Evasion is an attack at inference time on a predictive ML system. The attacker crafts an input that causes a misclassification or a wrong decision while the model behaves as designed. A prompting attack targets a generative system through the prompt surface. The model is not misclassifying. The model is doing what it was asked, where the asking was hostile. NIST AI 100-2e2025 splits that ground into § 3.3 Direct Prompting Attacks and § 3.4 Indirect Prompt Injection Attacks, and places jailbreak inside § 3.3. The 2025 edition has no Abuse class.

Where does NIST AI 100-2e2025 put prompt injection and jailbreak?

In two numbered sections, and it is worth citing them rather than an informal class name. § 3.3, Direct Prompting Attacks and Mitigations, tagged NISTAML.018, covers attacks where the attacker is the primary user interacting through query access; direct prompt injection is defined there as the subset in which the main user supplies in-context instructions appended to higher-trust instructions such as the model's system prompt. Jailbreak sits inside that same section, defined as a direct prompting attack intended to circumvent restrictions placed on model outputs. § 3.4, Indirect Prompt Injection Attacks and Mitigations, covers attacks that depend on the attacker modifying external sources of information ingested into the model context, and is subdivided into availability, integrity and privacy-compromise cases. The 2025 edition has no section headed Abuse; that word appears only in its keyword list.

What changed between NIST AI 100-2e2023 and e2025?

e2023, published January 2024, already covered both predictive and generative AI — its § 3 was the generative-AI taxonomy. e2025 restructured that section into § 3.2 AI Supply Chain, § 3.3 Direct Prompting and § 3.4 Indirect Prompt Injection, and renamed rather than removed the e2023 Abuse objective: the word \"abuse\" now appears once in the publication, in its keyword list, while the objective itself is carried as a distinct GenAI attacker objective tagged NISTAML.04 alongside availability, integrity and privacy. Read the tag, not the word. There was no 2024 edition of NIST AI 100-2, and the 2019 draft was a different publication in a different series, NISTIR 8269. Cite the section numbers, not the informal class names.

What mitigation has the strongest evidence base?

Differential privacy for training-data privacy attacks has the strongest formal-guarantee story. Adversarial training raises the bar for evasion at known cost in clean accuracy. Certified defences offer provable bounds for small perturbations, and NIST also documents certified defences against data poisoning. For the § 3.3 and § 3.4 prompting attacks, the picture is less settled and the empirical literature evolves quarterly. The honest engineering answer in 2026 is layered defence with per-decision evidence.

Does Warrant produce per-decision adversarial-check evidence?

No, not across the taxonomy. There is no per-action record for evasion, poisoning or privacy attacks, and no typed field for any of them in any schema, pipeline stage or receipt. What exists is narrower and real: a deterministic detector for one class of prompt-injected trace content, which runs before any model call and reports each finding as a field path, a matched pipeline-target pattern and a matched directive pattern in the debug payload of the attestation response. It reports rather than refuses unless refusal is explicitly configured, and passing it does not mean a trace is free of injection. Separately, every receipt records which models, which prompt bytes, which corpus digest and which confidence floors produced the verdict, so two packages that disagree carry a dated reason. Warrant does produce a per-action obligation record; that is a different claim from an adversarial check. On the law: Article 12(2) requires logging capabilities that enable recording of events relevant to Article 79(1) risk, Article 72 post-market monitoring and Article 26(5) monitoring. It does not impose per-decision granularity, and Article 15(5) is silent on record granularity — per-decision evidence is Warrant's design choice, not a quoted obligation.

How does NIST AI 100-2 interact with ISO/IEC 27090?

ISO/IEC 27090 is a draft international standard on addressing security threats and compromises to AI systems. As of 6 August 2026 it sits at FDIS stage and is not yet published, so it cannot be cited as a current control set. NIST AI 100-2e2025 does not reference it — the string 27090 occurs zero times in that publication. Cite the NIST taxonomy for vocabulary and treat ISO/IEC 27090 as forthcoming, with neither displacing the harmonised standards process under EU AI Act Articles 40 and 41. One catalogue trap worth naming: ISO/IEC 27090 is catalogue entry 56581, while 56582 is ISO/IEC 27091, a privacy standard.

11 · READ THE SOURCE

Read the source directly.

NIST AI 100-2e2025 · Adversarial Machine Learning · Taxonomy and Terminology of Attacks and Mitigations · PDF
NIST CSRC publication landing page · NIST.AI.100-2e2025
ISO/IEC 27090 · Cybersecurity — Artificial Intelligence — Addressing security threats and compromises to artificial intelligence systems · FDIS, not yet published as of 2026-08. Catalogue entry 56581; 56582 is ISO/IEC 27091, a privacy standard.
Regulation (EU) 2024/1689 · Article 15 · EUR-Lex CELEX:32024R1689
OWASP project page · Top 10 for Large Language Model Applications · the list has three generations — the original 2023-24 list whose numbering § 09 maps, a 2025 edition published 17 November 2024, and a 2026 edition published 3 August 2026. State which one you are citing.
Article 15 · the regulator-side reading filed alongside

Authored by Warrant Engineering, the engineering function at Warrant. [email protected]. Editorial commentary on a published technical taxonomy. Not legal advice. The publication identifier NIST.AI.100-2e2025 and the title Adversarial Machine Learning · A Taxonomy and Terminology of Attacks and Mitigations reflect the NIST CSRC final release of March 2025 — Editorial Review Board approval 2025-03-20, with a corrected PDF uploaded 2025-04-01. No NIST source gives a day-precise 24 March date. Where the taxonomy text is paraphrased or summarised, the canonical source is the PDF linked above. Corrected 28 July 2026: § 05 previously carried a quotation block holding a paraphrase marked as unverified. It has been replaced with verbatim text from § 3.3 of the publication, checked against the NIST PDF at nvlpubs.nist.gov on 28 July 2026, and the section is renamed to the numbered headings NIST actually uses — the 2025 edition has no section headed Abuse. Corrected again 6 August 2026, after a clause-by-clause re-verification against the enacted instruments: the four-class framing was replaced with NIST's actual structure (three predictive-AI classes in § 2, three generative-AI classes in § 3); the abstract quotation was restored verbatim; the privacy sub-types, the knowledge-versus-capability axis, the poisoning sub-type names and the mitigation names were corrected to NIST's headings; the edition lineage was corrected (there is no 2024 edition, e2023 published January 2024, the 2019 draft was NISTIR 8269); Article 15(5) is now quoted in all three subparagraphs, and the enumeration of data poisoning, model poisoning, adversarial examples, model evasion, confidentiality attacks and model flaws is attributed to that third subparagraph rather than to Recital 76, which contains none of those four terms; the Article 15 application dates were added; the Article 12(2) per-decision obligation claim was withdrawn; the ISO/IEC 27090 link was repointed from catalogue 56582 (which is ISO/IEC 27091) to 56581 and relabelled as an unpublished draft; the OWASP mappings were dated to the archived v1.1 list; and § 08 was rewritten — it previously described four typed evidence fields that exist in no Warrant schema, pipeline or receipt. Corrected 7 August 2026: the sample-package card in § 08 was labelled only by its counts, which left it open to being read as evidence of the adversarial checks discussed above it. The linked package is an EU lending trace mapping EU AI Act Article 12 and Article 13 and FCA Principle 12 — a different domain to this page's subject — and it is now labelled as such, at the count of five regimes the receipt carries. The OWASP cross-reference in § 09 was relabelled the same day: its item numbers belong to the original 2023-24 list, and the claim about what the OWASP project page currently serves was removed as unquotable.

NIST AI 100-2, line by line.