← Blog

NIST AI 100-2 Turns Adversarial ML into a Control-Scope Map

Parminder Singh
Parminder Singh··6 min read
Summarize with AI

NIST AI 100-2 classifies adversarial machine learning by AI system type, lifecycle stage, attacker objective, capability, and knowledge. That structure gives security teams a better way to assign each attack to the model, data, deployment, or runtime owner. This guide maps the taxonomy to test evidence and draws a precise line around the authenticated HTTP traffic an inline policy gateway can inspect.

Compliance & Regulationnistnist-ai-rmfai-securityllm-securityai-governancepolicy-enforcement
NIST AI 100-2 Turns Adversarial ML into a Control-Scope Map

NIST AI 100-2 starts with the AI system type and lifecycle stage. It then classifies the adversary's objective and available capabilities. It also records the adversary's knowledge of the target. Published in January 2024, the report covers predictive and generative AI, then traces attacks against data and models. It also covers deployment infrastructure and prompts. Connected resources are included. I want security teams to use that structure as an ownership map. A red-team result becomes useful when it identifies the affected component and the attacker's access, then records the expected control and the evidence that proves the control ran.

TL;DR

  • NIST AI 100-2 separates predictive AI attacks into evasion and poisoning families. Privacy is the third family, and the report adds generative AI attack families such as prompt injection and supply-chain compromise.
  • Each finding needs five labels: system type and lifecycle stage, objective and capability, plus knowledge.
  • Training data and model artifacts have different control owners from retrieval stores and local tools. Runtime HTTP requests also have their own owner.
  • DeepInspect covers authenticated HTTP requests deliberately routed through its policy point. It cannot inspect model files or training pipelines. It also cannot inspect local execution or direct paths around that route.

The five dimensions prevent vague findings

The NIST publication page describes a conceptual hierarchy built around ML methods and lifecycle stages. It also covers attacker goals and capabilities, plus knowledge. The report itself is formally identified as NIST AI 100-2e2023, even though NIST published the approved report in January 2024. Teams searching for NIST AI 100-2 should preserve that full identifier in evidence records.

Those dimensions turn "the model was attacked" into a testable statement. Record predictive or generative AI first. Name the stage where the adversary acts, such as training and fine-tuning or inference and deployment. Add the objective and the access the attacker possesses. Then record the information available about the target. A black-box API caller and an insider who can modify training data occupy different cells.

My opinion is blunt: an adversarial ML register with one generic severity column is administrative wallpaper. Put the five labels beside every finding. The resulting record tells engineering which component changed and tells audit which evidence to request.

Predictive AI has three main attack families

NIST organizes predictive AI around evasion and poisoning attacks. Privacy attacks form the third family. Evasion changes an input at inference time to cause a wrong prediction. Poisoning changes training data or the model during learning, with availability and targeted variants, plus backdoor and model-poisoning variants. Privacy attacks seek information about training records or the model through reconstruction and membership inference, plus model extraction and property inference.

The lifecycle distinction controls the response. An evasion test can exercise a deployed inference endpoint. A poisoning investigation needs dataset lineage and labeling history, along with training jobs and artifact hashes. It also needs access records. A membership-inference test needs a privacy evaluation and carefully bounded queries. One green runtime filter cannot prove the integrity of a model artifact produced six months earlier.

Picture four evidence folders on a steel desk. One holds crafted inference inputs. The second holds dataset records. The third holds training records. The fourth holds privacy-test results. NIST's taxonomy explains why combining them into a single "AI security passed" folder destroys the information a reviewer needs.

Generative AI expands the runtime surface

The generative AI portion covers supply-chain attacks and direct prompt injection, along with indirect prompt injection and attacks that target connected data or model behavior. Direct prompt injection arrives in the user's input. Indirect prompt injection reaches the model through content such as a document and website, or a message and retrieved record. The delivery path and the compromised component determine the owner.

A runtime test should name the source of the hostile instruction and the point where it entered the assembled request. It should also identify the model route and caller identity, plus the policy version and expected action. The observed response completes the record. The AI red teaming controls guide provides the testing program around those records. The prompt injection benchmark guide covers corpus and adaptive-attack limits.

