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 claims about artifacts registerable, receipted, and independently auditable across transparency services.

Category: Concept Published: June 25, 2026 Modified: June 25, 2026 Last reviewed: 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 frames the work as 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, artifact signer, or universal registry. 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 a specific auditable transparency structure.

For AI systems, SCITT matters because model weights, datasets, evaluation reports, containers, agent tools, deployment manifests, and approval records are all artifacts whose governance often depends on evidence created by different parties. The useful question is not only "what artifact is this?" but "who made which statement about it, under which registration policy, at which transparency service, and can that registration still be verified?"

Current Status

As of the June 2026 review window, the IETF datatracker listed the SCITT working group as active. The architecture document, draft-ietf-scitt-architecture-22, was an active Internet-Draft intended for Proposed Standard status and was in the RFC Editor queue, so implementers should identify the exact draft or later RFC they rely on.

The companion SCITT Reference APIs work, draft-ietf-scitt-scrapi-11, remained an active Internet-Draft intended for Proposed Standard status. It specifies the HTTP resources, request and response messages, and error handling needed for interoperable interaction with a SCITT transparency service.

A separate CCF Profile for COSE Receipts draft was also active in the SCITT working group. That draft profiles verifiable data-structure evidence for append-only logs produced by the Confidential Consortium Framework. Treat these documents as work in progress until the relevant RFCs are published and named.

How It Works

The 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 authenticates the issuer, evaluates the statement against the current Registration Policy, adds accepted statements to a verifiable data structure, and returns a Receipt. A Signed Statement plus one or more receipts can become a Transparent Statement.

The architecture defines roles for issuers, transparency services, relying parties, clients, auditors, and adjacent services. Relying parties may collect receipts, retrieve transparent statements, verify artifact-bound claims, or replay transparent statements to audit consistency. The draft requires transparency services to produce COSE Receipts, and it makes the service's registration policy and trust anchors part of the auditable record.

The security model is evidence-oriented. SCITT can show that an authenticated issuer made a signed statement and that the statement was registered in a transparency service. It does not prove that the payload is accurate, that the artifact is safe, or that the issuer was honest or uncompromised.

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 exact 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, stale approvals, and unverifiable attestations 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, so SBOMs, VEX records, provenance attestations, evaluation summaries, and policy approvals can remain separate payloads while sharing a common registration and receipt discipline.

Governance and Safety

SCITT's governance value is evidentiary. It separates the existence of a signed statement, the transparency service that registered it, the policy under which it was accepted, and the later verification of its receipt. That helps when an organization needs to reconstruct which artifact was approved, scanned, evaluated, certified, superseded, 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, Vulnerability Exploitability eXchange, GUAC, in-toto, AI System Inventory, and AI Audit Trails. It can carry evidence across those systems rather than replacing them.

Safety programs should also account for privacy and metadata leakage. The architecture draft notes that signed statements can contain private, confidential, or personally identifiable information, and that transparency-service metadata can reveal relationships such as build, signing, and upload order. Sensitive AI records may need payload minimization, detached payloads, access controls, and separate adjacent services rather than public disclosure of every detail.

Minimum Evidence Record

A useful SCITT-backed AI governance record should identify enough context for an independent verifier to repeat the trust decision later. At minimum, record:

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, receipt profile, 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 distinguish SCITT Architecture from SCRAPI and from receipt profiles. The architecture names concepts and workflows; SCRAPI defines a concrete HTTP REST protocol for interacting with a transparency service; receipt-profile drafts define how particular verifiable data structures express receipt evidence.

Because several SCITT documents were still Internet-Drafts during the June 2026 review window, source citations should include the draft number or later RFC number. Do not cite an Internet-Draft as if it were a final standard.

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