2026 Comparative Analysis: Software Supply-Chain Provenance for AI Agent Tools — Applied Technology Index

Executive Summary

Software supply-chain provenance is the evidence that connects an executable artifact to the identity, source, workflow, builder, inputs, and policy that produced it. For AI agent systems, the artifact may be an MCP server, command-line tool, container image, Python wheel, npm package, browser extension, sandbox image, or generated tool bundle. Provenance does not decide whether that code is safe. It makes a narrower claim verifiable: this exact digest came from an identified build path under stated conditions.

That distinction is increasingly important because agents discover and execute third-party tools with less human inspection than conventional software installation. A registry name, package owner, repository link, checksum, signature, provenance statement, vulnerability report, and sandbox policy answer different questions. Treating any one of them as a complete trust decision creates a gap between discovery and execution.

The reviewed infrastructure forms a layered system rather than a set of direct substitutes. in-toto supplies a general attestation statement that binds a predicate to immutable subjects by digest. SLSA Build Provenance supplies a standardized predicate for how software was built, including build type, external parameters, resolved dependencies, builder identity, and run details. Sigstore and Cosign sign, bundle, store, and verify artifact evidence using workload or user identity, certificates, transparency logs, keys, or KMS-backed trust. GitHub artifact attestations package these concepts into GitHub Actions and expose verification through GitHub tooling. npm and PyPI integrate provenance and publish attestations into package-registry workflows. OCI 1.1 referrers provide a distribution mechanism for attaching signatures, attestations, and other metadata to container digests. The MCP Registry verifies namespace and package ownership and records package locations, but its documented ownership checks are not equivalent to build provenance.

The central finding is that provenance creates evidence, while verification policy creates protection. GitHub explicitly warns that generating attestations alone provides no security benefit unless consumers verify them. npm similarly states that provenance does not guarantee a package contains no malicious code. A signed artifact can be intentionally harmful; a valid workflow can build compromised source; an approved publisher can be compromised; and a correct checksum can identify the wrong artifact perfectly.

For production agent platforms, the defensible default is to pin every executable tool to a digest, require a verified signer and builder identity, check expected source and workflow claims, retain the attestation bundle with the deployment record, and enforce the decision before installation or execution. That admission decision should then be combined with vulnerability scanning, permission review, sandboxing, egress control, credential brokering, human approval for consequential actions, and runtime audit.

Key Findings

A checksum proves integrity, not origin. It can show that bytes did not change relative to a known digest, but it does not establish who produced them, from which source, or through which builder.
A signature proves control of an accepted signing identity or key, not benign behavior. Verification policy must constrain which identities, issuers, workflows, repositories, builders, and predicate contents are acceptable.
SLSA provenance is content, not a signing or storage system. It describes how an artifact was produced; in-toto binds that predicate to subjects; Sigstore, repository services, and package registries can sign or distribute it.
Artifact identity should be digest-based. in-toto requires subject digests, Cosign recommends signing image digests instead of mutable tags, and OCI registries expose digest-addressed manifests and blobs.
Builder identity is a trust boundary. SLSA states that consumers must accept only specific signer-builder pairs. A valid signature over an unexpected self-hosted runner or workflow should not satisfy policy designed for a vetted hosted builder.
Transparency and private verification are different operating models. GitHub public-repository attestations use the Sigstore Public Good Instance and a public transparency log; GitHub private-repository attestations use a GitHub Sigstore instance without a transparency log.
Package registries are moving verification closer to installation. npm publishes provenance and publish attestations; PyPI exposes attestations through index and Integrity APIs. Registry integration reduces the need to find detached evidence elsewhere.
MCP package ownership is not MCP build provenance. The MCP Registry checks namespace control and package metadata, while MCPB uses a client-validated SHA-256 value. Those checks help prevent impersonation and corruption but do not attest to source, workflow, builder, or dependencies.
OCI referrers solve discoverability, not trust. They associate manifests such as Sigstore bundles with a subject digest. Consumers still need to verify the attached evidence and apply policy.
Agent tool admission should happen before runtime. Letting an agent install a package first and reviewing provenance later reverses the control. Verification belongs in the catalog, gateway, image admission controller, sandbox image builder, or package-resolution step.

Methodology

This analysis reviewed public specifications, repositories, release notes, and official provider documentation available on 4 August 2026. The topic was selected after checking the Applied Technology Index research corpus for duplicate coverage and scanning current technical activity around artifact signing, attestations, package distribution, and MCP packaging. Recent Cosign v3.1.2 release material was used as a current infrastructure signal; substantive claims are grounded in the primary and official sources listed in References.

