An AI deployment depends on more than a model name. Imported weights, packages, data pipelines, retrieval corpora, plugins and evaluation artifacts can each create a separate path for compromise.
Inventory what you actually run
Record model source, immutable identifier when available, hash, license, inference runtime, container image, dependency versions, tool permissions and data sources. A friendly repository title is not a security assessment. Signed packages and reproducible builds improve traceability, but they do not establish that code or training data is benign.
Threats at different stages
During development, a poisoned training or fine-tuning dataset can alter outcomes. A malicious package can execute ordinary software code. Model weights and serialization formats may require special care because unsafe loading routines can run code. At retrieval time, hostile documents can inject instructions. At deployment, excessive permissions or weak logging can multiply the impact of any compromise.
Make provenance actionable
Prefer artifacts from traceable maintainers; verify download hashes against trusted channels; isolate experimentation from production secrets; and scan packages using the organization’s established secure-development pipeline. Document dataset permission, licensing, deletion pathways and changes in source terms. Review model cards or data sheets critically rather than treating their existence as proof of safety.
Change control
Pin versions, test staged upgrades, maintain a dependency register and have a rollback package. A silently replaced model alias or index rebuild may change behavior without a new marketing launch. Capture important output regressions and unexpected network activity before promotion to production.
Short example
A team downloads a community model to summarize legal documents. Before allowing it onto internal systems, the team checks artifact provenance, reviews its loading method, verifies license restrictions, runs it in an isolated environment and tests on permitted synthetic cases. Only a documented review grants access to real documents.
Boundary and limitations
NIST’s adversarial ML taxonomy is a risk vocabulary, not a universal prescribed checklist. Software supply-chain controls, privacy reviews and model performance evaluation remain separate activities that must be combined.
Sources & Further Reading
- NIST AI 100-2e2025 Adversarial ML Taxonomy — NIST.
- MITRE ATLAS — MITRE.
- NIST AI Risk Management Framework 1.0 — NIST.
Guidance varies by jurisdiction and application. This is general education, not legal, medical or other professional advice.