Two browser tools for the in-toto supply-chain attestation lifecycle: author a layout that names the steps a workflow must follow and the artifact rules each step enforces, then build the DSSE-signed links or attestation statements that a verifier checks a run against. The authoring layer for in-toto has sat mostly vacant since the last dedicated GUI (in-toto/layout-web-tool) archived in 2024; these are a from-scratch composer and builder, not a revival of that project.
For engineers wiring supply-chain provenance into an agent or MCP-tool pipeline, and for anyone who wants to see, hands-on, what an in-toto layout and link actually constrain and what they leave unconstrained.
Author steps, artifact rules (MATCH, CREATE, DELETE, MODIFY, ALLOW, DISALLOW), authorized functionaries, threshold, and expiry, then export a DSSE-signed in-toto layout. Import an existing layout to edit it.
Open tool →Hash materials and products by dragging files in, build a signed link or an attestation-framework statement, or paste a layout and its links to run a strict client-side artifact-rule check.
Open tool →A verified in-toto link proves that a named step ran with the recorded materials as input and produced the recorded products as output, and that whoever holds the private key behind the stated functionary identity signed off on that record. It does not, on its own, prove the command actually executed the way the link's command field claims: a functionary can hand-craft a link that names the right artifacts and hashes without having run anything. The chain of trust an in-toto verification gives you runs from artifact to artifact through the rules in the layout; it does not extend into the step's execution environment unless something else attests to that (a trusted build system, a hardware root of trust, or a §18 compute-integrity proof for the deterministic-kernel case).
A layout's threshold and functionary-key requirements bound who is authorized to sign a given step's link, not whether that person or system executed the step correctly. Reviewing a layout tells you what a verifier will accept; it does not by itself tell you whether the pipeline it describes matches the pipeline that actually runs. Treat layouts and links produced here as a working example of the format, not as a substitute for auditing the pipeline they describe.
An agent invoking a chain of MCP tools is structurally the same shape as a software supply chain: named steps, materials in, products out, and a question of whether the steps that ran match the steps that were supposed to run. in-toto already has the vocabulary for this (layouts, links, artifact rules); the gap has been tooling, not the standard itself. The link builder and layout composer here are a first attempt at closing that gap for MCP-call provenance specifically, alongside the worker-side link recorder that wraps a chain execution automatically.
The link builder's attestation tab produces a standard in-toto attestation statement (subject digests, a predicateType, and a predicate), which is the newer, more general envelope in-toto adopted for arbitrary claims about a subject, not just step-execution links. Both formats DSSE-sign the same way; a link is one specific predicate shape among many an attestation statement can carry.
No. The client-side verifier checks a strict subset of the artifact-rule grammar (MATCH, ALLOW, DISALLOW) and labels anything outside that subset as unsupported rather than silently accepting it. It is useful for a quick sanity check while authoring; a binding verification for anything that matters should run through a reference implementation such as in-toto-golang or the in-toto python package.
This guide and its two tools are original authoring and verification tooling, built independently. A separate, ongoing effort is proposing a new predicate type to the upstream in-toto attestation-framework repository for OCG execution receipts, coordinated with the in-toto maintainers there rather than shipped as a standalone tool. The two are complementary: one is tooling you can use today, the other is a standards proposal working through upstream review.