The comparison applies eight criteria:

Artifact binding: whether evidence identifies immutable output bytes by cryptographic digest rather than only by a mutable name or version.
Producer identity: whether verification can establish a key, workload, OIDC issuer, repository, workflow, publisher, organization, or build service.
Build description: whether evidence records source, workflow, build type, external parameters, dependencies, builder, and execution details.
Evidence format: whether the system uses in-toto statements, SLSA predicates, Sigstore bundles, registry-specific attestations, checksums, or package metadata.
Distribution and discovery: where consumers retrieve the evidence and how it is associated with the artifact.
Policy enforcement: whether tooling can constrain signer identity, issuer, workflow, source repository, predicate type, annotations, or other claims before use.
Agent-tool applicability: how the layer maps to MCP packages, OCI images, npm packages, Python distributions, binaries, and sandbox images.
Residual risk: what remains unproven after successful verification, including malicious source, compromised builders, incomplete dependencies, unsafe permissions, vulnerable code, and runtime misuse.

This is a documented-capability and architecture comparison. No common build was executed across the systems, no artifact was independently reproduced, and no signer, certificate authority, transparency log, registry, CI control plane, or MCP package was penetration-tested. Product names identify documented roles, not an overall security ranking.

Comparative Analysis Table

Layer or system	What it establishes	Artifact binding	Identity and policy surface	Main limitation	Best fit for agent-tool governance
in-toto Statement v1	A typed predicate applies to one or more immutable software subjects	Required subject digest	Predicate type plus external signature or envelope policy	General envelope does not define whether a predicate is sufficient or trustworthy	Common evidence format across packages, images, SBOMs, provenance, scans, and runtime evidence
SLSA Build Provenance	Where, when, and how a build platform produced artifacts	in-toto subject digest	Builder ID, build type, external parameters, dependencies, run details, signer-builder acceptance	Does not sign, store, distribute, or enforce provenance by itself	Standard build evidence for MCP servers, agent binaries, packages, containers, and sandbox images
Sigstore and Cosign	A signer or workload identity made a signed claim about an artifact; optional transparency evidence	Container or blob digest, with attestations bound through in-toto claims	OIDC issuer, certificate identity, GitHub workflow claims, public key, KMS, predicate type, CUE or Rego policy	Valid signature does not prove safe source or safe behavior; public-good services and private trust roots have different operations	Cross-registry signing and policy verification for OCI-hosted and standalone agent artifacts
GitHub artifact attestations	A GitHub Actions identity produced signed build provenance and related claims	Artifact digest in the attestation	Repository, organization, environment, commit, workflow, triggering event, OIDC claims; verification through GitHub CLI and policy tooling	GitHub-centered; public and private attestations have different transparency properties	Agent-tool projects whose canonical releases and CI builds run on GitHub Actions
npm provenance	Public linkage between an npm package, source, build instructions, and authorized publication	Package artifact and registry attestation	Supported cloud CI identity, Sigstore certificate, public transparency ledger, registry publish attestation	Supported hosted CI constraints; provenance does not prove package code is non-malicious	JavaScript and TypeScript MCP servers or agent CLIs distributed through npm
PyPI Trusted Publishing and digital attestations	Short-lived OIDC-based publication plus signed claims for each release distribution	Each wheel or source distribution is bound to a strong digest	Trusted Publisher identity; GitHub Actions, GitLab CI/CD, and Google Cloud documented for attestations; repository expectation during verification	Ecosystem-specific; consumers must actually retrieve and verify the provenance object	Python MCP servers, agent libraries, plugins, and command-line tools distributed through PyPI
OCI Distribution 1.1 referrers	A registry can discover manifests that refer to a subject digest	Subject relationship to a manifest digest	Artifact type and registry access policy; signer policy is external	Storage and discovery mechanism, not a signature verifier or provenance policy	Containers, model-serving images, sandbox templates, bundles, signatures, SBOMs, and attestations
MCP Registry package checks	Publisher controls the namespace and referenced package metadata under documented rules	Package version, OCI tag or digest; MCPB requires `fileSha256`	Namespace authentication, package-ownership marker or OCI annotation, restricted public registries	Ownership markers and hashes do not record builder, source inputs, workflow, or signer identity; MCP Registry is documented as preview	Discovery and anti-impersonation layer that should feed, not replace, enterprise admission policy

Observed Profiles

in-toto: the digest-bound attestation envelope

The in-toto Statement v1 is deliberately small. It contains a statement type, one or more subjects, a predicate type, and a predicate. Every subject must include a digest, and the specification assumes subject artifacts are immutable. The predicate-type URI tells a verifier how to interpret the attached claim.

