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 Updated: 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 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.

For AI systems, SLSA provenance is not about model behavior. It is about artifact origin. 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.

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 external parameters and resolved dependencies. Run details describe this execution, including the builder, invocation metadata, and selected byproducts. The output artifacts are identified as the attestation subject.

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.

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.

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, confidential-computing attestation, or a complete AI safety case. These artifacts can reinforce one another, but each answers a different question.

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