To secure a software supply chain that includes AI, treat models, datasets, prompts and agent tools as dependencies. Inventory them, record where each came from, pin exact versions, review what changes and assign an owner. NIST's AI profile for the Secure Software Development Framework gives a recognized structure for this.
What does NIST say about AI in the SDLC?
NIST SP 800-218A is a community profile that augments the Secure Software Development Framework, SSDF version 1.1, with practices, tasks and recommendations specific to AI model development throughout the software development life cycle. NIST says it is meant for the producers of AI models, producers of AI systems that use those models and acquirers of those systems, and should be used together with SP 800-218.
The final version is dated July 2024 and its abstract ties it to Executive Order 14110. Check the NIST page for the current status of both before you cite them in a policy. The practices describe secure development work either way.
What new items are in the chain?
Constructed example: a support team builds a chatbot. It pulls a base model from a public hub, fine tunes on a dataset the team exported from tickets, calls a vendor API for embeddings, loads a handful of Python libraries and lets the bot use two tools that read the knowledge base and create tickets.
That is at least six supply chain items that a traditional software bill of materials might not list: the model weights, the dataset, the embedding service, the prompts and system instructions, the tools the agent can call and the serving code. Each can change behavior, and each can be tampered with or simply replaced.
What can go wrong?
- A model artifact is swapped or modified upstream, and you pull the new one by name.
- Training or fine tuning data contains sensitive records or poisoned examples.
- A dependency in the serving stack carries a known vulnerability.
- A tool the agent can call is more powerful than the task needs.
- A vendor model changes behavior without notice, and your evaluation results no longer hold.
How to check or apply this
- Inventory. List every model, dataset, service, library and tool in each AI feature, with version and source. Add them to your SBOM or keep a companion record.
- Provenance. For each item, note who published it, under what license, and how you verified it. Prefer sources that publish checksums or signatures, and verify them.
- Pin. Reference models and datasets by immutable identifier or hash, not by a floating name or "latest".
- Isolate and limit. Run model loading and tool execution with minimal permissions, and give agents the narrowest tool set that does the job.
- Evaluate on change. Treat a model or dataset update like a code change: rerun your tests and safety checks before promoting it.
- Protect data. Classify what goes into training and prompts, and remove what should not be there.
- Monitor. Track advisories for libraries and serving components, and log tool calls.
- Name an owner for each AI component, as you would for a service.
Where do scanning and policy fit?
Much of the chain is ordinary software, and the old controls still apply. Safeguard scans dependencies, generates software bills of materials and applies policies and gates in pull requests, which covers the libraries around your models. For agents that call tools through MCP, its MCP Guardrail adds policy on those calls. Models and datasets still need the provenance and evaluation steps above.
How do you handle third party model APIs?
A hosted model is a dependency you cannot pin by hash, because the vendor controls it. Record the model name and version you called, keep a regression set of prompts with expected behavior, and rerun it on a schedule and whenever the vendor announces a change. Limit what you send to the API to what the task needs, and check the vendor's data handling terms against your own obligations. Have a fallback plan if the service changes or disappears.
Quick check
Is an SBOM enough for an AI system?
Not on its own. A traditional SBOM lists software components. You also need records for models, datasets, prompts and tools, because they affect behavior and can be changed or tampered with.
What is the first step?
Make an inventory of every model, dataset, service and tool in one AI feature, with version and source. You cannot pin or review what you have not listed.
Sources
- NIST SP 800-218A, Secure Software Development Practices for Generative AI and Dual-Use Foundation Models
- NIST SP 800-218, Secure Software Development Framework
Last reviewed: 18 October 2026.