This separation is useful for agent infrastructure because the same MCP server image can accumulate different evidence without inventing a new container format for every control. One statement may carry SLSA build provenance, another an SBOM, another a vulnerability report, and another a runtime trace. The subject digest is the join key.

The design also exposes a critical limitation. in-toto states that subjects are matched purely by digest regardless of content type. A policy engine must therefore know which artifact it expects, which predicate types it accepts, who may sign each predicate, and which fields are mandatory. Merely finding an in-toto document next to a package is not a pass condition.

The experimental in-toto runtime-trace predicate illustrates how the evidence model can extend beyond compilation. It can represent monitored process, network, and file-access events and can complement provenance claims about hermetic builds or network isolation. The published predicate is version 0.1 and leaves monitor-specific formats open, so it is better treated as a direction for richer evidence than as a universal agent-runtime audit schema.

SLSA Build Provenance: describing the trusted build path

SLSA defines provenance as verifiable information about where, when, and how software was produced. Its recommended provenance predicate uses https://slsa.dev/provenance/v1 and is carried inside an in-toto attestation.

The model distinguishes the build definition from run details. The build definition identifies a build type, external parameters, internal parameters, and resolved dependencies. SLSA treats external parameters as untrusted inputs that must be recorded and verified downstream. Resolved dependencies can capture the exact commit or artifact digest that an input reference resolved to. Run details identify the builder and the specific execution.

For agent tools, this is stronger evidence than a repository URL in a catalog. A catalog entry can claim that an npm package comes from one GitHub repository. SLSA provenance can bind the package digest to a build type, exact source dependency, workflow inputs, and builder identity. That makes substitution and unexpected-build-path decisions machine-readable.

SLSA also states the core policy requirement directly: consumers must accept only specific signer-builder pairs. Signer identity alone is insufficient because one signer can issue attestations for multiple builders, and build modes can have different security properties. SLSA specifically notes that hosted and self-hosted GitHub Actions runners may need distinct builder identities from a consumer’s perspective.

Distribution remains separate. SLSA recommends binding attestations to individual artifacts rather than broad releases, supporting multiple attestations per artifact, publishing evidence with the artifact when possible, and preserving immutability. It identifies source releases, package registries, and third-party transparency logs as complementary distribution paths.

Sigstore and Cosign: identity, transparency, bundles, and enforcement

Cosign is Sigstore’s signing and verification tool for OCI containers and other artifacts. Its documented operating modes include keyless signing with Fulcio and Rekor, hardware and KMS keys, encrypted key pairs, and bring-your-own PKI. The keyless flow uses OIDC identity to obtain a short-lived signing certificate, records evidence in a transparency log, and stores a signature or attestation with the artifact.

Cosign’s verification interface is more important than its signing command for agent-tool admission. Verifiers can require an expected certificate identity and OIDC issuer; inspect GitHub workflow repository, ref, SHA, name, and trigger claims; select an expected predicate type; and apply CUE or Rego policies. The command verifies attestation claims against transparency evidence unless the operator explicitly disables that check.

The policy consequence is concrete. An agent platform should not accept “any valid Cosign signature.” It should accept a specific release workflow in an approved repository, from an approved issuer, for a pinned digest, carrying an expected predicate whose builder and source match policy. Broad regular expressions over signer identity can erase much of the security value.

Cosign bundles package verification material so evidence can survive beyond an online signing session and support offline verification when the trusted root is managed correctly. The Cosign bundle specification also maps Sigstore bundles into OCI 1.1 manifests, allowing multiple attestations to refer to one image. Cosign v3.1.2, published on 17 July 2026, continued the migration toward bundle-oriented workflows and added bundle inspection while maintainers signaled future Cosign v4 cleanup. That release activity makes bundle compatibility and version policy immediate procurement questions rather than theoretical concerns.

GitHub artifact attestations: integrated provenance for Actions builds

GitHub artifact attestations produce cryptographically signed claims containing the repository, organization, environment, commit SHA, triggering event, workflow link, and other OIDC-derived information. GitHub documents that basic artifact attestations provide SLSA v1.0 Build Level 2 and that reusable workflows can help meet Build Level 3 when they provide the required isolation and vetted build instructions.

GitHub uses Sigstore under the service. Public repositories use the Sigstore Public Good Instance, with a copy stored by GitHub and evidence written to a publicly readable immutable transparency log. Private repositories use GitHub’s Sigstore instance, which shares the codebase but does not have a transparency log and federates only with GitHub Actions.

