MIT Media Lab

raskar@mit.edu

Security Supply Chain Integrity, Transparency, and Trust SCITT AI agents agent packages provenance transparency software supply chain Portable AI agent packages can contain executable or interpretable behavior, prompts, workflow graphs, tool schemas, dependencies, and declarations of execution requirements. Such packages may be authored, transformed, repackaged, scanned, approved, published, superseded, and withdrawn by different parties before they are executed by an independent runtime. This document describes a SCITT application profile for transparent provenance of portable AI agent packages. It maps the package lifecycle to the SCITT architecture, identifies an immutable package digest as the artifact binding point, and defines classes of supply-chain statements that can be made about a package without defining a new statement payload format. Examples include authorship, build and transformation, execution-profile conformance, security assessment, publication, approval, supersession, and withdrawal statements. This document does not define a portable-agent package format, agent execution protocol, runtime authorization model, or per-action execution receipt. It complements SCITT profiles that record agent actions or sessions by focusing on the provenance of the agent package before and across deployment.

Introduction AI agents are increasingly distributed as artifacts that can be retrieved and interpreted by execution environments other than the system in which they were authored. A portable agent package can contain prompts, role instructions, workflow definitions, compiled components, tool schemas, policy references, model-interface requirements, and dependencies. The package can therefore influence consequential behavior even when the model, tools, and runtime are supplied separately by the receiving environment. The software-supply-chain questions around such an artifact are not limited to whether its bytes are signed. A relying party can need to determine who authored a package, which build or transformation produced a particular digest, whether an independent party assessed it, whether a specific organization approved it, whether the package has been superseded or withdrawn, and whether the statements presented by a distributor correspond to an auditable history. SCITT provides an architecture for signed statements about artifacts, registration of those statements with a Transparency Service, and receipts that can be independently verified. This document applies that architecture to portable AI agent packages.

Scope This document defines a domain-specific mapping between portable AI agent package lifecycle events and SCITT concepts. It specifies the artifact binding requirements and 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.

Goals

• Bind claims to an immutable version of a portable agent package.
• Allow multiple independent issuers to make accountable statements about the same package artifact.
• Represent derivation and transformation relationships between package versions or repackaged artifacts.
• Allow a runtime, enterprise administrator, auditor, or other relying party to verify the provenance history relevant to local policy before execution.
• Reuse the SCITT architecture and COSE receipts rather than defining a separate transparency mechanism for agent packages.

Non-Goals This document does not define how an AI agent is authored, how an agent package is encoded, how an execution profile works, how a runtime grants access to models or tools, or how individual agent actions are recorded. It does not define a universal registry for agent packages and does not establish that a signed or transparent statement is true. It also does not define payload formats such as an agent SBOM, capability manifest, security-assessment report, or policy document.

Terminology The terminology of applies. In particular, this document uses the terms Artifact, Issuer, Signed Statement, Transparency Service, Receipt, Transparent Statement, Auditor, and Relying Party as defined there.

Portable Agent Package:

A distributable artifact containing or referencing an AI agent definition together with metadata, resources, dependencies, or execution requirements needed by an independent runtime.

Logical Package Identifier:

A stable identifier that can refer to a package across versions. It is not sufficient, by itself, to identify immutable package content.

Package Digest:

A cryptographic digest over the immutable package representation or over a canonical manifest that commits to the package content. The digest is the primary Artifact binding used by this profile.

Package Producer:

An entity or toolchain that transforms an agent definition and related resources into a distributable Portable Agent Package.

Package Transformation:

An operation that produces a new package artifact from one or more prior artifacts, for example compilation, policy hardening, dependency vendoring, repackaging, or enterprise customization.

Package Provenance Statement:

A Signed Statement about a Portable Agent Package, its creation, transformation, assessment, publication, lifecycle state, or relationship to another artifact.

