Why a Component List Was Never Going to Be Enough
An SPDX or CycloneDX SBOM answers a specific question well: which packages, at which versions, with which licenses, are compiled or bundled into this artifact? That question maps cleanly onto traditional software, where a dependency is a discrete, versioned, mostly-static thing.
AI systems break that model in three ways. First, the highest-risk "component" in an AI application is often not a package at all — it is a set of model weights pulled from a hub like Hugging Face, with no equivalent of a CVE database, no standard versioning scheme, and frequently no clear record of what data it was trained on. Second, an AI system's behavior depends on artifacts that a package-manifest scanner will never see: system prompts, fine-tuning datasets, retrieval indexes, and increasingly the tool and MCP server definitions that give an agent the ability to act. Third, agents compose other agents — an "agentic skill" installed into one system may itself invoke a third-party model or a remote MCP server, creating a dependency graph that has no analogue in classic software composition analysis.
Security teams that pointed their existing SCA tooling at an AI product and concluded they had full visibility were, in most cases, only seeing the conventional Python or TypeScript scaffolding around the AI system — not the AI system itself.
What CISA and G7 Actually Published
"Software Bill of Materials for AI: Minimum Elements" is a joint publication from CISA and G7 cybersecurity partners, built as a direct extension of the NTIA's 2021 SBOM minimum elements and the refreshed 2025 CISA minimum elements guidance. Rather than replacing the existing SBOM framework, it adds an AI-specific layer on top of it — the same seven baseline fields (supplier, component name, version, unique identifiers, dependency relationships, author, timestamp) plus a set of fields that only make sense in an AI context.
| AI-BOM Field | What It Captures | Why It Matters |
|---|---|---|
| Model provenance | Origin, training organization, and modification history of a model | Distinguishes a vetted base model from an unverified fine-tune or a swapped checkpoint |
| Training / fine-tuning data source | Dataset identity, licensing, and known sensitive-data exposure | Surfaces license and privacy risk that no dependency scanner can see |
| Model architecture / framework | The ML framework and architecture family the model relies on | Enables matching against framework-level CVEs, e.g. in inference runtimes |
| Agentic capabilities | Tools, function calls, and actions an agent is authorized to invoke | Defines the actual blast radius if the agent is manipulated or jailbroken |
| MCP / external service connections | Every MCP server and external API an agent or model can reach | Treats each connection as a supply chain edge, not an implementation detail |
The guidance defines AI-BOM scope broadly: models, datasets, SDK libraries, MCP servers, ML frameworks, agents, agentic skills, and prompts — plus how those components interact with each other and with the rest of the application. It is explicitly designed to sit alongside, not replace, your existing SPDX/CycloneDX SBOM.
Cisco's Open Source Move
The same week the guidance shipped, Cisco open-sourced two tools that give the framework practical teeth. The first is an AI-BOM scanner that inventories AI components across codebases, container images, and cloud environments — the same three surfaces conventional SCA tools already cover, now extended to detect model files, embedding stores, and agent configuration alongside ordinary packages. The second is a Model Provenance Kit, a standalone open source tool focused specifically on establishing and verifying where a model actually came from — closing the gap where organizations could generate a technically complete SBOM while still having no idea whether the model checkpoint in production matches the one that was originally vetted.
Releasing both as open source rather than as proprietary platform features is a deliberate signal: Cisco is betting that AI-BOM adoption follows the same trajectory SBOM did after the 2021 NTIA guidance — slow until free, well-known tooling made the first scan trivial, then rapid once procurement and compliance teams started asking for the output.
The Attack Surface This Actually Closes
This is not a paperwork exercise. Every field in the AI-BOM minimum elements maps to a concrete incident pattern security teams have already seen: models pulled from public hubs with tampered weights, fine-tunes trained on scraped data carrying license or privacy exposure they never disclosed, and — the fastest-growing category in 2026 — agents wired up to MCP servers that were never reviewed by anyone outside the engineer who added them.
An MCP server is, from a risk standpoint, indistinguishable from a transitive package dependency: code you did not write, running with access you granted, chosen by whichever engineer needed a capability fastest. Unlike a package, it usually is not pinned, versioned, or scanned by anything in your existing pipeline. Treat every MCP connection your agents can reach as a first-class entry in your AI-BOM, not a configuration detail.
Building an AI-BOM Practice: Where to Start
Organizations that already run a mature SBOM program have most of the process muscle they need — the gap is almost entirely in tooling coverage and inventory scope, not in process design.
- Inventory your models first. List every model in production or staging, its source, and whether it is a vetted base model, a licensed API, or an internally fine-tuned variant.
- Extend scanning to model files and datasets. Standard SCA tools do not inspect .safetensors, .gguf, or pickle files for provenance — you need AI-aware scanning layered on top, not instead of, your existing SCA coverage.
- Catalog agentic capabilities explicitly. For every agent, document the tools, function calls, and MCP servers it can invoke. This becomes your blast-radius map if the agent is compromised.
- Apply the same freshness discipline you use for SBOM. A model swapped in production without an AI-BOM update is the AI-era equivalent of the SBOM drift problem — the declared inventory silently stops matching reality.
- Feed AI-BOM data into the same governance process as your SBOM. Do not stand up a parallel AI security program; extend the OSPO or security team mandate that already owns component transparency.
SBOM and AI-BOM From a Single Platform
Fossity is extending its SBOM generation and continuous monitoring to cover AI-BOM minimum elements — model provenance, dataset licensing signals, and agent/MCP connection mapping — alongside the traditional component inventory you already rely on. One platform, one policy engine, one place to answer "what is actually running in production."
See Fossity's AI-BOM Roadmap →What to Expect Next
Minimum elements guidance has historically been the leading indicator for regulation, not the end state — the 2021 NTIA SBOM guidance took roughly a year to show up in procurement language and contractual requirements. Expect the same pattern here: federal AI procurement and the EU AI Act's transparency obligations are the two most likely near-term forcing functions that turn AI-BOM from "leading-edge good practice" into a line item vendors are asked to produce on demand.
The organizations that will handle that transition smoothly are the ones treating AI-BOM as a natural extension of the SBOM program they already run — not a separate initiative bolted on after the fact.