This difference matters for enterprise agent catalogs. Public transparency supports independent monitoring and inclusion verification. Private attestations prioritize confidentiality and GitHub-scoped verification. Buyers should document which trust root, retention, export, offline verification, and disaster-recovery model applies to private artifacts.

GitHub’s strongest warning is operational: generating attestations alone provides no security benefit. Consumers must verify them. For agent tools, verification should be automated in the release intake path, not offered only as a manual command a developer might run after an incident.

npm: provenance and registry publication evidence

npm provenance uses two attestation classes. A provenance attestation links a package to source code and build instructions from the build environment. A publish attestation is generated by the registry when an authorized user publishes the package. npm documents that packages published with provenance are signed through Sigstore public-good services and logged in a public transparency ledger.

The service uses OIDC build identity rather than requiring a durable signing key in the workflow. The current npm documentation names GitHub Actions and GitLab CI/CD cloud-hosted runners as supported provenance environments and states that trusted publishing can generate provenance automatically without the --provenance flag.

For npm-distributed MCP servers, this is a materially stronger signal than the MCP Registry’s mcpName ownership check. The ownership marker says the package publisher asserted a matching MCP server name. npm provenance can link a particular package version to its build environment and source. An internal catalog should require both where available: MCP namespace/package consistency for discovery and verified package provenance for execution.

npm also states the boundary clearly: provenance does not guarantee that a package has no malicious code. It gives consumers a verifiable source and build link that can be audited. Static analysis, dependency review, permission controls, and runtime containment remain separate.

PyPI: Trusted Publishing plus per-file attestations

PyPI Trusted Publishing exchanges a CI-issued OIDC token for a short-lived, project-scoped API token rather than storing a long-lived upload token in CI. PyPI documents that the minted token is valid for 15 minutes. This improves publisher authentication, but publisher authentication alone is not artifact provenance.

PyPI’s digital-attestation implementation, based on PEP 740 and in-toto, adds the artifact evidence layer. Each wheel or source distribution is bound to a strong content digest. PyPI currently accepts SLSA Provenance and PyPI Publish predicates and documents Trusted Publisher identities from GitHub Actions, GitLab CI/CD, and Google Cloud. Attestations are exposed through the simple index, simple JSON, and Integrity API surfaces.

Per-file binding matters because one Python release can contain multiple wheels for different Python versions, operating systems, architectures, or build runs. A release-level badge cannot prove that every wheel followed the same path. Each distribution needs its own digest and evidence.

PyPI’s documented manual verification flow downloads the distribution and corresponding provenance object, checks that the Trusted Publisher in the provenance matches the expected source repository, and cryptographically verifies the file against the attestations. Agent platforms should automate the equivalent check before a Python tool is installed into a reusable sandbox or local agent environment.

OCI referrers: making evidence discoverable beside the artifact

OCI Distribution Specification 1.1 added a referrers mechanism that lets a manifest declare another manifest as its subject. Registries can return a referrers list for a digest, and artifact-type metadata helps clients distinguish signatures, attestations, SBOMs, and other related objects.

This is infrastructure plumbing, but it solves a practical problem. Detached evidence is often lost because release files, transparency services, registries, and deployment systems use different identifiers. OCI subject relationships keep evidence attached to the immutable image digest that an admission system is evaluating.

Cosign’s bundle specification uses this model to store a JSON Sigstore bundle as a registry blob and associate its manifest with the image it describes. Multiple attestations can refer to the same image. An agent-platform intake service can therefore query the image digest, discover its referrers, select the required artifact types, verify signatures and predicates, and write one admission decision.

OCI does not decide which referrers to trust. An attacker may be able to publish an irrelevant or self-signed attestation. Registry authorization, trusted issuer policy, expected predicate types, and content checks remain mandatory.

MCP Registry: useful ownership checks with a provenance gap

The official MCP Registry is documented as preview infrastructure that stores metadata about servers and supports npm, PyPI, NuGet, Cargo, OCI, and MCPB package references. Its official requirements include namespace authentication, package-ownership verification, and restricted public registry locations.

The ownership mechanism varies by ecosystem. npm packages include an mcpName field in package.json; PyPI and NuGet packages expose an mcp-name marker in the README; Cargo uses a visible README marker; OCI images include an io.modelcontextprotocol.server.name annotation. MCPB entries require a fileSha256, which clients validate before installation, although the registry documentation says the registry itself does not validate that hash.

These are useful anti-impersonation and integrity controls. They can show that the publisher controls the namespace or package metadata and that a downloaded MCPB file matches the expected digest. They do not show which source commit, workflow, dependencies, or builder produced the bytes. They also do not prove that the tool descriptions, requested credentials, permissions, or runtime behavior are safe.

