Skip to main content
Agent Volumes is designed from the ground up to address supply chain risks that affect AI agent package ecosystems: fragmented integrity models that tie trust to transport containers rather than content, no standardized publisher identity system, and no shared trust model across bibliothecas. The v0.1 core establishes a baseline that any conforming client or bibliotheca can implement independently, without requiring a universal trust root.

​
The v0.1 core trust baseline

The core trust baseline is built on four established standards:

CycloneDX

The normative BOM exchange format. Every Agent Volumes trust workflow that involves a software bill of materials uses CycloneDX as the portable serialization target.

SLSA provenance

The baseline provenance model. Trust attachments use the https://slsa.dev/provenance/v1 predicate type to record who built a release and how.

Sigstore

Baseline signing and verification. Provenance and signature artifacts use Sigstore-family bundles that carry the signed subject digest, builder identity, and cryptographic evidence.

SPDX

Secondary export format. SPDX is a reference-compatibility target for archival, compliance-oriented, and graph-oriented exchange use cases.
The v0.1 core does not commit to one narrower AI-BOM or ML-BOM profile beyond the generic CycloneDX baseline. AI-specific BOM representation may be refined through future profiles or extensions.

​
Layered verification process

When you install a volume or evaluate trust artifacts for a release, a conforming client performs verification in this order:
1

Resolve and validate the release subject

Identify the release by both its package-facing logical identity (pkg:volume/<name>@<version>) and its immutable content identity (sha256:<hex>). Both identities must be present and consistent.
2

Discover trust metadata

Fetch the trust summary and detail views for the release from the bibliotheca. If the release exists but has no attached trust artifacts, treat this as missing evidence — not as an automatic failure.
3

Apply lifecycle status filtering

Exclude trust attachments whose status is revoked or invalid. Exclude superseded attachments from satisfying current-state evidence requirements. Both types remain in the append-only record for audit purposes, but they do not count as active evidence.
4

Validate artifact format identity

Check each remaining trust attachment against the baseline category and format conventions: cyclonedx for BOMs, slsa-provenance for provenance, and sigstore-bundle for signatures.
5

Retrieve the trust artifact bytes

Fetch the artifact bytes or use the embedded representation from the detail view. Verify the retrieved bytes against the attachment’s artifactDigest before interpreting the contents.
6

Validate release-subject binding

Confirm that each artifact’s declared subject matches both the logical identity (pkg:volume/...@version) and the immutable content identity (sha256:...). Reject the release if any attachment claims an incompatible identity.
7

Verify Sigstore-family signatures

For signature artifacts, verify the cryptographic signature, the signing certificate or key material, any bundled transparency or timestamp evidence, and the signed subject digest.
8

Verify SLSA provenance

For provenance attestations, verify the attestation envelope, require the predicate type https://slsa.dev/provenance/v1, and confirm that the provenance subject digest matches the release integrity value.
9

Validate CycloneDX BOMs

For BOM artifacts, validate the BOM structure and schema/profile identity, and check that the mapped package identity and SHA-256 hash fields match the release subject when present.
10

Report objective facts separately from policy

Surface verification successes and failures as objective artifact facts. Leave broader trust policy — builder identity allowlists, vulnerability blocking, absence of non-mandatory artifacts — as local inputs rather than core hard failures.

​
Threat model

​
In-scope threats

The following threats are within the scope of what the v0.1 baseline is designed to mitigate:

​
Out-of-scope threats

The v0.1 baseline does not claim to solve all possible threats. The following remain outside the guaranteed baseline:
  • Endpoint compromise on the consumer side after trusted installation
  • Arbitrary runtime sandbox escape not covered by runtime-specific enforcement
  • Universal trust-root agreement across independent bibliothecas
  • Generalized malware or vulnerability scanning result normalization across all scanners
  • Portable scanner-finding interchange or scanner severity normalization

​
Trust attachment lifecycle

Release-scoped trust attachments are append-only. Once a bibliotheca accepts a trust artifact for a release, the following invariants hold:
  • The published release content identity remains immutable and cannot be changed.
  • New trust attachments may be added after publication without replacing existing ones.
  • Previously published trust attachments are never silently replaced, rewritten, or reinterpreted.
When a trust attachment later becomes invalid, superseded, or revoked, it remains part of the append-only record. Its status changes through status metadata, not deletion. The superseded status means the attachment has been replaced by a newer artifact — it does not mean the attachment was compromised. A superseded attachment may still be evaluated by historical or audit workflows, but it does not satisfy mandatory current-state evidence requirements.

​
Client trust consumption baseline

When consuming trust metadata from a bibliotheca, apply these minimum behaviors:
  • Reject on digest or subject-binding mismatch. If a trust artifact’s declared subject does not match the release identity, treat the release as inconsistent and fail.
  • Reject on explicit revocation or invalidation. Treat revoked and invalid attachments as failures by default. You may override this only with an explicit non-baseline configuration.
  • Treat superseded evidence as stale. If the only available evidence for a mandatory trust category is superseded, report a stale or insufficient-current-evidence diagnostic rather than treating it as equivalent to an active attachment.
  • Distinguish facts from policy. The trust summary view may include derived judgments such as verification labels. These are not canonical trust facts. Consume the raw objective facts from the detail view and apply your own policy locally.
Scanner findings are not advisory records and not trust attachments in v0.1. A bibliotheca may create an advisory based on scanner information under local policy, but the portable contract is the advisory read/discovery model only. See Security advisories for details.