If your product uses AI, say that the SBOM covers the software components, including AI libraries and SDKs, and that model and data details are documented separately. CISA's 2026 guidance says AI systems may have extra components the minimum elements do not capture, and it adds no AI specific fields.
What the guidance actually says
The 2026 minimum elements document states that AI software systems, like cloud and SaaS environments, may have additional components not captured by the minimum elements. It points out that since AI is software, the minimum elements illuminate many components an organization should know about. It then mentions "model cards" and "data cards" as examples of additional supply chain data, notes there are ongoing discussions about SBOM for AI use cases, and states plainly that the document does not introduce additional elements for AI systems (see Sources).
So the honest answer has two layers: the standard SBOM, and whatever extra documentation you maintain.
What goes in the SBOM today
Your regular SBOM tooling will pick up many AI related components because they are ordinary packages.
- Machine learning and model serving libraries in your lockfiles.
- Client SDKs for any third party model API you call.
- Vector database clients and orchestration frameworks.
- Container images used to serve or run inference.
List these like any other dependency, with versions and identifiers.
What does not fit neatly
Some things are not software packages in the usual sense.
| Item | Typically in an SBOM? | Where to document it |
|---|---|---|
| Third party model API you call | No, it is a service | Vendor list and data flow note |
| Model weights you host | Not in minimum elements | Model card or internal record |
| Training or fine tuning data | No | Data card or data inventory |
| Prompts and system instructions | No | Internal documentation |
Do not stretch the SBOM to hold these. Keep a short companion note instead.
A truthful script
"Our SBOM lists the software libraries and SDKs behind our AI features, including client libraries for the model provider we call. The provider itself is on our vendor list. We keep a separate note on which models we use, where they run, and what data is sent. The CISA guidance does not yet define AI specific SBOM fields, so we follow it as written."
What to leave unclaimed
- Do not say you have an "AI SBOM" unless you can define what it contains.
- Do not claim the SBOM proves anything about model behavior or data quality.
- Do not describe provider internals you have not confirmed in writing.
Prepare the companion note
A half page is enough: models in use, who hosts them, what customer data reaches them, whether any customer data is retained or used for training under your agreement, and who to ask. Get the data handling statements from your provider's documents, and cite them if you quote them.
Where Safeguard fits
Safeguard's SBOM and dependency scanning covers the libraries behind your AI features like any other package, and its MCP Guardrail and agent identity capabilities address how agents and tools are controlled. Try the free scan to see what your AI related dependencies look like.
Try it yourself
Click through it at your own pace, or open it full screen.
Look at how tool connections are configured, since agent tooling is a growing part of what AI products depend on.
Quick check
Does a standard SBOM cover model weights?
Not under the 2026 minimum elements. Document weights and data in a model card or similar record, and say that is where they live.
Should I list the model API provider in the SBOM?
Usually it belongs on your vendor list as a service. List the client SDK you use as a component in the SBOM.
Sources
Last reviewed: 19 October 2026.
