Why We Built AIBOM Export with CycloneDX into Prediction Guard

When we started talking internally about adding AI Bill of Materials (AIBOM) export to the Prediction Guard platform, the conversation wasn't about checking a compliance box, it was about owning your AI. This was recently highlighted as a call to action by Probabl. More specifically, it was about a problem our customers kept running into: they couldn't answer basic questions about what was actually running inside their AI systems.

"Which model version produced this output six months ago?"

"What guardrails were active when this prompt ran?"

"Can you prove to our auditor that no unapproved model touched regulated data?"

If you've shipped AI into production at any reasonable scale, you've heard some version of these questions. And if you're honest, you've probably struggled to answer them quickly.

That's why we shipped AIBOM exports using the CycloneDX format. Here's why it matters from an engineering, audit, and supply chain perspective.

The Problem: AI Systems Are Opaque Supply Chains

A modern AI application isn't a single artifact. It's a composition of:

• Foundation models (often from third parties)

• Tokenizers, embedding models, rerankers, and document parsers

• Datasets used for augmentation, context engineering, or RAG

• Prompt templates and system instructions

• Input and output guardrails (PII filters, injection detection, factuality checks, toxicity classifiers)

• Inference infrastructure and runtime dependencies

Every one of those components has a provenance, a license, a version, and a risk profile. Traditional SBOMs were designed for software libraries. They don't capture model weights, training data lineage, or the behavioral controls wrapped around AI agents.

Without a structured way to inventory all of this, security teams are doing archaeology instead of audits.

Why CycloneDX

We had a choice to start with one format. CycloneDX won for a few practical reasons:

1. It's an OWASP-backed open standard with active extensions for ML and AI components (the ML-BOM and AI/ML extensions). This isn't a proprietary lock-in or a homegrown JSON schema we'd have to maintain forever.

2. It already integrates with the tooling our customers use: Dependency-Track, Snyk, Anchore, and most major SCA platforms parse CycloneDX natively. AIBOM data flows into the same pipelines as the rest of an organization's SBOM data.

3. It supports the full graph: components, services, dependencies, vulnerabilities, licenses, and ML-specific metadata like model parameters, datasets, and considerations.

4. It's machine-readable and signable. You can hash it, sign it, store it in a registry, and verify it later. That matters for non-repudiation.

Building on an existing standard meant we could focus on capturing the right AI-specific metadata rather than reinventing the document format.

What's in a Prediction Guard AIBOM

When you export an AIBOM from Prediction Guard, you get a CycloneDX document that includes:

• Models in use: name, version, provider, hash, and parameters

• Guardrails and validators configured: factuality, toxicity, PII detection, prompt injection protection, output schema validation

• Dependencies between components: which guardrails wrap which models, which models are routed to under which conditions

• Licensing and provenance metadata for each component

• Service definitions describing the inference endpoints exposed to applications

This is the artifact your security, compliance, and procurement teams have been asking for, and it can be generated automatically from the actual running configuration (not a Confluence page someone updated last quarter).

Why This Matters for Audit

Auditors don't want screenshots. They want evidence that is reproducible, timestamped, and tied to a specific point-in-time configuration.

With AIBOM export, an audit workflow looks like:

1. Export the AIBOM at the time of the control event (deployment, incident, periodic review).

2. Store it alongside your other compliance artifacts.

3. When asked, produce the exact inventory of models, guardrails, and dependencies that were live.

For frameworks like the EU AI Act, NIST AI RMF, ISO/IEC 42001, and SOC 2 controls that increasingly include AI-specific clauses, this kind of structured evidence shortens audit cycles dramatically. Instead of interviews and tribal knowledge, you produce a signed document.

Why This Matters for Supply Chain Security

Although the AI supply chain has some of the same risks as the software supply chain, agentic systems introduce a few new ones:

• Model provenance: Was this model pulled from a trusted registry? Has it been fine-tuned on data you can account for?

• License drift: Foundation model licenses change. Knowing exactly which version you're running protects you from inheriting terms you didn't agree to.

• Vulnerability tracking: When a new prompt injection technique or jailbreak is disclosed against a specific model family, you need to know within minutes whether you're exposed.

• Third-party risk: When your customer asks for a list of every model touching their data, you can produce it from automation rather than a spreadsheet.

Because the AIBOM is CycloneDX, it slots directly into existing supply chain tooling. Your Dependency-Track instance ingests it. Your vulnerability feeds match against it. Your incident response playbooks work the same way they do for software CVEs.

Engineering Perspective: This Should Be a Default, Not a Premium

I'll be blunt: any serious deployment of AI agents should be producing AIBOMs. The argument that AI systems are too novel or too dynamic to inventory is wearing thin. The components are knowable. The configurations are knowable. The dependencies are knowable. We just need to expose them in a standard format.

We made AIBOM export a first-class capability in Prediction Guard because the alternative (customers reverse-engineering their own AI inventories from logs and config files) is not acceptable in 2026. If your organization is building and deploying agents in high impact or regulated environments, you need this.

What's Next

We're continuing to expand the AIBOM coverage:

• Richer dataset lineage for all model types (LLMs, LVMs, STT, etc.)

• Automatic diffing between AIBOMs across deployments

• - Support for additional BOM formats (SPDX, CSV) along with human readable outputs

• Integration with attestation frameworks (in-toto, SLSA) so AIBOMs can be signed as part of the build pipeline

• Vulnerability feed and AI component risk integration specific to model, MCP, and guardrail components

If you're running AI in production and your security team can't tell you what's actually deployed, talk to us. The export is a few clicks (or one API call) away — and once it's in your supply chain pipeline, the questions that used to take a week now take a query.

That's the bar. That's what shipping AI responsibly looks like.