AI Supply Chain Security: Provenance, AI-BOMs & Model Signing

• AI supply chain security protects models, data, tools, and dependencies.

• Model provenance shows where a model came from and how it was derived.

• AI-BOMs reveal models, datasets, APIs, and dependencies.

• Model signing verifies model integrity and authenticity.

• Third-party risk covers external models, vendors, and hidden dependencies.

• Continuous monitoring tracks model and dependency changes at runtime.

Risks enter through models, datasets, dependencies, and external services. Some change how a model behaves. Others open a path into the infrastructure around it.

Figure 01 · The model trust gap

Four incidents from 2025 and 2026.

Model provenance is verifiable evidence of where an AI model came from, who produced it, and how it was created or modified.

It gives visibility into parent models, datasets, versions, and licenses before a model reaches production, instead of trusting publisher metadata.

Model Provenance vs. Model Lineage vs. Data Provenance

Although these terms are related, they track different parts of an AI model's history.

Together they make a model traceable across its lifecycle.

What Should Model Provenance Track?

A useful record captures enough to verify a model and see how it changed:

• Source and provider
• Name and version
• Parent or base model
• Fine-tuning or other modifications
• Dataset references
• Framework and dependency versions
• Licensing information
• Cryptographic hashes for integrity checks

An AI-BOM, also written as AIBOM or AI Bill of Materials, is a structured inventory of the models, datasets, frameworks, APIs, prompts, embeddings, and other assets used in an AI system.

It answers what your AI applications depend on and what breaks when one of those assets changes.

AI-BOM vs. SBOM

An SBOM covers software packages. An AI-BOM extends that to models, datasets, prompts, embeddings, and external AI services.

The two work together. AI systems still run on ordinary software, and the AI-BOM adds what an SBOM cannot see.

AI-BOM Formats

CycloneDX ML-BOM and the SPDX AI Profile both provide machine-readable structure for models, datasets, versions, licenses, and provenance. The format matters less than keeping the inventory current, so review it whenever a model is fine-tuned, replaced, or repointed at a new provider.

AI model signing uses cryptographic signatures to verify who published or approved a model and whether the artifact has changed.

The signer hashes the model files and signs a manifest of those hashes. Anyone can re-hash and verify, so any modification breaks verification.

Figure 02 · Verification at deployment

What Model Signing Proves

A valid signature confirms two things:

Model Scanning vs. Model Signing

Scanning checks an artifact for malicious content. Signing confirms the artifact reaching production is the one you approved. Scan first, record the hash, sign the approved artifact, verify before deploy.

Model Signing Standards: OMS, Sigstore, and Attestations

OpenSSF Model Signing (OMS) handles AI model artifacts and supports identity-based signing through Sigstore. Provenance attestations add verifiable detail about how an artifact was produced.

Third-party AI risk is the security, privacy, operational, or compliance exposure a business inherits from external models, APIs, datasets, tools, and service providers.

It is hardest to manage where teams cannot see how a vendor builds, updates, or secures what they supply.

Figure 03 · Third and fourth party exposure

Fourth-Party AI Risk

This appears when a vendor quietly depends on another AI provider, such as a SaaS platform calling a foundation model or inference API you never contracted with. You cannot assess a provider you do not know you rely on.

What Should You Ask AI Vendors?

Standard questionnaires rarely cover AI, so ask for evidence rather than assurances. Every question below maps to something reviewable.

These surface hidden dependencies before an external service reaches production.

Each control answers a different part of the same question: what you use, where it came from, and whether it still matches what you approved.

An AI-BOM answers what exists. Provenance explains where it came from. Scanning inspects the artifact. Signing binds approval to that exact artifact. Monitoring catches what changes after deployment.

Seven controls across sourcing, development, deployment, and runtime.

Figure 04 · Lifecycle with a blocking deployment gate

These controls produce the records regulators ask for: models, datasets, suppliers, dependencies, and changes. They strengthen documentation and auditability, but no artifact alone proves compliance.

Article 53(1)(d) ties most directly to provenance work: providers of general-purpose AI models must publish a sufficiently detailed summary of training content.

What AI Act Requirements Apply Now, and What Comes Next?

The Act lands in stages, and the AI Omnibus pushed the high-risk dates back further. Each milestone below is marked against today's date.

The 2 August 2027 date comes from Article 111(3), a transitional period for GPAI models already on the market before 2 August 2025. The later high-risk deadlines are not a reason to postpone inventory or provenance work, because those records earn their keep long before then.

Each lifecycle stage, its main risk, the control that reduces it, and the evidence to keep.

The evidence column is what makes this auditable. Each control leaves an artifact that both an engineer and an auditor can work from.

AI supply chain security comes down to three questions a team should be able to answer at any moment: what AI assets are in use, where they came from, and whether they have changed since approval. Most organizations still cannot answer all three, even as platforms adopt artifact signing and documentation rules turn inventories into a compliance concern. None of this needs solving at once, so start with discovery, because every other control depends on knowing what exists.