What Is SCITT Agent Package Provenance? The Beginner's Guide to Transparent Supply-Chain Statements for AI Agent Packages
CodexFuse Team · 2026-11-05T21:01:11.370Z · 27 min read min read
What Is SCITT Agent Package Provenance? The Beginner's Guide to Transparent Supply-Chain Statements for AI Agent Packages
What Is SCITT Agent Package Provenance?
What is SCITT agent package provenance? It is a new IETF Internet-Draft that applies the SCITT architecture to portable AI agent packages, so that every claim about a package — who wrote it, how it was built, whether it passed a security scan, whether an enterprise approved it — is a signed statement tied to one immutable package digest. The draft is called SCITT Profile for Portable AI Agent Package Provenance, it carries the name draft-raskar-scitt-agent-provenance-00, and it was posted on 2 November 2026 by Ramesh Raskar of the MIT Media Lab.
The problem it attacks is easy to picture. An AI agent package can be authored by one party, built by a second, transformed by a third, scanned by a fourth, approved by a fifth, and finally run by a sixth.
Each of those parties makes a different claim about the same package, and a single signature on the finished package cannot express that whole history or say who is accountable for which claim. SCITT agent package provenance is the proposal for recording each claim separately, in signed form, against the exact bytes of the package it describes.
Each claim is bound to the package by a digest, which is a short fixed-length fingerprint of the package content. A SHA-256 hash generator produces exactly the kind of fingerprint a package digest is: change one byte of the input and the fingerprint changes completely.
The runtime that executes the package often lives on rented infrastructure — VPS hosting is the common home for agent runtimes — but this profile says nothing about the server. It is about the package itself, and about proving what happened to it before it ever runs.
Three facts about the document set the frame for everything below. It is an Informational Internet-Draft, which means it is work in progress and not a standard, and it expires on 6 May 2027.
It is revision -00, the first version, posted only four days before this article was written. Its lifespan runs 185 days from posting to expiry, leaving 181 days from today. And it is short: 13 pages and 16 numbered sections, with 1,213 lines of plain text.
The scitt agent provenance draft matters because portable agent packages are becoming a real distribution unit. A package can contain prompts, role instructions, workflow definitions, compiled components, tool schemas, policy references, model-interface requirements, and dependencies. Because it can influence consequential behaviour even when the model, the tools, and the runtime are supplied separately by the receiving environment, the receiving side needs a way to check the package's history before trusting it.
Why Portable Agent Packages Need Signed Provenance
Software supply chains learned this lesson years ago. A build attestation, a bill of materials, and a signed statement in a transparency log tell a deployer what was built, by whom, and from what source.
Agent packages need the same treatment, with one extra difficulty: the artifact is not just code. It can carry prompts and workflow graphs that steer behaviour, tool schemas that decide what the agent may call, and policy references that constrain it.
The draft names the cast explicitly. The author, package producer, transformer, security assessor, publisher, enterprise approver, and runtime operator can all be different entities.
A single signature on the final package cannot, by itself, express the full history or distinguish which entity is accountable for which claim. That sentence is the whole case for the profile: many parties, many claims, one artifact.
| Actor | What they do | What they can claim |
|---|---|---|
| Agent author | Writes the agent definition | Authorship and source |
| Package producer | Turns the definition into a distributable package | Build or transformation |
| Enterprise transformer | Hardens policy, changes dependencies, repackages | Build or transformation |
| Security assessor | Scans or red-teams the package | Security assessment |
| Publisher | Releases the package at distribution endpoints | Publication and release |
| Enterprise approver | Approves a package for a defined scope | Approval |
| Runtime operator | Receives and executes the package | Verifies provenance before execution |
Without signed provenance, the runtime operator has two bad options. It can trust the package on the strength of a name, a version label, or a download URL — all of which can point at different bytes tomorrow.
Or it can refuse packages it cannot verify, which blocks the portability the format exists to provide. Signed statements tied to an immutable digest are the draft's middle path: trust the history, but check it first.
The portable agent package supply chain is therefore the subject of this article, not the agent itself. The draft does not say how to write a good agent, how to run one safely, or how to authorise its actions. It says how to record, transparently, what happened to the package on its way to the runtime.
What SCITT Is, in One Paragraph
SCITT stands for Supply Chain Integrity, Transparency, and Trust. It is defined by RFC 9943, An Architecture for Trustworthy and Transparent Digital Supply Chains, a Standards Track RFC published in June 2026 by Birkholz, Delignat-Lavaud, Fournet, Deshpande, and Lasker. In the RFC's own words, its goal is to enhance auditability and accountability for single-issuer signed content — statements — that are about supply-chain commodities, called artifacts.
The architecture has three moves. An Issuer signs a statement about an Artifact.
The signed statement is registered with a Transparency Service, which records it in an append-only, linear, irrevocable ledger and issues a receipt. RFC 9943 describes registration as akin to a notarization procedure: once the signed statement is registered, the Transparency Service issues a receipt that anyone can later check.
SCITT is deliberately content-agnostic. Instead of understanding every statement type, it standardises authenticity, visibility, and scalable accessibility, using CBOR and COSE message structures with COSE receipts defined by RFC 9942.
Its examples come from software supply chains, but the specification states it applies to other supply chains too. That generality is exactly what makes an application profile possible: the same machinery, pointed at a new kind of artifact.
A SCITT application profile answers three domain questions — what is the artifact, how is it bound to a statement, and what kinds of statements can be made about it — while reusing SCITT registration, receipts, and verification unchanged. This draft is such a profile for portable AI agent packages.
It specifies the artifact binding requirements and the statement classes needed for interoperable provenance reasoning, but it does not define a new payload schema. Statement payloads may use existing supply-chain formats or future formats suitable for the claim being made.
What Is a Portable AI Agent Package?
The draft defines a portable agent package in section 2: a distributable artifact containing or referencing an AI agent definition together with metadata, resources, dependencies, or execution requirements needed by an independent runtime. The word that carries the weight is independent. The package is built by one party and executed by another, in an environment the builder does not control.
Inside a package there can be prompts, role instructions, workflow definitions, compiled components, tool schemas, policy references, model-interface requirements, and dependencies. That mixture is why provenance matters more here than for a plain code library. A prompt or a workflow graph can change what an agent does just as surely as code can, and a tool schema can change what it is allowed to touch.
SCITT portable ai agent packages follow a lifecycle the draft maps step by step. The chain below is the draft's own illustrative example, paraphrased. It shows how one package can pass through many hands before any runtime sees it.
| Step | Actor | What happens | What is recorded |
|---|---|---|---|
| 1 | Agent author | Creates an agent definition | Source revision |
| 2 | Package producer | Turns the definition into Package A | Package A, digest A, security assessment, profile-conformance claim |
| 3 | Enterprise transformer | Transforms Package A into Package B | Package B, digest B |
| 4 | Enterprise approver and publisher | Approves and publishes Package B | Enterprise approval, publication statement |
| 5 | Runtime | Receives Package B | Verifies provenance before execution |
Transformation is a first-class event in this model, not an afterthought. A transformation produces a new package artifact from one or more prior artifacts — for example compilation, policy hardening, dependency vendoring, repackaging, or enterprise customisation.
Because the bytes change, the digest changes, and the new package is a distinct artifact with its own history. Statements can relate the two artifacts by identifying the input digest and the output digest of the transformation.
That distinction is what makes provenance chains possible. A relying party can trace Package B back to Package A, and from there to the author statement about the source revision. Without digest-bound statements, that trace would rest on version labels and trust, which is exactly the gap the profile closes.
The Package Digest: The One Binding That Cannot Change
The package digest is the heart of the profile. The draft defines it as a cryptographic digest over the immutable package representation, or over a canonical manifest that commits to the package content. It calls the digest the primary artifact binding used by this profile, and it states the SCITT artifact plainly: the SCITT Artifact is a specific immutable portable agent package, identified by a Package Digest.
Names and URLs fail this job by design. A statement about a mutable package name or distribution URL alone is insufficient for artifact-specific provenance, the draft says, because the content reachable at that name or URL can change.
A version label such as 1.2.0 can be re-pointed at new bytes. A download URL can serve a different file tomorrow. A digest cannot be re-pointed: it is computed from the bytes themselves.
| Identifier | Stable across versions? | Binds the exact bytes? | Good enough for provenance? |
|---|---|---|---|
| Logical Package Identifier | Yes — it names a product line or package family | No — it is not sufficient by itself to identify immutable content | No, on its own |
| Distribution URL | No — the content behind it can change | No | No |
| Version label | No — it can be re-pointed at new bytes | No | No |
| Package Digest | Yes — it is computed from the bytes | Yes — it is the primary artifact binding | Yes |
The rule for statements follows directly. A package provenance statement needs to identify the exact package content it applies to, so it needs an artifact identifier that includes, or unambiguously resolves to, a cryptographic package digest. A logical identifier can additionally identify a product line or package family, but a statement that affects execution policy should not rely on a mutable name without also binding the immutable package content.
The consequence of any change is absolute. If the package bytes are changed after approval, the draft states, the digest changes and the prior approval no longer binds the new artifact.
There is no grace period and no near-enough: a different digest is a different artifact, and old approvals stop applying to it. That strictness is the feature, not a bug. It is what lets a runtime treat an approval as a statement about exact bytes rather than about a name.
One gap is worth stating plainly. The draft does not name a hash algorithm and does not define package canonicalization or archive hashing rules.
What the digest commits to must be defined by the package format or an adjacent specification. The profile tells you to bind claims to a digest; it leaves the choice of digest function to someone else.
The Seven Statement Classes, Explained
Section 6 of the draft defines semantic classes of statements useful for agent package provenance. It does not define a payload encoding for them.
Each statement needs to bind the relevant package digest and identify the Issuer according to SCITT requirements. The seven numbered subsections cover nine named kinds of statement: the abstract names eight, and section 6.7 adds revocation as a third lifecycle ending alongside supersession and withdrawal.
| Section | Statement class | Who issues it | What it says |
|---|---|---|---|
| 6.1 | Authorship and source | Agent author or source repository operator | This package was authored from a particular source revision, repository state, or agent definition |
| 6.2 | Build or transformation | Package producer or transformer | This output digest was produced from these input digests by a named build or transformation process |
| 6.3 | Execution-profile conformance | Conformance service | This digest was tested against a named execution profile, with this result |
| 6.4 | Security assessment | Scanner, evaluator, or red-team service | This digest was evaluated using an identified procedure, with a referenced report |
| 6.5 | Publication and release | Publisher or package owner | This digest is an official release, available from these endpoints, or the current release for this package identifier |
| 6.6 | Approval | Enterprise, marketplace, administrator, or policy authority | This digest is approved for a defined scope, policy, environment, validity interval, or deployment class |
| 6.7 | Supersession, withdrawal, and revocation | Authorised issuer | This digest has been superseded by another digest, withdrawn from distribution, or is no longer approved for a stated purpose |
Different supply-chain actors can be Issuers for different statements. The draft lists the agent author, package producer, source repository operator, security scanner, execution-profile test service, publisher, enterprise administrator, and package owner.
A relying party decides which issuers are authoritative for a particular statement class, under its own local policy. No single issuer is authoritative for everything.
Three of the classes carry explicit limits in the draft itself. A conformance statement reports that a package was tested against a named execution profile, but it does not guarantee identical behaviour across different models or runtimes.
A security assessment statement references a report, but SCITT provides transparency and accountability for the statement — it does not establish that the assessment is complete or correct. And an approval statement approves a digest for a defined scope without granting runtime capabilities by itself.
The classes chain together into a provenance graph. A useful provenance graph, the draft says, consists of statements that bind input artifact digests to output artifact digests. A relying party can traverse it to answer five questions: which source or prior package produced this artifact; which entity performed each transformation; which assessments apply to the exact artifact being executed; whether an approved artifact was later modified or repackaged; and whether a later statement superseded or withdrew an earlier release.
The draft is careful about what the graph proves. SCITT transparency makes the statements auditable, it says, but it does not define the semantics of every transformation or prove that an issuer described a transformation truthfully.
The graph shows who claimed what, in signed form. It does not certify that the claims are true.
How a Package Moves From Author to Runtime
The draft's worked example in section 8 turns the abstract classes into a concrete chain. It starts with a source revision and ends with a runtime checking provenance before execution. Every step produces a statement, and every statement binds a digest.
- Author writes the definition. An agent author creates an agent definition from a source revision and issues an authorship statement binding that revision to the work.
- Producer builds Package A. A package producer turns the definition into Package A, identified by digest A, and attaches a security assessment and a profile-conformance claim to that digest.
- Transformer builds Package B. An enterprise transformer converts Package A into Package B — in the draft's example, removing one dependency and constraining the tool set — and issues a transformation statement binding digest A to digest B.
- Enterprise approves and publishes. The enterprise issues an approval statement for digest B and a publication statement naming the distribution endpoints where Package B is the current release.
- Runtime verifies before execution. The runtime receives Package B and verifies the approval, its SCITT receipt, and the transformation statement, optionally tracing back to digest A and the author statement, before deciding whether to run it.
Notice what the runtime checks: statements, not vibes. It verifies the approval statement and its receipt, then the transformation statement that links digest B to digest A, then optionally the author statement behind digest A.
Each check is a verification of a signed statement about a specific digest. If any link in that chain is missing or fails, the runtime's local policy decides what happens next — the profile does not dictate the decision.
The example also shows why supersession and withdrawal matter. Suppose a vulnerability is found in Package B after publication.
An authorised issuer can state that digest B has been superseded by a new digest, or withdrawn from distribution, or is no longer approved for a stated purpose. A relying party needs local policy for deciding how those lifecycle statements affect previously issued approvals and cached artifacts. The profile supplies the signal; the policy decides the response.
What a Relying Party Checks Before Running a Package
Section 9 of the draft sets out the relying party's job as seven conceptual steps. It is the closest thing the profile has to a checklist, and it is worth reading as one. The steps run in order, from obtaining the digest to making the admission decision.
- Compute or securely obtain the package digest. The check starts with the bytes, not the name. The relying party needs the digest of the exact package it is about to run.
- Obtain the relevant package provenance statements. It gathers the signed statements about that digest — authorship, build, assessment, approval, and any lifecycle statements.
- Verify each signed statement. Each statement is verified under RFC 9943, including the issuer's identity, against the relying party's own policy about which issuers it trusts for which classes.
- Verify the receipt where transparency is required. Where the deployment requires transparency, the SCITT receipt is verified under RFC 9942, confirming the statement was registered with a Transparency Service.
- Check the digest binding. Each statement must bind the exact digest, or an explicitly related artifact in a verified transformation chain. A statement about digest A says nothing about digest B.
- Evaluate freshness, supersession, withdrawal, and issuer authority. The relying party checks whether a later statement superseded or withdrew the release, whether the approval is still within its validity interval, and whether the issuer was authorised for that class.
- Use provenance as one input to the decision. The verified history feeds the admission or audit decision. It does not make the decision on its own.
Two sentences in section 9 deserve emphasis. First, the exact APIs for discovering and retrieving statements are outside this document — the profile says what to check, not where to fetch it from.
Second, successful verification does not itself authorise execution or grant access to models, tools, credentials, data, storage, or network resources. Verification is evidence for a decision. Authorisation is a separate act, governed by separate policy.
That separation is the profile's most important design choice. Provenance answers the question "what is the history of this package, and who vouches for each part of it?" It does not answer "may this package run here, with these tools, on this data?" A runtime that confuses the two questions would let a well-documented package do anything — which is exactly the failure the profile is built to prevent.
Package Provenance vs Session and Action Receipts: Two Layers, Not Rivals
The draft draws a deliberate before-and-after line in section 10, and it is the key to placing this profile in the wider SCITT agent family. This profile concerns the software-supply-chain history of an agent package.
It is intentionally distinct from records of what an agent did after execution began. One layer covers the package before it runs; the other covers the agent after it starts.
| Layer | What it covers | Example records | Profile |
|---|---|---|---|
| Package provenance | Author, build, transform, scan, assess, approve, publish, supersede, withdraw | Authorship, build, assessment, approval statements | This draft (Raskar, -00, 2 Nov 2026) |
| Session provenance | Session start, governed tool dispatch, state transitions, termination, settlement | Causal Provenance Receipt bundles | Session receipts draft (Bailey, -00, 25 Oct 2026) |
| Action records | Individual agent actions and their evidence | Agent Interaction Records | Execution profile draft (Emirdag and Feichtinger, -01, 12 Oct 2026) |
A deployment can use both layers. The draft gives the example itself: an execution receipt can identify the exact package digest whose pre-execution provenance was established using this profile. The package layer answers "which package is this, and who vouches for it?" The session and action layers answer "what did this package do once it ran?" Neither replaces the other, and the profile complements session and action receipt profiles rather than replacing them.
The siblings are worth knowing by name. What Tap-to-Record Agent Evidence is covers the per-interaction evidence layer, where an NFC tap anchors the evidence from every layer of an in-person agent interaction.
The agent accounting siblings cover the measurement layer: What Agent Run Metrics is defines the JSON format for counting what an agent run costs, and What IoA Usage Accounting is defines auditable billing records across agent domains. Agent package provenance SCITT work sits underneath all of them: it establishes which package was running before any of those records can be trusted to describe it.
The two sibling drafts named in this draft's references show how fast the family is growing. The execution profile, draft-emirdag-scitt-ai-agent-execution-01, was posted on 12 October 2026 — 21 days before this draft — and is already at revision -01.
It defines the Agent Interaction Record as the signed-statement payload for material agent actions, and it maps its compliance story to the EU AI Act, DORA, NIST AI RMF, and other frameworks. The session receipts draft, draft-bailey-scitt-agent-session-receipt-00, was posted on 25 October 2026 — eight days before this draft — and defines Causal Provenance Receipt bundles with a head commitment that detects hash-chain truncation and whole-store rollback. A related decision-provenance draft, draft-lemonnier-scitt-decision-provenance-01, was also posted on 2 November 2026, binding software releases and agent actions to the decisions behind them.
One caution about the siblings: the session receipts draft names reference implementations, but those implementations belong to that draft's receipt format, not to this package-provenance profile. This draft names no implementation at all. Do not carry an implementation claim from one draft to another.
What This Profile Deliberately Does Not Define
The draft's non-goals section is unusually explicit, and it is the fastest way to understand the profile's boundaries. It defines no new statement payload format, no package format, no execution protocol, no runtime authorization model, and no per-action receipt. Those five exclusions are in the abstract itself, and the draft repeats them in its non-goals section.
| Not defined | What that means in practice |
|---|---|
| New statement payload format | Statement classes are semantic only; payloads may use existing supply-chain formats or future formats |
| Portable-agent package format | How a package is encoded is left to the package format or an adjacent specification |
| Agent execution protocol | How an agent is authored, how an execution profile works, and how actions are recorded are all out of scope |
| Runtime authorization model | How a runtime grants access to models, tools, credentials, data, storage, or network is not defined here |
| Per-action execution receipt | Records of individual agent actions belong to the execution and session profiles, not this one |
| Universal registry for agent packages | There is no single registry the profile creates or requires |
| Truth guarantee | A signed statement is not established as true by being signed or transparent |
| SBOM, manifest, or report payload formats | Agent SBOMs, capability manifests, security-assessment reports, and policy documents keep their own formats |
| Package canonicalization and archive hashing rules | No hash algorithm is named and no canonicalization rules are defined |
| Statement discovery and retrieval APIs | How a relying party finds the statements about a given digest is outside the document |
| IANA actions | No new SCITT media type, COSE header parameter, statement payload format, or package media type is defined |
The pattern is consistent: the profile defines the mapping and the statement classes, and leaves the formats, the protocols, and the plumbing to other documents. That restraint is deliberate. A profile that tried to define a package format, a payload schema, a discovery API, and an authorisation model would be a platform, not a profile — and it would take years to standardise instead of months to discuss.
For a reader, the practical consequence is simple. You cannot implement this draft on its own and have a working system.
You can implement it alongside RFC 9943, an existing package format, an existing statement payload format, and a discovery mechanism of your own choosing. The draft is a mapping layer, and it is honest about that.
The Limits You Should Not Miss
The strongest sentence in the draft is in its security considerations, and it should be read before anything else in this section. A valid signed statement proves that the statement was signed by a corresponding issuer identity; it does not prove the statement is true.
A malicious or compromised issuer can make false claims. Transparency makes false claims auditable after the fact. It does not prevent them.
Incomplete provenance is the second limit, and it is subtler. A distributor can omit an unfavourable assessment while showing valid positive statements.
The draft flags this directly: nothing in the profile guarantees that a relying party sees the full history of a package. The statements you can see may be genuine, signed, and registered — and still incomplete. Completeness policy is left to the relying party, which must decide how much missing history it will tolerate.
The third limit is the missing plumbing. No hash algorithm is named, no canonicalization rules are defined, and no discovery API is specified.
Two implementations that choose different digest functions cannot compare digests, and a relying party with no way to find statements cannot verify anything. These are not oversights — the draft marks them as out of scope — but they mean the profile is not yet implementable as a complete system.
The fourth limit is scope. An execution-profile conformance statement does not guarantee identical behaviour across different models or runtimes.
A security assessment statement does not establish that the assessment is complete or correct. An approval statement does not grant runtime capabilities. Each class says exactly what it says, and a reader who inflates it into a guarantee has misread the draft.
Finally, remember the status. This is a four-day-old -00 draft from a single author, with no working-group adoption and no implementation named.
Its siblings are moving at a similar pace — the execution profile reached -01 in 21 days — so the details here may change. Treat the profile as a direction of travel, not a finished specification.
Should You Track It, Use It, or Wait?
The answer depends on who you are. The profile is four days old, defines no payload format, and names no implementation, so nobody should build a production system on it today.
But the problem it addresses is real, the foundation it builds on is a published standard, and the surrounding family of drafts is growing weekly. Different readers should react differently.
| Reader | Verdict | Why |
|---|---|---|
| Standards watchers and SCITT followers | Track it | It is the first profile applying RFC 9943 to agent packages, and the sibling drafts are moving fast |
| Agent-platform builders | Track it and prototype against RFC 9943 | The digest-binding pattern is usable today; the profile's classes are a good design input even before standardisation |
| Enterprise security teams | Note the pattern, wait for the formats | Digest-bound approvals are the right shape, but without a payload format and a discovery API there is nothing to deploy yet |
| Agent developers shipping packages now | Wait | Nothing in this draft changes how you package, sign, or distribute an agent today |
| Compliance and audit teams | Watch the execution sibling | The execution profile's EU AI Act and DORA mappings are the compliance story; this draft is the package layer underneath it |
The most useful thing a builder can take from the draft today is the digest-binding discipline: bind every claim to the exact bytes it describes, record who made each claim, and let the runtime check the chain before execution. That discipline does not need a standard to be good practice. It needs a standard to be interoperable, and that is what this draft is trying to become.
No CodexFuse tool for SCITT agent package provenance exists, and this article promises none. The profile is a specification in progress, and the honest response to it is to read it, track its revisions, and apply its ideas where they fit — not to ship a tool around a four-day-old draft.
Sources
Every fact in this article comes from a source fetched on 6 November 2026. The draft itself is the primary source; RFC 9943 is the foundation; the two sibling drafts place this profile in its family.
- SCITT Profile for Portable AI Agent Package Provenance, draft-raskar-scitt-agent-provenance-00, R. Raskar, MIT Media Lab, 2 November 2026 — https://datatracker.ietf.org/doc/html/draft-raskar-scitt-agent-provenance-00
- SCITT Profile for Portable AI Agent Package Provenance, plain text, 1,213 lines — https://www.ietf.org/archive/id/draft-raskar-scitt-agent-provenance-00.txt
- An Architecture for Trustworthy and Transparent Digital Supply Chains, RFC 9943, Standards Track, June 2026, Birkholz, Delignat-Lavaud, Fournet, Deshpande, and Lasker — https://www.rfc-editor.org/rfc/rfc9943.html
- AI Agent Execution Profile of SCITT, draft-emirdag-scitt-ai-agent-execution-01, P. Emirdag and D. Feichtinger, Veridic Inc., 12 October 2026 — https://datatracker.ietf.org/doc/draft-emirdag-scitt-ai-agent-execution/
- Causal Provenance Receipts for Agent Sessions: A SCITT Profile, draft-bailey-scitt-agent-session-receipt-00, L. Bailey, WhiteMagic Labs, 25 October 2026 — https://datatracker.ietf.org/doc/draft-bailey-scitt-agent-session-receipt/
- Decision Provenance for SCITT: binding software releases and agent actions to the decisions behind them, draft-lemonnier-scitt-decision-provenance-01, L. Lemonnier, 2 November 2026 — https://datatracker.ietf.org/doc/draft-lemonnier-scitt-decision-provenance/
- Datatracker BibTeX record for draft-raskar-scitt-agent-provenance-00, confirming 13 pages, author Ramesh Raskar, and the 2 November 2026 date — https://datatracker.ietf.org/doc/draft-raskar-scitt-agent-provenance/00/bibtex/
Frequently Asked Questions
What is SCITT agent package provenance in simple terms?
It is a proposal for keeping a signed, checkable history of an AI agent package. Instead of trusting a package because of its name or download link, a runtime can check signed statements — who wrote it, how it was built, whether it was scanned, whether an enterprise approved it — each tied to a digest of the package's exact bytes. The proposal is draft-raskar-scitt-agent-provenance-00, posted on 2 November 2026.
What is a package digest, and why does it matter more than a package name?
A package digest is a cryptographic fingerprint computed from the package's exact bytes. A name, a version label, or a download URL can all point at different bytes tomorrow, so a statement about a name alone cannot prove anything about the content.
Change one byte of the package and the digest changes, the old approvals stop binding, and the new bytes become a different artifact. The digest is the primary artifact binding in this profile.
Is SCITT agent package provenance a standard?
No. It is an Informational Internet-Draft, revision -00, posted on 2 November 2026 and expiring on 6 May 2027.
Internet-Drafts are work in progress and may be updated, replaced, or obsoleted at any time. The foundation it builds on, RFC 9943, is a published Standards Track RFC from June 2026 — but this agent profile itself is new, unstandardised, and not working-group adopted.
What is the difference between package provenance and agent session receipts?
Package provenance covers the package before it runs: who authored it, built it, transformed it, assessed it, approved it, and published it. Session receipts cover the agent after it starts: session start, tool dispatch, state transitions, termination, and settlement.
The two layers are complementary. An execution receipt can identify the exact package digest whose pre-execution provenance was established by this profile, so a deployment can use both.
Can I use this profile to verify an agent package today?
Not as a complete system. The profile defines the mapping and the statement classes, but it defines no payload format, no package format, no discovery API, and no hash algorithm, and it names no implementation.
You can apply its digest-binding discipline in your own designs and prototype against RFC 9943, but there is no standard payload or registry to deploy against yet. Track the draft's revisions and its sibling drafts for the pieces that are still missing.
