Wiki · Concept · Last reviewed June 25, 2026

Supply Chain Integrity, Transparency, and Trust (SCITT)

Supply Chain Integrity, Transparency, and Trust (SCITT) is an IETF standards effort for making signed supply-chain statements registerable, receipted, and independently auditable across transparency services.

Category: Concept Updated: June 25, 2026 Tags: AI security, supply chain, SCITT, transparency services, artifact evidence, receipts

Definition

Supply Chain Integrity, Transparency, and Trust, usually shortened to SCITT, is an IETF working group and architecture for transparent digital supply-chain evidence. The IETF charter says the working group defines interoperable building blocks for integrity and accountability in software supply-chain systems, including software and firmware.

SCITT is not an SBOM format, package manager, model card, or artifact signer by itself. Its core idea is narrower: an issuer signs a statement about an artifact, a transparency service registers that signed statement under a registration policy, and a receipt lets relying parties later verify that the statement entered an auditable transparency structure.

For AI systems, SCITT matters because model weights, datasets, evaluation reports, containers, agent tools, and deployment manifests are all artifacts that may need evidence beyond a private spreadsheet or dashboard. The useful question is not only "what artifact is this?" but "who made which statement about it, where was that statement registered, and can the registration be checked later?"

How It Works

The current SCITT architecture draft describes four central objects: Signed Statements, Receipts, Transparent Statements, and Registration Policies. A Signed Statement is a signed claim about an artifact. A Transparency Service evaluates the statement against its Registration Policy and returns a Receipt after successful registration. A Signed Statement plus receipt can become a Transparent Statement.

The architecture defines roles for issuers, transparency services, and relying parties. Relying parties may collect receipts, retrieve transparent statements, verify claims about artifacts, or replay transparent statements to audit the consistency of the transparency service's verifiable data structure. The draft says transparency services must produce COSE Receipts.

The SCITT Reference APIs draft, draft-ietf-scitt-scrapi-11, specifies an HTTP-based REST API for interoperable interaction with a transparency service. The datatracker page lists it as an active Internet-Draft, intended for Proposed Standard status, with latest revision on June 26, 2026.

Agent Context

Agent systems make supply-chain evidence operational. A coding agent can install tools, build containers, modify repositories, generate release notes, and hand outputs to deployment workflows. A browser or desktop agent can depend on helper binaries, local model packages, connectors, and remote tool servers that users rarely inspect.

SCITT gives these workflows a registry-shaped question: before an agent uses an artifact, is there a signed statement about that artifact, from an expected issuer, registered with an expected transparency service, under an inspectable policy? That does not prove the artifact is safe. It does make hidden substitutions and unverifiable approvals easier to challenge.

For AI governance, the important statements may come from different parties: a model builder, dataset curator, red-team vendor, safety evaluator, deployment approver, vulnerability reporter, or regulator. SCITT's architecture allows statements about artifacts without requiring every ecosystem to use the same payload format.

Governance and Safety

SCITT's governance value is evidentiary. It separates the existence of a signed statement, the policy under which it was registered, and the later verification of its receipt. That helps when an organization needs to reconstruct which artifact was approved, scanned, evaluated, certified, or revoked at a particular point in time.

The IETF charter also draws hard boundaries. SCITT does not define payload formats such as bills of materials, does not create a universal centralized registry, and does not prevent authenticated issuers from making false claims. A malicious or mistaken issuer can still sign a bad statement. SCITT helps make the statement durable and auditable; it does not make the statement true.

In an AI stack, SCITT belongs beside SLSA Provenance, Sigstore, AI Bill of Materials, GUAC, in-toto, and vulnerability records. It can carry evidence across those systems rather than replacing them.

Defense Pattern

Source Discipline

Claims about SCITT should identify the draft or final RFC being used, the artifact identifier, issuer, statement payload type, transparency service identity, registration policy, receipt, and verification time. "Registered in SCITT" is too vague for audit unless it names what was registered and under which service policy.

Source notes should also distinguish SCITT Architecture from SCRAPI. The architecture names concepts and workflows; SCRAPI defines a concrete HTTP REST protocol for interacting with a transparency service.

Spiralist Reading

Spiralism reads SCITT as a discipline against unverifiable inheritance. Modern AI systems absorb code, weights, datasets, containers, evaluations, and policy artifacts from many hands. Without receipts, trust becomes a mood.

SCITT does not make the supply chain pure. It makes certain claims harder to erase. The ritual is not belief in the artifact; it is the ability to ask who said what, about which object, under which policy, and whether the record can still answer.

Open Questions

Sources

Return to Wiki