Wiki · Concept · Last reviewed June 25, 2026

in-toto

in-toto is a software supply-chain integrity framework for proving which steps happened, who performed them, and which artifacts moved between them.

Category: Concept Updated: June 25, 2026 Tags: AI security, supply chain, in-toto, attestations, provenance, governance

Definition

in-toto is a framework for protecting software supply-chain integrity. The project describes its purpose as ensuring that each task in a chain is carried out as planned, by authorized actors, and without tampering in transit. CNCF lists in-toto as a graduated project and dates that graduation to February 10, 2025.

The core idea is end-to-end evidence. A project owner defines a signed layout describing expected supply-chain steps and authorized functionaries. Each functionary performs a step and produces signed link metadata about the command, materials, products, and related evidence. The final product can then be checked against the layout and links.

For AI systems, in-toto matters because model weights, adapters, data-processing scripts, benchmark harnesses, containers, plugins, and agent tools are produced through chains of human and automated work. A model or tool is not only a file; it is the result of steps that may need to be proved.

How It Works

Classic in-toto uses layouts and links. The layout names the expected steps, the keys authorized for those steps, expiration data, material and product rules, and optional inspections. A link records what a step did: its name, materials consumed, products produced, byproducts, environment, and signature from the functionary.

The in-toto Attestation Framework generalizes this evidence pattern. Its repository describes a specification for generating verifiable claims about how software is produced. The core layers are an envelope for authentication and serialization, a statement binding the claim to subject artifacts, and a predicate containing type-specific metadata. SLSA provenance is one predicate type built on this model.

The practical value is that supply-chain evidence can become machine-checkable. A verifier can ask whether the expected source checkout, review, build, test, scan, package, and release steps occurred, whether they were signed by expected actors, and whether the artifacts flowed through the pipeline as intended.

Agent Context

Agent systems make provenance harder because they can generate, modify, test, and ship artifacts without a single human looking at every intermediate state. A coding agent may open a pull request, run tests, alter dependencies, produce a container, and hand off a deployment candidate. Without structured evidence, a later reviewer sees the artifact but not the path.

in-toto gives agentic workflows a way to make the path legible. A team can require attestations for steps such as dependency resolution, model download, test execution, red-team evaluation, build, signing, and promotion. Those records do not make the agent trustworthy. They make its claims inspectable.

The limitation is important: an attested pipeline can still produce bad software or an unsafe model. in-toto can show that a test step ran; it cannot prove the test was sufficient. It can show that a model came through an approved chain; it cannot prove the model is appropriate for deployment.

Governance and Safety

A governance-grade in-toto workflow should preserve the layout or policy, subjects, predicate types, signer identities, key or certificate evidence, artifact digests, step names, commands or workflow identifiers, materials, products, verification result, verifier version, exception rationale, and approving owner. For AI releases, those records should connect to an AI Bill of Materials, model card or system card, evaluation record, vulnerability review, and deployment authorization.

The main governance failure is evidence inflation. Teams can generate many attestations and still avoid accountability. The question is not "did we create metadata?" It is whether the metadata answers the risk question: who approved the model source, which data or base artifact entered the chain, what tests ran, what failed, and who accepted the remaining risk?

in-toto belongs beside SLSA Provenance, Sigstore, The Update Framework, GUAC, SBOMs, vulnerability data, sandboxing, and release review. It is the claim structure, not the whole assurance program.

Defense Pattern

Source Discipline

Claims about in-toto should cite the official project website, the in-toto repository, the CNCF project page, the in-toto Attestation Framework repository, or the published research paper. Source notes should distinguish classic layout/link verification from the newer attestation framework, because they are related but not identical layers.

A claim that an artifact has in-toto evidence should name the subject digest, predicate type, signer, verification policy, and review date. Otherwise "has attestations" can become a vague label rather than an audit-ready fact.

Spiralist Reading

Spiralism reads in-toto as an answer to the old problem of invisible labor. The artifact arrives cleanly named, but its making may involve maintainers, bots, contractors, data workers, build services, test systems, and release gates that disappear behind the download button.

in-toto does not sanctify the artifact. It makes the chain speak. The useful ritual is not the possession of a signed file, but the demand that the steps, actors, materials, and products remain inspectable when trust is requested.

Open Questions

Sources

Return to Wiki