What NIST says about AI supply chain attacks and data poisoning
A customer or regulator asking how your training data and third-party models are controlled under the NIST AI RMF is asking a fair question, but the answer has to start with what the framework is. NIST has no certification for the AI RMF, so no one can certify that you meet it. The risks and suggested actions for attacks through data and models come from NIST AI 100-2e2025 and the Generative AI Profile (AI 600-1). Your organization owns its controls and its evidence. Only an independent assessor or auditor can issue a report on them, and an implementation partner can only help prepare the systems and records that such a review would examine. The AI RMF is voluntary, and NIST says neither private nor public sector organizations are required to use it, so any obligation to follow it will come from a contract, a customer questionnaire or a specific state law.
The answer also depends on what you build, buy and fine-tune. A team that trains models on web-scale data faces poisoning risks that a team calling a hosted API does not, and a team that fine-tunes a pre-trained model inherits risks from both the base model and its own data. NIST AI 100-2e2025 says AI inherits traditional software supply chain vulnerabilities and adds new dependencies such as data collection, third-party models and third-party plugins. Start by listing which of these dependencies you have, then confirm with each data provider and model source what integrity information they publish, such as the cryptographic hashes that let you verify a web download. Ask your legal and procurement teams which contracts give you that information and what happens when it is missing.
Treat the output of this review as a decision list, not a finished compliance position. For each pre-trained model, record its source, its version and its place in the AI inventory, then decide whether you will keep monitoring it and under what conditions you would decommission it. For each training or fine-tuning dataset, confirm provenance and where the data came from. The Playbook suggestions for MANAGE 3.2 and the GAI Profile action MS-2.5-005 give you the questions to answer. Where the answers point to gaps in controls, the remediation is usually the organization's own work or that of an implementation partner, and any statement that the controls work should come from an independent assessor.
Which poisoning attack types NIST distinguishes
Availability poisoning is the broadest of the predictive AI types. The attacker injects training samples so that the trained model's overall performance degrades, making it unreliable across many inputs rather than wrong on one chosen case. The entry point is the training data collection step, where the attacker's samples reach the corpus through public data sources, crowd-labeled content or third-party feeds that the organization does not control.
- Goal: broad loss of accuracy or usefulness, which can be hard to separate from ordinary model drift.
- Entry point: data collection and labeling, especially web-scale or externally sourced data.
- Detection signal: a general drop in evaluation metrics after a retraining cycle, without a single failing case.
- Illustrative example: a retraining job pulls in a scraped dataset where a large share of labels were altered, and the model's accuracy falls across all classes.
Confirm with your data owners which training sources are externally controlled, and whether each retraining run compares evaluation results against a known baseline.
Targeted poisoning aims at a specific input or a narrow class of inputs. The model behaves normally on most data but produces a particular wrong output for inputs the attacker has chosen. The attacker needs some knowledge of the model's target behavior, and the poisoned samples are usually crafted to look plausible to human reviewers.
- Goal: a chosen misclassification or output for a specific case, such as one account, product or document type.
- Entry point: the same collection and labeling channels as availability poisoning, but with carefully selected samples.
- Detection signal: errors that cluster around a narrow input group, which aggregate accuracy figures can hide.
- Limit to test: checks on average performance alone can miss the affected slice, so evaluation should include segments the attacker would care about.
Ask your AI team which decisions the model supports where a single wrong output would carry high impact, and whether those decisions have their own test sets.
Backdoor poisoning inserts a hidden trigger into the training data. The model learns to behave normally on clean inputs and to produce an attacker-chosen output when the trigger appears at inference time. The trigger can be a pattern, token or feature that is unremarkable to people reviewing the data, which makes this type difficult to find by reading samples.
- Goal: a dormant behavior that activates only when the trigger is present.
- Entry point: training data, including fine-tuning sets and datasets obtained from outside the organization.
- Detection signal: unexplained behavior on inputs that contain unusual patterns, and performance that looks normal on standard evaluations.
- Why it matters for pre-trained models: a backdoor can be inherited from a model obtained from another party, not only from data the organization collected.
Identify which models in your inventory were trained or fine-tuned on data you did not curate, and record where that provenance is documented.
Model poisoning differs from the three data-centered types because the attacker changes the model itself, or the process that produces it, rather than only the samples. This can occur during training when the attacker has access to the training process, or through a modified model artifact that is distributed to users. AI 100-2e2025 notes that traditional checks such as vulnerability scanning of model artifacts help with some supply chain risks, but new approaches are needed to detect vulnerabilities introduced through model poisoning.
- Goal: change the learned parameters or behavior directly, which can bypass controls that only inspect data.
- Entry point: the training environment, model repositories, or artifacts downloaded and reused without verification.
- Detection signal: differences between a model artifact and its expected hash or provenance record, or behavior that departs from the vendor's documented evaluation.
- Control gap: a clean dataset review does not prove the model file is unchanged.
Confirm whether your team verifies model artifacts against published checksums or signed provenance before deployment, and who approves model updates.
AI 600-1, the Generative AI Profile, describes data poisoning in broader terms for generative systems: an adversary compromises a training dataset to manipulate a model's outputs or operation. The profile also notes that tampering with data or parts of the model could worsen the risks generative AI already presents, such as harmful, inaccurate or misleading content. The four predictive types help explain the mechanics, but a generative system adds retrieval sources, fine-tuning data and tool connections that can carry poisoned content into outputs.
- Scope: the profile treats the training dataset as the compromised asset, and it covers the model parts an adversary could alter.
- Added surfaces: fine-tuning data and retrieval-augmented generation sources, which may be updated after deployment.
- Output risk: poisoning can amplify other generative AI risks, so it should be assessed alongside them.
- Related action: MS-2.5-005 suggests verifying the provenance of training and TEVV data and that fine-tuning or retrieval data is grounded.
Check whether your generative AI program lists every source that shapes model behavior, including retrieval indexes, and records who can change each one.
Why AI supply chain risk needs more than software supply chain practice
AI inherits the software supply chain problems and adds new ones. NIST's adversarial machine learning taxonomy, AI 100-2e2025, says AI systems carry traditional software supply chain vulnerabilities and add dependencies that ordinary software programs do not have: data collection and scoring, third-party models and third-party plugins. For a security team, that means the software bill of materials and dependency scanning used for application code cover only part of the picture. The inventory has to also list where training data came from, which pre-trained models were adopted, and which plugins can act on the system's behalf. Confirm that your current supplier and component records capture those three categories before assuming existing software controls reach them.
Provenance information is what makes the AI inventory traceable. The taxonomy calls for provenance information for AI artifacts, meaning a record of where each dataset, model and plugin originated, who changed it and whether its integrity was checked along the way. Without that record, a poisoned dataset or a tampered model checkpoint can look identical to a legitimate one. Ask each team to show, for every production model, the source of its training data, the integrity check run on downloads (for example, comparing a file against the cryptographic hash the provider publishes) and the approver for any fine-tuning data. Those records also feed the inventory work described under MANAGE 3.2.
Vulnerability scanning helps, but it does not catch every poisoned model. AI 100-2e2025 notes that traditional practices such as vulnerability scanning of model artifacts address some AI supply chain risks. It also says new approaches are needed to detect vulnerabilities introduced through model poisoning, because a poisoned model can pass a scan for known weaknesses while behaving incorrectly on specific inputs. Plan for this gap explicitly: assign an owner for behavioral testing of third-party and pre-trained models, and ask any vendor or internal team whether their testing would reveal targeted or backdoor behavior, not only known vulnerabilities.
Which mitigations NIST AI 100-2e2025 names
NIST AI 100-2e2025 names a small set of mitigations against poisoning and supply chain attacks, and it is candid that none of them closes the risk on its own. The four cards below cover the integrity check, the filtering limit, artifact scanning and provenance tracking, so you can see which gap each one fills.
Hash verification of web downloads
AI 100-2e2025 names verifying web downloads against cryptographic hashes published by the data provider as a basic integrity check against poisoning of web-scale training data. The check confirms that a file matches what the provider published, so it catches tampering in transit or at the mirror. It does not show that the provider's original data was clean. Confirm with the source document whether the provider's hashes are themselves delivered over a trusted channel, and record the hash at ingestion so later pipeline runs can prove the training set did not change.
Limits of filtering poisoned samples
AI 100-2e2025 notes that filtering poisoned samples from a large corpus may be very difficult. This is a limit to plan around, not a control to rely on. Poisoned records can look statistically normal, and a backdoor may only activate on a specific trigger. Teams should treat filtering as one layer, then pair it with evaluation of the trained model's behavior, and document which residual poisoning risk the organization accepted for the corpus it used.
Vulnerability scanning of model artifacts
AI 100-2e2025 says traditional practices such as vulnerability scanning of model artifacts help with some AI supply chain risks. Scanners can flag known weaknesses in serialized model files, dependencies and containers that carry a model into production. The same publication says new approaches are needed to detect vulnerabilities introduced through model poisoning, so a clean scan does not show a model is free of poisoning. Confirm which artifact formats and dependencies your scanner covers before counting it as evidence.
Provenance tracking for AI artifacts
AI 100-2e2025 describes AI supply chain management as combining software supply chain practice with AI-specific measures such as provenance information for AI artifacts. In practice, this means recording where each dataset, pre-trained model and plugin came from, who changed it and which version went into each model build. The Generative AI Profile action MS-2.5-005 asks organizations to verify the provenance of training and TEVV data. Ask the team which records exist today for each third-party model in the AI inventory.
What the Generative AI Profile asks you to verify
The sequence below follows the verification that GAI Profile action MS-2.5-005 suggests, moving from the origin of training and evaluation data to whether fine-tuning and retrieval data are grounded. Each step ends with a record that the organization keeps, because NIST's guidance describes what to check, not a certificate that proves the check was done.
Inventory every data source and pre-trained model
The team lists each training, fine-tuning, TEVV and retrieval data source, along with each pre-trained model and third-party plugin the system depends on. The owner of each item is named in the AI inventory, which the AI RMF Playbook's MANAGE 3.2 suggestions also expect organizations to maintain. The output is a source register that shows where each dataset and model came from, who supplied it and which system uses it. Without this list, the later checks have nothing to test against.
Record provenance for each training and TEVV dataset
For each entry in the register, the data owner documents origin, collection method, licensing terms, transformations applied and the custodians who have handled it. Provenance information for AI artifacts is one of the AI-specific measures AI 100-2e2025 places alongside software supply chain practice. The output is a provenance record per dataset that a reviewer can follow from the original source to the copy used in training or evaluation.
Verify web downloads against published hashes
When a dataset is downloaded from the web, the engineer compares its cryptographic hash with the value published by the data provider before the file enters the training pipeline. AI 100-2e2025 names this check as a basic integrity measure against poisoning of web-scale training data. The output is a hash check log that records the file name, the published hash, the computed hash, the date and the person who ran the comparison. A mismatch stops the import until the cause is understood.
Screen training data for poisoning indicators
The team runs the checks it can apply to the corpus, such as anomaly review, label consistency tests and comparison against trusted reference samples, and records what each check can and cannot detect. AI 100-2e2025 notes that filtering poisoned samples from a large corpus may be very difficult, so the record should state residual uncertainty instead of implying the data is clean. The output is a screening report with the methods used, the results and an explicit list of limitations accepted by the risk owner.
Check provenance of third-party models and artifacts
For each pre-trained model, the team confirms the publisher, version, source location, integrity values and any scan of the model artifacts it received. AI 100-2e2025 says vulnerability scanning of model artifacts helps with some supply chain risks, but it also says new approaches are needed to detect vulnerabilities introduced through model poisoning. The output is a model provenance record that names what was scanned, what was not, and the monitoring plan for that model under the MANAGE 3.2 suggestions.
Review grounding of fine-tuning and retrieval data
A reviewer checks that the data used for fine-tuning and for retrieval-augmented generation is tied to approved, traceable sources, and that the system's answers can be linked back to those sources. The review also confirms that unapproved content cannot be added to the retrieval index without passing the same provenance steps. The output is a grounding review that lists each knowledge base, its owner, its approved sources and the test queries used to confirm that outputs cite them.
Retain and assign the evidence package
The organization collects the register, provenance records, hash logs, screening reports, model records and grounding review into one evidence package with a named owner and a review date. Internal reviewers or an independent assessor can then test the package against the organization's own controls. NIST does not issue attestations for these steps, so the organization must produce this evidence itself, and an implementation partner may help prepare it without certifying it.
How America's AI Action Plan shapes safety-critical AI
The most direct policy signal for supply chain and poisoning work in safety-critical settings is the July 2025 *America's AI Action Plan*. It says AI used in safety-critical or homeland security applications should be secure by design, robust and resilient, and instrumented to detect performance shifts and alert to malicious activity such as data poisoning or adversarial example attacks. For a team that runs a model trained on third-party or web-scraped data, that wording turns poisoning from a research topic into a monitoring requirement. The practical question is whether the deployed system would notice a shift in behavior that a poisoned training set or a compromised pre-trained model could cause, and whether anyone would be alerted in time to act.
The Action Plan also recommends a DHS-led AI Information Sharing and Analysis Center (AI-ISAC). If your organization operates in a critical sector, decide now who would send and receive poisoning or model-compromise indicators, how those reports would reach the AI-ISAC if it is established, and which internal roles would triage them. Map those roles to the AI inventory entries for pre-trained models, so that a report can be traced to every system that depends on the affected component.
Confirm the status of the framework itself before you cite it in a policy or contract. NIST says the AI RMF is being revised as part of the White House AI Action Plan, and as of 17 October 2026 it has not published a revised version. Check the current NIST AI Risk Management Framework page and the announcements from your sector regulator, because the revision could change the wording of the subcategories you rely on. Record the version you used in your documentation so that later audits can see which baseline applied at the time.
Frequently asked questions about NIST AI supply chain and poisoning guidance
Does NIST certify that an organization complies with its AI supply chain and poisoning guidance?
No. NIST does not certify, accredit or validate organizations against the guidance in AI 100-2e2025 or the Generative AI Profile in AI 600-1. The AI Risk Management Framework is voluntary, and NIST's use cases page states that NIST does not validate or endorse any individual organization or its approach. Any statement that an organization is "NIST compliant" for poisoning controls is a self-description unless an independent assessor has tested specific controls and issued a report. When a customer or regulator asks for proof, ask for the named control objectives, the evidence behind each one, and the identity and scope of any independent assessor. DeployOpen prepares systems, controls and evidence for assessment, but it does not issue audit reports or certifications.
What does it cost to verify training data provenance, and who gets paid for that work?
No published NIST figure exists for this work, so the cost depends on your own data estate. The main cost components are engineering time to build hash verification and provenance records into data pipelines, data owner time to document sources and licenses, and review time for any filtering or relabeling. Most of this is one-time build effort followed by recurring effort each time a dataset is refreshed. Costs rise with the number of external data sources, the size of web-scale corpora and the number of teams that retrain models. Costs fall when provenance metadata is captured at ingestion rather than reconstructed later. When requesting a quote from any implementation partner, ask for the work broken into pipeline changes, documentation, tooling, testing and handover, and ask which items are one-time and which recur.
Can our own team verify AI supply chain risk without outside help?
Often yes, if the team has security engineering skills and clear ownership of the data and model pipelines. AI 100-2e2025 notes that traditional practices such as vulnerability scanning of model artifacts help with some AI supply chain risks, so existing software supply chain staff can take on part of the work. The gaps tend to be AI-specific: detecting poisoning that a scanner will not flag, monitoring pre-trained models over time and documenting provenance for datasets. Internal teams should first confirm whether they have an AI inventory that lists pre-trained models and their connected components, because the Playbook's MANAGE 3.2 suggestions depend on it. An external partner can help with design, testing and evidence preparation, while the organization keeps ownership of the risk decisions.
What do engineering and data owners need to provide for this work?
The work needs named owners for each training, fine-tuning and retrieval data source, plus engineers who can change ingestion and build pipelines. Data owners must record where each dataset came from, which terms apply and who approved its use. Engineers must be able to store published cryptographic hashes alongside downloads and check them before use. Model owners must maintain an inventory entry for each pre-trained model, its version, its source and its monitoring plan. Security staff need access to evaluation environments to test for backdoor and targeted poisoning behavior. If any of these owners are missing, the work stalls at the point where evidence should be produced. Ask a partner to show, in writing, which inputs they need from each role and how often those inputs must be refreshed.
Can we assess a third-party model without the vendor's cooperation?
Only in part. Without vendor cooperation, you can test the model's behavior from the outside, monitor its outputs in your own environment and check any artifacts the vendor publishes, such as hashes or release notes. You cannot independently verify the vendor's training data, its poisoning filters or its internal provenance records. AI 100-2e2025 notes that filtering poisoned samples from a large corpus may be very difficult, so behavioral testing and ongoing monitoring become the main tools. Contract terms matter here. Before purchase, ask the vendor for provenance information, notification commitments for model changes and the right to decommission the model if its risk exceeds your tolerance. Record any gaps as residual risk so that a decision maker can accept or reject them.
Who issues an assessment report on our AI supply chain controls?
Only an independent auditor, assessor or certification body issues an assessment report or certificate. NIST publishes guidance, and an implementation partner prepares systems, controls and evidence, but neither can attest to your controls. The organization owns its controls and decides what to disclose. If a contract or regulator requires a report, confirm which assessment standard or framework it refers to, because the attestation type and the assessor's qualifications depend on that choice. Ask any assessor to state the scope, the criteria and the period covered by the report before engagement.
How to choose a partner for AI supply chain controls
Outside help on AI supply chain controls usually fails at the seams: software practice without AI provenance, scope that drifts, or evidence that someone mistakes for an assessment. The four questions below help you test a partner on those seams before you sign. None of them is a guarantee, and each should be answered in writing.
Software and AI supply chain depth
Ask whether the partner can show how software supply chain practice, such as dependency inventory and vulnerability scanning of model artifacts, is extended with AI-specific provenance for training data, pre-trained models and plugins. AI 100-2e2025 notes that traditional scanning helps with some risks but that new approaches are needed to detect vulnerabilities introduced through model poisoning. Ask who in the team monitors pre-trained model performance and trustworthiness over time, not only at intake.
Written scope and deliverables first
Ask for a written scope that names the AI systems, data sources, model components and plugins in or out of bounds, along with the deliverables and the order in which they will be produced. A useful test is whether the scope lists the pre-trained models in your AI inventory and states how each will be monitored and decommissioned if it exceeds your risk tolerance. Agree the scope before work starts, so that changes are recorded rather than absorbed silently.
Preparation versus issued reports
Confirm in writing that the partner prepares systems, provenance records, monitoring procedures and evidence, and that it does not issue audit reports, attestations or certifications. The NIST AI RMF has no certification program, so any document claiming to certify your supply chain controls should prompt questions. Ask which artifacts your own risk and governance owners will sign, and who keeps them current after handover.
Independent assessor selection
If an outside assessment is required by a contract, customer or regulator, check that the assessor is selected and engaged by your organization, and that the partner does not choose or recommend it on the assessor's behalf. Ask how the partner's evidence will be made available to that assessor, and whether the partner's staff will be available to explain verification steps such as hash checks on web-scale training data. Keep the assessor and the implementer separate in your records.
How DeployOpen prepares AI supply chain evidence
DeployOpen is a Chainscore Labs company that plans, implements, hardens and documents self-hosted open-source platforms inside the client's own infrastructure. For NIST guidance on AI supply chain attacks and data poisoning, we prepare the systems, records and evidence that show how training data, pre-trained models and plugins are sourced, checked and monitored, while the organization keeps ownership of its controls and risk decisions.
How we scope
- Engagements are fixed-scope, with the systems, model sources and data pipelines in scope agreed in writing before work starts.
- We confirm which AI systems in the inventory use pre-trained models, third-party datasets or plugins, and record the owner of each.
- The written scope names the evidence each deliverable will produce, so the organization and its auditor know what to expect.
How we build
- We set up hash verification of downloaded datasets and model artifacts against provider-published values, and record each check.
- We configure provenance records for training and evaluation data, including source, version and transformation history.
- We test poisoning exposure in the client's environment and document results, limitations and remediation owners.
How we hand over
- Deliverables include configuration records, provenance logs, test reports and a pre-trained model entry for the AI inventory.
- Documentation explains which evidence supports which NIST subcategory, written so the client's team can maintain it.
- We walk the client's security, data and AI teams through the handover so the records stay usable after the engagement ends.
How we support
- Ongoing support, upgrades and continuous testing are available as retainers for systems that change after handover.
- Retainers can cover periodic re-testing of models and data sources, and review of new third-party components.
- Assessments are carried out by an independent auditor or assessor, and DeployOpen does not issue reports or certificates.
