Are you an LLM? You can read better optimized documentation at /docs/hub-user/using-hub/attestations.md for this page in Markdown format
Attestations in Jozu Hub
An attestation is a signed, verifiable record tied to a specific ModelKit's SHA-256 digest. Attestations are stored alongside the ModelKit they describe. They can be queried by consumers manually, automated as part of CI/CD pipelines, or used as inputs to policy decisions. Verification works in any environment that has access to the registry and the signing public key, including air-gapped deployments.
Attestations are the primary tool for tying claims to AI artifacts in a way that downstream systems can verify without trusting the registry, the build pipeline, or any intermediate party. Common use cases:
- Lineage and build provenance - prove which base model, dataset, and configuration produced a model
- Security scan results - record what was scanned, when, and what the scanners found
- Evaluation results - attach benchmark scores or reviewer-approved evaluation reports
- Human-in-the-loop decisions - cryptographically record an approval, review, or sign-off event
- License and regulatory classifications - bind license claims to the exact artifact bytes
- Custom claims - any signed statement your organization needs to make about a specific ModelKit
What attestations are for
Attestations in Jozu Hub serve three functions.
Supply chain evidence. An attestation proves that a specific artifact, identified by its SHA-256 digest, was the subject of a specific event (a scan, a build, an approval) at a specific time. The digest binding makes the claim non-transferable: an attestation signed against one ModelKit cannot be reattached to a different one without invalidating its signature. It also allows consumers to validate those findings without having to simply trust that they happened.
Policy evaluation inputs. ArtifactPolicy, ToolPolicy, and GuardrailPolicy rules can require specific attestations as a precondition. A policy can require that a ModelKit has a scan attestation with no critical findings, or an evaluation attestation signed by an authorized reviewer, before it loads into the runtime. Attestations turn opaque "trust the registry" gates into evaluable, signed conditions.
Compliance documentation. Attestations provide cryptographic proof of decisions, scan outcomes, and human reviews. For audit and regulatory purposes, this is stronger than a ticket reference or a row in a database: the proof is bound to the artifact itself and verifiable by any party that has the signing public key.
How attestations work
Every attestation has three properties that matter:
- Bound to a digest. The attestation references a specific artifact by its SHA-256 digest. If the artifact changes by a single byte, the digest changes and the attestation can no longer be used to verify the changed artifact.
- Signed. The attestation carries a cryptographic signature from the entity that produced it - Hub itself, your CI pipeline, or a reviewer using their own key.
- Stored alongside the artifact. Attestations are stored in the same registry as the ModelKit so they're always accessible.
Hub-issued attestations follow the in-toto Statement standard wrapped in a DSSE (Dead Simple Signing Envelope) signature. Any tool that understands in-toto, DSSE, or Cosign can read them - the format is not Jozu-specific. For the full wire-format specification, including envelope structure, subject binding, and predicate schemas, see the ModelKit Attestation Format reference.
INFO
Because attestations live in the same registry, an air-gapped or DDIL environment that has mirrored the ModelKit and its sibling attestation tags can verify everything locally. No callback to Jozu Hub is required at verify time, the verifier only needs registry access and the signing public key.
Hub-generated attestations
Jozu Hub automatically generates and attaches attestations to ModelKits in two cases.
Security scan attestations
Every ModelKit pushed to Hub is security scanned. When the scan completes, Hub signs the result and attaches it to the registry as an attestation against the ModelKit's digest. For details on what is scanned see Security Scanning docs.
Scan attestations use the predicate type URI https://kitops.org/attestation/scan/v1. Policy rules that gate on scan results should match on this URI.
Import provenance attestations
When a ModelKit is created by importing from Hugging Face, Hub attaches an import provenance attestation recording the source URL, the repository commit SHA, and the import timestamp. This preserves the link back to Hugging Face on the imported artifact itself.
Import provenance attestations use the standard SLSA provenance predicate type (https://slsa.dev/provenance/v1) with buildType set to https://jozu.dev/kitops/import/v1. Policy rules that gate on import provenance should match on both URIs.
Attestations and policy enforcement
Attestations are often used with an ArtifactPolicy that is evaluated at admission time, when a ModelKit is about to load into a runtime such as Jozu Agent Guard. An ArtifactPolicy can require that the ModelKit carry a valid scan attestation with no critical findings, a build provenance attestation, or check for any other attestation. A ModelKit that fails to satisfy the policy does not load.
On self-hosted Jozu Hub, pull policies can also use attestations to gate registry egress directly. For example, a pull policy can refuse to release a ModelKit that doesn't carry an approval attestation signed by your model risk committee's key.
TIP
It can be difficult to predict how pull policies will impact teams with different use cases for Jozu Hub. While they are powerful, they can create significant friction if misused.
Attaching your own attestations
You can attach signed attestations to any ModelKit you have push rights to. The Jozu Hub target URL pattern is:
jozu.ml/<account-or-org>/<repository>:<tag>Hub accepts attestations produced by Cosign in either signing mode:
- Key-based signing produces a raw DSSE envelope. Right for on-premises deployments and regulated environments where keys must live in your own KMS.
- Keyless signing via Sigstore produces a Sigstore Bundle wrapping a DSSE envelope. Right for public-cloud CI/CD pipelines where you don't want to manage private keys.
Refer to the Cosign documentation for command syntax, signing flags, and verification. For the wire-format that Hub accepts, see the ModelKit Attestation Format reference.
Lineage and provenance
Lineage and provenance are related but distinct. It's worth being precise about which is which, because the difference changes what attestations you need.
Lineage is the manifest of what went into producing an artifact: which base model, which dataset, which training code, which hyperparameters. Each artifact that was used in the building of an artifact needs its own lineage information. So lineage is a graph or tree. Lineage information can be added as an attestation or SBOM.
Provenance is a signed claim about how an artifact was built or where it came from. Verification confirms who made the claim, not that the claim actually happened that way.
Capturing build provenance for a fine-tuned model
When a fine-tuning job produces a new ModelKit, capture its inputs as a SLSA provenance attestation. This pins the inputs by digest so a verifier can later confirm that the model in production was actually built from the artifacts that were approved.
Resolve the OCI manifest digest for each input ModelKit before the fine-tuning job runs. Build a SLSA provenance predicate that names the inputs and the build configuration:
json
{
"buildDefinition": {
"buildType": "https://jozu.dev/kitops/fine-tune/v1",
"externalParameters": {
"config": {
"learning_rate": 2e-5,
"epochs": 3,
"batch_size": 16
}
},
"resolvedDependencies": [
{
"uri": "jozu.ml/acme/llama-base:v2",
"digest": { "sha256": "abc123..." },
"name": "base-model"
},
{
"uri": "jozu.ml/acme/customer-support-data:v1",
"digest": { "sha256": "def456..." },
"name": "dataset"
}
]
},
"runDetails": {
"builder": {
"id": "https://jozu.dev/kitops/cli",
"version": { "kit": "0.9.2" }
},
"metadata": {
"invocationId": "ft-run-a7b8c9d0",
"startedOn": "2026-03-15T09:00:00Z",
"finishedOn": "2026-03-15T10:00:00Z"
}
}
}Attach the predicate to the fine-tuned ModelKit as a signed SLSA provenance attestation using the predicate type https://slsa.dev/provenance/v1. Refer to the Cosign documentation for command syntax.
The fine-tuned ModelKit now carries a signed claim of exactly which base model digest and which dataset digest it was built from. Substituting a different base or dataset between approval and build will break verification.
Other common attestation patterns
You don't need a build pipeline or SLSA provenance to use attestations. Any claim your organization wants to bind to a specific artifact works.
Evaluation results
After a reviewer signs off on an evaluation report, attach the report as a signed attestation against the ModelKit's digest, using the reviewer's signing key. Downstream policy can require that an artifact has a valid evaluation attestation signed by an authorized reviewer key before it can be deployed.
Human-in-the-loop decisions
When a model risk committee, compliance reviewer, or release manager approves an artifact, capture the decision as a signed attestation. The signing key represents the approver. The payload records the decision, the policy version it was approved against, and the timestamp. Auditors can later verify the approval cryptographically without relying on a separate ticketing system, and ArtifactPolicy can require the attestation before the model loads into production.
License attestations
Attach a signed license attestation that captures the license terms, attribution requirements, and any usage restrictions. This is particularly useful for models derived from sources with restrictive licenses (for example Llama variants that require Meta's license review for commercial use). The attestation makes the license claim verifiable rather than just documented.
Verifying attestations outside Jozu Hub
Attestations are standard Cosign-signed artifacts stored in the registry alongside the ModelKit. They can be inspected with any compatible tooling, with no connection to Hub required at verify time. Refer to Cosign docs for details on how to use it to verify attestations in your environment.