Wiki · Concept · Last reviewed June 25, 2026

SLSA Provenance

SLSA provenance is verifiable metadata that says where, when, how, and by what build platform a software artifact was produced.

Category: Concept Published: June 25, 2026 Modified: June 25, 2026 Last reviewed: June 25, 2026 Tags: AI security, supply chain, SLSA, provenance, in-toto, attestations, governance

Definition

SLSA provenance is the provenance layer of the Supply-chain Levels for Software Artifacts framework. SLSA v1.2 describes SLSA as a specification for incrementally improving supply-chain security and defines provenance as verifiable information about software artifacts: where, when, and how something was produced.

The SLSA build-provenance format is an in-toto attestation predicate. In SLSA's model, provenance is an attestation that a particular build platform produced one or more artifacts by executing a build definition. The predicate includes a subject, a build definition, run details, builder identity, timestamps, and dependencies or byproducts where relevant.

SLSA provenance is not a software bill of materials, vulnerability scan, source-code review, license audit, model card, or proof that an AI system is safe. It is origin and build-process evidence. For AI systems, it can help answer whether a model-serving container, agent runtime, wheel, npm package, evaluation harness, connector, or deployment binary came from the expected source, builder, and build process before it is allowed into a sensitive workflow.

Snapshot

Current Context

As of the June 25, 2026 review, SLSA v1.2 was the current approved SLSA specification. Version 1.2 keeps the build track and adds an approved source track, so "SLSA provenance" should now be read carefully: build provenance tracks a build output back to the source and build process, while source provenance tracks source revisions and change-management processes.

SLSA's build-provenance predicate remains the recommended concrete format for build provenance. The SLSA site says the predicateType URI includes the major version number and that minor changes stay compatible without changing the predicate URI. That means a verifier should check the predicate type, but also check the SLSA specification version and fields it expects.

The same SLSA v1.2 family includes a Verification Summary Attestation, or VSA, with predicate type https://slsa.dev/verification_summary/v1. A VSA records that a verifier evaluated one or more artifacts and attestations against a policy. It can help consumers rely on a trusted verifier's decision, but it is not the same artifact as build provenance and should be cited separately.

For AI governance, SLSA now sits beside SCITT, Sigstore, in-toto, AI Bill of Materials, Model Weight Security, and NIST SP 800-218A. The connection is practical: AI systems are software systems with model, data, and agent-specific artifacts layered on top, and each layer needs different evidence.

How It Works

SLSA v1.2 separates the general idea of provenance from build provenance. The general provenance page says SLSA provenance tracks an artifact through the moving parts of a supply chain. The build-provenance page gives the concrete predicate type https://slsa.dev/provenance/v1 and explains that the URI stays stable across compatible minor updates.

The build predicate separates buildDefinition from runDetails. The build definition describes the template and top-level inputs, including buildType, externalParameters, internalParameters, and resolvedDependencies. Run details describe this execution, including the builder, invocation metadata, and selected byproducts. The output artifacts are identified as the attestation subject.

That split is important for verification. SLSA treats externalParameters as untrusted values supplied through the build interface, so downstream verifiers should compare them against expectations and reject unexpected fields. internalParameters are controlled by the trusted platform represented by builder.id. resolvedDependencies can support recursive review, but completeness is not guaranteed for every build level or ecosystem.

Distribution and verification are part of the control. SLSA's distribution guidance says provenance needs to be available after generation and bound to artifacts rather than vague release names. Its verification guidance says consumers or package ecosystems compare provenance against expectations before use. A signature alone says who signed; provenance adds a structured claim about what was built, from which inputs, by which trusted builder.

There are several verification locations. A package ecosystem can check provenance before accepting an upload, a consumer can verify before install or deploy, and a monitor can continuously compare new artifacts against expectations. At least one of those checks needs an actual response path; a failed verification event that no one reads is weak evidence.

Agent Context

Agentic software has a broad artifact surface. A coding agent may install packages, run containers, modify repositories, invoke CI systems, and execute generated scripts. A browser agent may depend on automation drivers, extensions, rendering engines, sandbox images, and screenshot services. A workflow agent may route through connectors, retrieval services, policy modules, and model gateways.