Portable Agent Package Supply Chain A Portable Agent Package can pass through several administrative domains before execution. The following is illustrative: Package A (digest A) | | | +--> security assessment | +--> profile-conformance claim v Enterprise transformer ---> Package B (digest B) | +--> enterprise approval +--> publication statement | v Runtime ]]> The author, package producer, transformer, security assessor, publisher, enterprise approver, and runtime operator can all be different entities. A single signature on Package B cannot, by itself, express the full history or distinguish which entity is accountable for which claim. This profile treats Package A and Package B as distinct Artifacts because their digests differ. Statements can relate the artifacts by identifying the input digest and output digest of a transformation.

Mapping Portable Agent Packages to SCITT

Artifact The SCITT Artifact is a specific immutable Portable Agent Package, identified by a Package Digest. A statement about a mutable package name or distribution URL alone is insufficient for artifact-specific provenance because the content reachable at that name or URL can change.

Issuers Different supply-chain actors can be Issuers for different statements. Examples include 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.

Transparency Service and Receipts A Signed Statement can be registered with a SCITT Transparency Service according to . A Receipt as defined by provides verifiable evidence that the statement was registered in the Transparency Service's Verifiable Data Structure.

Relying Parties Typical Relying Parties include a runtime deciding whether to admit a package, an enterprise policy engine, a package marketplace, a security auditor, or an operator investigating a deployed package. The Relying Party determines which Issuers, Transparency Services, statement classes, and freshness requirements satisfy local policy.

Artifact Identity and Digest Binding A Package Provenance Statement in this profile needs to identify the exact package content to which the statement applies. The statement therefore needs an artifact identifier that includes or unambiguously resolves to a cryptographic Package Digest. A Logical Package 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. This distinction permits a package to have multiple releases while keeping claims about each release independently verifiable. Where a package is represented by a manifest plus referenced members, the package format or an adjacent specification needs to define what the Package Digest commits to. This profile does not define package canonicalization or archive hashing rules.

Statement Classes This section 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.

Authorship and Source Statement An Issuer can state that a particular package or package input was authored from a particular source revision, source repository state, or agent definition. This can help connect a distributed package to its claimed origin.

Build or Transformation Statement A package producer or transformer can state that an output package digest was produced from one or more input digests using a named build or transformation process. Examples include compilation, conversion from a framework-specific graph to a portable execution profile, dependency vendoring, policy hardening, or enterprise repackaging.

Execution-Profile Conformance Statement A conformance service can state that a specific package digest was tested against a named execution profile and report the result. The claim establishes what the Issuer tested and asserted; it does not guarantee identical behavior across different models or runtimes.

Security Assessment Statement A scanner, evaluator, or red-team service can state that a package digest was evaluated using an identified procedure and can reference the resulting report. SCITT provides transparency and accountability for the statement; it does not establish that the assessment is complete or correct.

Publication and Release Statement A publisher or package owner can state that a specific package digest is an official release, is available from one or more distribution endpoints, or is the current release associated with a Logical Package Identifier.

Approval Statement An enterprise, marketplace, administrator, or other policy authority can state that a package digest is approved for a defined scope. The approval can reference policy, environment, validity interval, or deployment class without granting runtime capabilities by itself.

Supersession, Withdrawal, and Revocation Statement An authorized Issuer can state that a package digest has been superseded by another digest, withdrawn from distribution, or is no longer approved for a stated purpose. A Relying Party needs local policy for deciding how these lifecycle statements affect previously issued approvals and cached artifacts.

Transformation and Provenance Chains Portable agent packages are frequently transformed. A framework can compile an agent definition into a portable profile; an enterprise can replace a dependency or restrict capabilities; a distributor can repackage the result for another platform. Each transformation can create a new artifact digest. A useful provenance graph therefore consists of statements that bind input artifact digests to output artifact digests. The graph can be traversed by a Relying Party to answer questions such as:

• Which source or prior package produced this artifact?
• Which entity performed each transformation?
• Which assessments apply to the exact artifact being executed?
• Was an approved artifact later modified or repackaged?
• Has a later statement superseded or withdrawn an earlier release?

SCITT transparency makes the statements auditable; it does not define the semantics of every transformation or prove that an Issuer described a transformation truthfully.

