How to Verify Supply-Chain Provenance for AI Agent Dependencies
An operational playbook for three separate trust-boundary gates — package-install time, model-load time, and MCP-server-connect time — that turns SBOM and attestation formats into checks a pipeline can actually run, plus a fail-closed default for the dependency that carries neither.
- Supply-chain provenance verification for an AI agent's dependencies needs three separate gates — package-install time, model-load time, and MCP-server-connect time — because each one hands the agent a different kind of artifact and no single generic check covers all three.
- A build or CI pipeline should fail a dependency install outright when no bill of materials is present at all, rather than logging a warning and letting the install proceed on the assumption someone will review it later.
- A third-party model should carry a CycloneDX entry using the schema's dedicated machine-learning-model component type, or an SPDX 3.0 AI-profile record, ideally alongside a modelCard field naming its training data and intended use, before an agent loads it.
- Connecting to an MCP server should be gated on four checkable items at once — an exact pinned version, a verified checksum or signature, an audited tool-description field, and a minimum-scope OAuth grant — not a one-time read of its documentation months earlier.
- A dependency carrying neither a bill of materials nor a build-provenance attestation should be blocked from installing, loading, or connecting by default, with any override recorded as an explicit, logged risk acceptance rather than a silent exception.
- Passing every provenance check does not replace code sandboxing or credential scoping, because a clean bill of materials proves what a package declares to contain, not that its actual implementation can't misbehave once it runs.
Three checkpoints, not one generic supply-chain check
Supply-chain provenance verification for an AI agent's dependencies breaks into three separate trust boundaries — package-install time, model-load time, and MCP-server-connect time — because each one hands the agent a different kind of artifact at a different point in its lifecycle, and a single generic "check the BOM" step misses the parts specific to each. A package arrives once and sits static in a lockfile. A model gets loaded and reasoned over directly. An MCP server stays live and connected, gets handed live tool-calling authority, and can change what it does on any given day without a version bump at all. The agent security operations pillar already covers the underlying formats these three gates are built on — CycloneDX, SPDX, SLSA, in-toto and Sigstore — at comparison-table depth; this piece turns that ground into the checks a pipeline actually runs at each boundary, plus what to do by default when none of them exist.
What should a CI pipeline check before pulling a dependency?
A CI pipeline should check four things before a package ever enters an agent's build, in order of what each one actually proves:
| Check | What it proves | Fails closed when |
|---|---|---|
| BOM presence | A structured inventory ships with the release at all | No CycloneDX or SPDX file accompanies the package |
| Format validity | The file actually parses as a real bill of materials | The file exists but doesn't validate against the CycloneDX or SPDX schema |
| Declared-contents match | The BOM's component list matches what actually gets imported | The lockfile pulls a component the BOM never declared |
| Attestation presence | The artifact was built the way its publisher claims, not merely inventoried | No SLSA provenance record, or no in-toto/Sigstore signature over it |
The first two checks are cheap and mechanical — a missing or malformed BOM is a binary, automatable gate, not a judgment call for a reviewer to make case by case. The third catches a stale BOM: a real bill of materials that no longer matches the code it's attached to is functionally indistinguishable from no BOM at all once a pipeline installs something the document never mentioned. The fourth is the layer the AI supply chain provenance reference is clearest about: Sigstore's Fulcio issues a short-lived certificate tied to the build's own identity, Rekor logs that signature in a public transparency log, and an SLSA provenance record ties the two together — a chain that answers a genuinely different question than any BOM can, moving from "the inventory wasn't tampered with in transit" to "the build itself happened the way the publisher says."
Model-load time: verifying a third-party model before you load it
Before an agent loads a third-party model, check that its release carries a machine-readable inventory of what the model actually is, not just a README description of what it claims to be. The CycloneDX 1.7 schema gives a model its own dedicated machine-learning-model component type, a separate data type for any bundled dataset, a formulation field covering how the artifact was produced — including AI/ML model training as a named case — and a modelCard property for training-data and intended-use metadata. SPDX 3.0's AI profile is the ISO-standardized alternative; per the resource's own WebSearch-corroborated sourcing it covers a model's domain and type, its training method, how its data was handled, its explainability, and its energy consumption, with a companion Dataset profile for collection method, preprocessing, and intended use.
Neither format is universal yet as of September 2026 — the OWASP AIBOM Generator, moved under the OWASP GenAI Security Project in December 2025, currently targets Hugging-Face-hosted models specifically and produces CycloneDX-format output aligned with SPDX, not every model-hosting surface a team might pull from. Where a modelCard field or an SPDX AI-profile record is present, treat its training-data and intended-use claims as the load-time gate; where it's absent, the model falls straight into the fail-closed default below.
What should you check before connecting to an MCP server?
Connecting to an MCP server should be gated on four checkable items at once, because a server is a live, running dependency that can change what it does without any version bump the way a pinned package can't. The agentic security checklist (updated 15 August 2026) states these as seven prose bullets under its own MCP-supply-chain section; the table below turns four of them into a connection gate built on the BOM and attestation formats above, not a one-time read of a server's documentation.
| Checklist guidance | Gates | Machine-checkable form |
|---|---|---|
| "Pin package versions with lock files and verify checksums" | Which exact build you're connecting to | Version pinned in a lockfile; checksum or Sigstore signature verified against Rekor's transparency log on every connection, not just the first |
| "Audit the tool description text of every MCP server before connecting" | What the server's tools claim to do | Current tool-description text diffed against the last-approved snapshot on every update, not re-read from memory |
| "Prefer OAuth 2.1 + PKCE... scope OAuth tokens to the minimum required tools" | What the server can actually do once connected | Per-agent OAuth client issuing a token scoped to only the tools the task needs, mandatory since the 2025-06-18 MCP spec |
| "Revoke server access when the agent task is complete" | How long access stays open | Token expiry tied to task completion, not a standing grant |
The checklist names a concrete reason version-pinning is item one rather than optional advice: the first documented malicious MCP package appeared in September 2025, which makes "connect once, trust indefinitely" the specific failure mode this gate exists to close. None of these four checks is MCP-specific in its underlying format — a checksum, a signature, and an OAuth scope are general security primitives — but an MCP server's live, mutable nature is what makes re-checking them on every connection matter, not only on the first one.
What do you do when no BOM or attestation exists at all?
The fail-closed default is to block a dependency automatically when it carries neither a bill of materials nor a build-provenance attestation, requiring an explicit, logged exception before it proceeds. That default beats leaving the call to a reviewer's best-effort judgment under deadline pressure, since that pressure is exactly the condition under which a rushed exception quietly becomes the norm. The default takes a slightly different concrete shape at each checkpoint:
Package-install time. Fail the CI build outright. This is the cheapest checkpoint to enforce mechanically, since the check runs before any code from the dependency has executed anywhere.
Model-load time. Require a named reviewer's manual sign-off before the model loads into a production path, since an unverified model's training data and intended use can't be checked automatically without a
modelCardor AI-profile record to check against.MCP-server-connect time. Refuse the connection by default; only allow it after a manual review of the server's actual behavior, with the resulting grant recorded as an accepted, logged risk tied to a named approver and an expiry date, not a standing exception.
ChangeGamer's own publish pipeline runs a different instance of the same default: it fails the entire build outright — not a warning, not a partial publish — the moment two articles declare the same target search query, since a duplicate is treated as an unresolved conflict rather than a detail for an editor to catch later by hand. (See choosing a sandbox for AI agent code execution for the build's parallel fail-closed check on an unresolved resource reference.) Apply the same logic to an unverifiable dependency: block first, argue for a logged exception second, never the reverse.
Where sandboxing and credential scoping fit in
Provenance verification and code sandboxing solve different problems, and clearing the checks above doesn't retire the isolation question. Even a dependency that passes every gate here still runs inside whatever isolation tier the operator chose, because a clean bill of materials and a valid attestation prove what a package declares to contain and that it was built the way its publisher claims — not that a correctly built, legitimately signed piece of code can't still misbehave once it executes. Choosing a sandbox for AI agent code execution covers matching an isolation layer to a task's blast radius; that choice runs in parallel with provenance checks, not something a clean BOM makes unnecessary.
The same logic applies to credentials on the MCP side: a server that hasn't cleared the connect-time gate above hasn't earned the trust to be handed a credential either, whatever shortcut makes skipping the gate tempting. Managing secrets for AI agents covers what a credential should look like once a server has earned that trust — narrowly scoped, short-lived, resolved outside the model's view — and that discipline assumes the server on the other end already cleared this gate first.
A provenance verification checklist
A dependency has cleared supply-chain provenance verification once every item below checks out at the boundary that applies to it:
A bill of materials (CycloneDX or SPDX) is present, parses, and its declared contents match what actually gets installed
A build-provenance attestation (SLSA plus an in-toto/Sigstore signature) accompanies the BOM, not just the inventory alone
A third-party model carries a machine-learning-model component entry or an SPDX AI-profile record, with a modelCard checked where one exists
An MCP server's version is pinned, its checksum or signature verified, its tool-description text diffed against the last-approved snapshot, and its OAuth grant scoped to the minimum tools the current task needs
Any dependency missing a BOM or attestation at any checkpoint is blocked by default, with an override logged as an explicit, named risk acceptance rather than a silent exception
Sandboxing and credential scoping are still applied on top of a passing result, not skipped because the provenance checks already passed
None of these checks is exotic engineering — a version pin, a checksum, a schema validation, and a scoped OAuth grant are ordinary controls a pipeline already has the tooling to run. What makes them a discipline rather than a checklist item nobody owns is running them at all three checkpoints, by default, before the dependency gets a chance to prove the check was unnecessary.
Frequently asked questions
- What is the difference between checking a dependency at install time and checking an MCP server at connect time?
- Package-install time checks a static artifact before it enters a codebase — does a bill of materials exist, is it in a parseable CycloneDX or SPDX format, and do its declared contents match what actually gets pulled — while MCP-server-connect time checks a live, running service an agent is about to grant tool access to, adding a pinned-version check, a checksum or signature verification, an audit of the server's tool-description text, and a minimum-scope OAuth grant that a static package check has no equivalent of.
- What should you do if a third-party AI agent dependency has no SBOM or attestation at all?
- Block the dependency from installing, loading, or connecting by default rather than treating its absence of a bill of materials or a build-provenance attestation as a minor gap to note and move past — if a genuine business need overrides that block, record the override as an explicit, logged risk acceptance tied to a named approver, not a silent exception nobody can find later during an incident review.
- How do you verify a third-party model before an AI agent loads it?
- Check for a CycloneDX bill of materials using the schema's dedicated machine-learning-model component type, or an SPDX 3.0 AI-profile record covering the model's domain, type, and training method, and treat a bundled modelCard field naming the model's training data and intended use as a strong positive signal rather than a required one, since not every publisher populates it yet as of September 2026.
- Does verifying an MCP server's supply-chain provenance replace sandboxing the code it runs?
- No — supply-chain provenance and code sandboxing are complementary controls, not substitutes: a clean bill of materials and a valid attestation prove a server's declared contents weren't tampered with and were built the way its publisher claims, but a dependency that clears every provenance check still needs to run inside an isolation tier matched to its blast radius, because provenance says nothing about what a legitimately built, correctly signed piece of code does once it actually executes.
This guide is free and stays free. The reference corpus behind it — machine-readable contracts, verified primary sources, continuously refreshed — is the paid product: a €5 starter key unlocks every premium reference for one agent via API; a €25 corpus license delivers the full corpus as RAG / fine-tuning data with an explicit AI-use grant; the €150 enterprise license adds commercial redistribution rights.