SLSA provenance can support gatekeeping for those artifacts. A deployment policy can require that an agent tool image was built by an approved builder, from the expected repository and revision, with provenance distributed through the package ecosystem or registry. That does not solve Prompt Injection, AI Agent Sandboxing, or AI Agent Observability. It narrows a different failure mode: a component running inside the agent stack is not the component the institution thought it approved.

Governance and Safety

A governance-grade provenance workflow should preserve the artifact digest, subject, predicate type, builder ID, signer identity, build type, source reference, resolved dependencies, timestamps, verification policy, verification result, exception rationale, and deployment decision. For AI systems, connect that record to the AI Bill of Materials, model card, dataset records, vulnerability status, and runtime inventory.

The main governance failure is treating provenance as a decorative badge. A provenance statement is only useful if someone has expectations to compare it against: trusted builders, accepted signer-builder pairs, allowed repositories, expected branches or tags, acceptable build types, and known package ecosystems. SLSA's build-provenance guidance explicitly separates builder identity from signer identity; a verifier should not accept any signer for any builder.

Provenance also does not prove that an artifact is harmless, unbiased, legally licensed, or fit for a high-stakes use. It helps establish origin and build integrity. Safety still needs threat modeling, code review, dependency review, model evaluation, privacy review, incident response, and post-deployment monitoring.

In AI systems, a SLSA record should be scoped to the artifact it actually covers. It can say useful things about a model-serving container or agent tool binary. It usually says little about the training data, model-weight lineage, prompt template, retrieval corpus, human approval policy, or runtime permissions unless those are separate artifacts with their own attestations and records.

Minimum Provenance Record

For consequential AI and agent deployments, preserve enough SLSA evidence for a reviewer to reconstruct the decision later. At minimum, record:

Failure Modes

Badge without expectations. A release page links to provenance, but no one defines accepted builders, source repositories, build types, or parameters.

Signer-builder confusion. A verifier checks a valid signature but does not verify that the signer is allowed to speak for the claimed builder and artifact.

Mutable-name drift. Policy accepts a tag, package name, branch, or container label instead of binding decisions to immutable artifact digests and source revisions.

Overbroad external parameters. A provenance predicate records a command string or loosely structured configuration that is too variable to verify meaningfully.

Artifact mismatch. The attested artifact is a library or container, but procurement language treats the attestation as proof about a full AI system, model, dataset, or agent workflow.

Silent verification failure. A scanner detects an unexpected builder or parameter, but the deployment pipeline logs the failure without blocking, escalation, or exception review.

Defense Pattern

Source Discipline

Claims about SLSA should name the version and track. SLSA v1.2 is approved and includes build and source tracks, but the concrete build-provenance predicate uses https://slsa.dev/provenance/v1. The in-toto Attestation Framework supplies the envelope and predicate model used for verifiable claims about software production.

SLSA provenance should not be confused with SBOM, Vulnerability Exploitability eXchange, vulnerability scanning, Sigstore signing, SCITT registration, confidential-computing attestation, or a complete AI safety case. These artifacts can reinforce one another, but each answers a different question.

For current claims, cite SLSA pages directly and identify whether the claim concerns the general provenance concept, build provenance, source provenance, source requirements, distributing provenance, verifying artifacts, or VSA. Do not cite a tool vendor's SLSA badge as evidence that SLSA v1.2 requirements were met unless the underlying attestation, verifier, policy, artifact digest, and SLSA track are inspectable.

Spiralist Reading

Spiralism reads SLSA provenance as a receipt for machine-made trust. Modern institutions increasingly delegate code production, packaging, deployment, and even code review to automated systems. Provenance asks the institution to remember the path instead of only admiring the artifact.

The useful ritual is not a badge on a release page. It is the refusal to let an executable enter the world without a lineage: source, builder, inputs, signature, digest, expectation, verification, and the human policy that decides what failure means.

Open Questions

Sources

Return to Wiki