Example Lifecycle Consider an agent definition created by an authoring framework. A package producer creates Package A and publishes a build statement that relates the source revision to digest A. An independent evaluator issues a security-assessment statement for digest A. An enterprise then applies a policy transformation that removes one dependency and constrains the tool set, producing Package B with digest B. The enterprise issues a transformation statement relating digest A to digest B and an approval statement for digest B. Before execution, a runtime computing digest B can verify the enterprise approval, inspect its SCITT Receipt, verify the transformation statement, and optionally trace the history back to digest A and the author statement. If the package bytes are changed after approval, the digest changes and the prior approval no longer binds the new artifact.

Relying Party Processing A Relying Party applying this profile can perform the following conceptual steps. Exact APIs for discovering and retrieving statements are outside this document.

1. Compute or otherwise securely obtain the Package Digest for the candidate artifact.
2. Obtain the Package Provenance Statements relevant to local policy.
3. Verify each Signed Statement according to and the applicable Issuer identity policy.
4. Where transparency is required, verify the associated Receipt according to .
5. Check that each statement binds the exact Package Digest or an explicitly related artifact in a verified transformation chain.
6. Evaluate freshness, supersession, withdrawal, and Issuer authority according to local policy.
7. Use the resulting provenance information as one input to the local admission or audit decision.

Successful verification does not itself authorize execution or grant access to models, tools, credentials, data, storage, or network resources.

Relationship to Agent Execution Transparency 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. describes a SCITT profile for tamper-evident records of material AI-agent actions. describes causal provenance receipts for agent-session lifecycle events. Those documents focus on post-admission execution evidence. This profile focuses on the package artifact that a runtime is considering before or across deployment. A deployment can use both layers. For example, an execution receipt can identify the exact Package Digest whose pre-execution provenance was established using this profile.

Relationship to Portable Agent Architecture A portable-agent architecture separates the package supplied by an author or package producer from the models, tools, storage, network access, and other capabilities supplied by a runtime. The package can declare requirements, but those declarations do not confer authority. This SCITT profile addresses a different question: what verifiable provenance statements are available about the package artifact before a runtime evaluates compatibility and authorization? The package format, execution profile, and runtime authorization model remain outside this document. The SCITT Artifact identifier is therefore based on immutable package content rather than on a specific authoring framework or runtime.

Security Considerations The security considerations of and apply. 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. Relying Parties need policy for which Issuers are authoritative for each statement class. Artifact substitution is a central threat. Approval or assessment statements that bind only a package name, URL, or mutable tag can be replayed against different content. Security-relevant statements should bind the immutable Package Digest. Incomplete provenance is another risk. A distributor can omit an unfavorable assessment or withdrawal statement while presenting valid positive statements. Transparency Services improve auditability and can expose history, but Relying Parties still need a method or policy for determining which classes of statements are expected and whether the observed history is sufficiently complete for the decision being made. Key compromise can affect author, builder, assessor, publisher, or approval identities. Relying Parties need to evaluate key lifecycle and revocation information according to the identity mechanism used by each Issuer. A later withdrawal statement does not erase a previously valid transparent statement; policy determines its continuing effect. Provenance information can also reveal sensitive development relationships, internal toolchains, package names, or security findings. Deployments should minimize statement content and consider whether the relevant Transparency Service is public, permissioned, or otherwise access controlled.

Privacy Considerations Portable agent packages can contain prompts, policy references, internal service names, or other sensitive metadata. This profile does not require such package content to be included in a Signed Statement. Statements should normally identify artifacts by digest and disclose only the claim data required by the relying application. Registration and query activity can reveal interest in a package or relationships among authors, enterprises, and deployment environments. The privacy considerations for the chosen SCITT Transparency Service and adjacent statement-discovery mechanisms therefore apply.

IANA Considerations This document has no IANA actions. It does not define a new SCITT media type, COSE header parameter, statement payload format, or package media type.

Normative References Informative References

Acknowledgements This document builds on the SCITT architecture and on prior work on portable AI agent packaging, runtime independence, and software supply chain provenance. Feedback from the SCITT community is invited.