The practical architecture is to treat MCP Registry metadata as discovery input. Resolve the referenced package to an immutable digest, retrieve ecosystem-native provenance or OCI attestations, verify them against enterprise policy, scan and review the tool, and only then add the digest to an approved internal catalog.

Deployment and Evaluation Implications

Create an admission manifest for every tool. Record the canonical package identifier, immutable digest, accepted source repository, accepted release workflow, OIDC issuer, signer identity, builder ID, predicate type, minimum evidence, SBOM requirement, vulnerability policy, permissions, destinations, and expiry or review date. A version string alone is not an admission record.

Verify at resolution time and again at deployment time. Package tags and registry metadata can change. Resolve a human-friendly package version to a digest, verify evidence, then ensure the deployment pulls that same digest. Reverification catches policy or trust-root changes before a cached tool is reused.

Keep the verifier outside the agent’s trust boundary. The model-controlled process should not decide whether its own downloaded tool is trustworthy. Run verification in the registry gateway, CI release intake, image admission controller, sandbox template builder, desktop agent host, or another trusted control-plane service.

Constrain identity, not only cryptography. A mathematically valid signature from an unknown repository or broad issuer is not enough. Match the expected certificate identity, issuer, repository, workflow, ref or release condition, builder identity, source digest, and predicate type.

Reject mutable-only references. Tags such as latest, floating package ranges, Git branches, and unpinned workflow actions are convenient but weak admission boundaries. Preserve the human-readable version for operations, but execute the digest that was actually verified.

Distinguish producer authentication from build provenance. OIDC trusted publishing reduces long-lived package-upload secrets. It does not by itself describe build inputs. Require the publish identity and the artifact provenance where the ecosystem supports both.

Do not collapse an SBOM into provenance. An SBOM lists components; provenance describes production; a vulnerability attestation reports a scan result; a signature authenticates a claim; a runtime trace reports observed behavior. Each can refer to the same digest, but each supports a different policy decision.

Preserve evidence with the deployment receipt. Store the artifact digest, attestation bundle or stable retrieval reference, verification timestamp, verifier version, trusted-root version, policy version, matched signer and builder claims, result, exceptions, and deployed environment. This allows incident responders to reconstruct why an agent tool was admitted.

Plan for unavailable transparency and registry services. Decide whether installation fails closed when evidence cannot be retrieved, which bundles support offline verification, how trusted roots are updated, and how private artifacts are verified during provider outages. Cached success without an expiry policy can become permanent unreviewed trust.

Add runtime controls after admission. Provenance cannot constrain what an approved tool does with credentials, network access, files, or user authority. Run tools in least-privilege sandboxes, use deny-by-default egress, broker credentials outside the process, scope authorization, log tool calls, and require human approval for consequential actions.

Test negative cases. A useful conformance suite should reject the right artifact signed by the wrong workflow, the wrong digest signed by the right identity, an expected signer with an unexpected builder, missing dependencies, a mutable tag that moved, an unsupported predicate, expired or revoked trust material, an unattested wheel within an otherwise attested release, and an MCP ownership marker without provenance.

Limitations

This analysis relies on public specifications, repositories, release notes, and official documentation available on 4 August 2026. It does not include private registry controls, enterprise contract terms, source-code review of hosted services, production incident histories, certificate-policy audits, transparency-log monitoring, or hands-on interoperability testing.

The compared layers are intentionally different. in-toto is an attestation framework; SLSA defines build evidence and levels; Sigstore and Cosign provide signing and verification infrastructure; GitHub, npm, and PyPI provide ecosystem integrations; OCI distributes related artifacts; MCP Registry performs discovery and ownership checks. The table compares their roles in one control chain, not interchangeable products.

Provenance completeness depends on the builder and predicate. SLSA describes resolved dependencies as best effort through Build Level 3, and a build platform remains part of the trust base. A compromised or incorrectly configured trusted builder can produce valid but misleading evidence. Reproducible builds and independent rebuilders can add assurance but were not compared here.

Availability and verification behavior vary for public, private, hosted, and air-gapped environments. Public transparency can expose signer information and requires monitoring; private transparency or no-log models change independent-verification properties. Organizations should validate privacy, retention, trusted-root, and outage requirements for their own deployment.

This analysis does not measure adoption, verification latency, storage overhead, false-accept or false-reject rates, registry coverage, or total operational cost. It also does not assess whether any specific MCP server or agent tool is safe. Successful provenance verification is one input to a broader software, identity, authorization, and runtime risk decision.