Supply-chain and training attacks need separate evidence. A tampered model package belongs to artifact verification and deployment security. A poisoned retrieval record belongs to ingestion and data-access controls. The runtime request may expose the consequence, but that observation never proves that the upstream source is clean.

Control ownership follows the affected component

The NIST AI Risk Management Framework supplies the wider Govern and Map structure, followed by Measure and Manage, that AI 100-2 uses for security and resilience. It also covers related risk. Apply that structure by assigning an owner and evidence source to every taxonomy cell.

Data owners preserve dataset provenance and labeling changes, along with access history and approval records. Model engineering owns training configuration and evaluation results, plus artifact integrity and release decisions. Platform security owns package admission and secrets, along with workload isolation and model-serving infrastructure. Application teams own retrieved context and tool permissions. They also own identity propagation. The HTTP policy point owns only the requests and responses that cross it.

This split also improves incident response. A suspicious model response can trigger parallel checks without collapsing them into one theory. Review the routed request record and inspect retrieval provenance. Then verify the model artifact and compare the active release with its approved evaluation. The AI threat modeling guide can hold those trust boundaries and evidence owners.

A taxonomy label should change the test plan

Start each test with the five NIST labels and a named component. State the attacker action and required access, followed by the expected outcome and control owner. Record the evidence location as well. A direct prompt-injection test might expect an inline deny tied to an authenticated caller and policy version. A backdoor-poisoning test might expect the training pipeline to reject an unapproved dataset or artifact. The outcomes use different verbs because different systems make the decisions.

Keep a negative control and the prior result beside each test. The prior result reveals drift after a model and policy change or a retrieval and application change. A screenshot of two dated rows often tells a release reviewer more than a slide marked "red team complete." Preserve the target version and route so the team can reproduce the comparison.

NIST AI 100-2 also points out open challenges. Taxonomy coverage cannot establish attack likelihood or organizational risk tolerance by itself. Teams still need context and threat intelligence, plus asset value and a defined risk decision. The taxonomy gives those decisions consistent names and boundaries.

DeepInspect

DeepInspect operates on authenticated HTTP requests that users or agents deliberately route to LLM endpoints. It can evaluate application-supplied identity and policy context, then classify request content and enforce a route decision. It can also inspect the response and produce a per-decision record tied to the active policy version.

That boundary maps to the runtime slice of NIST AI 100-2. Direct prompt injection and hostile content assembled into a routed request can produce enforcement evidence at this point. Poisoned training data and modified model weights remain with their actual owners. So do local model loading and direct retrieval-store writes. STDIO calls and traffic sent around the proxy also remain with their actual owners. Book a technical deep dive at deepinspect.ai.

Frequently asked questions

Is the report called NIST AI 100-2 or NIST AI 100-2e2023?

The official report number is NIST AI 100-2e2023. NIST approved it on January 2, 2024 and published it on January 4, 2024. "NIST AI 100-2" is the common search phrase. Use the full report number in control mappings and citations. Use it in evidence registers so a reviewer can resolve the exact edition.

Does NIST AI 100-2 define a required control set?

The report defines taxonomy and terminology. It surveys mitigations and identifies open challenges. It does not set an organization's risk tolerance or prescribe one mandatory implementation for every system. Use it to classify attack surfaces and assign evidence, then use the AI RMF and organization-specific standards to govern treatment decisions.

Where does prompt injection sit in the taxonomy?

NIST gives direct and indirect prompt injection dedicated treatment in its generative AI taxonomy. Direct injection enters through user input. Indirect injection arrives through external content incorporated into the model context. Tests should preserve that source distinction because the delivery path changes the prevention and evidence owners.

Can one gateway cover the full adversarial ML taxonomy?

A gateway covers the traffic crossing its own route. Training data and model weights require controls at those components. So do package loading and retrieval-store writes. Local tools and inference paths that bypass the gateway also require separate controls. The taxonomy helps prevent runtime evidence from being stretched into a claim about those other surfaces.