Signing and Provenance: Model Signatures, SLSA Attestations, and Verification at Load

Every attack in this series exploits the same gap: a consumer trusts an artifact without verifying that a trusted party actually produced it, unaltered, the way they claim. Close that gap and the attacks close with it. A malicious checkpoint fails a signature check; a tampered adapter fails an integrity check; a typosquatted name fails a publisher-identity check; a build-time compromise is caught by a provenance attestation. The tools to do this are mature, borrowed from software supply-chain security — cryptographic signing, build provenance, and verification at consumption — and they apply to model artifacts almost unchanged. The only discipline required is to actually verify, and to verify at the one moment that matters: the moment you load.

The control the whole chain reduces to

The model-supply-chain threats look varied — deserialization, adapters, distribution — but they share a single root: unverified authenticity and provenance. In each, the consumer accepts an artifact without cryptographic proof of who produced it and how. So the unifying defense is also single: establish verifiable authenticity (a signature proving who published the artifact) and verifiable provenance (an attestation proving how it was built), and check both before trusting the artifact. Everything else — safe formats, sandboxing, drift detection — is defense in depth around this core.

This is the same insight that reshaped software supply-chain security after a wave of build-system and registry compromises: you cannot secure a supply chain by trusting artifacts, only by verifying them, and the verification must bind an artifact to a trusted producer and a trusted build. The Sigstore project provides signing and transparency for this, and the SLSA framework provides provenance levels; both were designed for software artifacts and apply to model artifacts directly.

The defensive principle is that trust in a model artifact must derive from a verified signature and a verified provenance attestation, not from the artifact's presence on a hub, its plausible name, or its intact download. Signing says who; provenance says how; verification at load says now — and together they answer the question every attack exploits the absence of.

Signing: proving who produced it

A signature binds an artifact to the identity that produced it: the publisher signs the artifact with a key, and a consumer verifies the signature against the publisher's trusted public key, confirming both that the artifact is unaltered and that this specific publisher signed it. This closes tampering (a modified artifact fails the signature) and impersonation (only the real publisher's key produces a valid signature), which are the mechanisms behind malicious artifacts, tampered adapters, and typosquatting alike.

Modern signing systems like Sigstore reduce the friction that historically kept signing from being adopted: they support keyless signing tied to identity providers and record signatures in a public transparency log, so a consumer can verify not just that an artifact was signed but that the signing is publicly auditable. For models, this means an artifact can be signed by its publishing organization's identity and verified by any consumer against that identity, with the signing event logged for accountability.

The critical discipline is verifying against the expected identity, not merely that some valid signature exists. A signature only helps if you check that it was made by the publisher you intended to trust — otherwise an attacker signs their own malicious artifact with their own valid key and passes a naive 'is it signed?' check. Signing binds artifact to identity; the consumer must bind expected identity to the check.

Provenance: proving how it was built

A signature proves who published an artifact, but not how it was produced — and some attacks compromise the build itself, so that even a legitimately-signed artifact contains injected content. Build provenance closes this: an attestation records how the artifact was built (the source, the build system, the inputs, the steps), signed so it cannot be forged. A consumer verifies the provenance to confirm the artifact came from the expected source through an expected, trusted build process, catching build-time compromise that signing alone would miss.

The SLSA framework formalizes this into levels of assurance, from basic provenance existence to hardened, tamper-resistant build processes with verified provenance. For models, adopting SLSA-style provenance means each artifact carries a verifiable attestation of its training or build pipeline — what data and code produced it, on what system — so a consumer can require that a model was built from expected inputs by an expected pipeline before trusting it. This raises the bar from 'a trusted party signed this' to 'a trusted party built this the expected way.'

Provenance also enables forensics and policy. Because the attestation records the build, a consumer can enforce policies (only accept models built from approved data by approved pipelines) and, if a compromise is discovered, trace which artifacts came from an affected build. Provenance turns the opaque question of trust into an auditable, policy-checkable record of production.

Model cards as attestations

Model cards — the documentation accompanying a model describing its training, intended use, and limitations — can serve as machine-verifiable attestations rather than mere prose. When a model card's claims (training data sources, evaluations, safety testing) are structured and bound to the artifact via signing and provenance, they become checkable assertions a consumer's policy can enforce, not just human-readable notes. This extends provenance from how the artifact was built to what the producer attests about it.

The value is turning trust decisions into policy. A consumer can require that a model's card attests to specific safety evaluations, that the attested training data meets a policy, or that the card is signed by the expected producer — and reject models whose attestations are missing, unsigned, or non-compliant. This converts model documentation from marketing into a verifiable input to an automated trust decision, aligned with the signing and provenance backbone.

The discipline, as with signatures, is verification: an attestation only helps if it is signed and checked against the expected producer and policy. An unsigned or unverified model card is unverifiable marketing; a signed, provenance-bound, policy-checked one is an attestation a pipeline can gate on. Treat model cards as claims to verify, not assurances to accept.

Verification at load: the decisive moment

All of this fails if verification does not happen at the right moment. An artifact verified when it entered a registry but loaded later without re-verification is not verified at load — anything could have happened in between, and the loading process trusts whatever bytes it receives. The decisive control is to verify the signature, the provenance, and the attested policy at the moment of load, so that trust is established against the exact artifact being used, at the time it is used, by the process that will use it.

This is the same principle as verifying a dependency at build or install time rather than trusting that it was verified once upstream. For models, it means the loader itself — or a gate immediately before it — checks that the artifact about to be loaded is signed by the expected identity, carries valid provenance from an expected build, satisfies attestation policy, and matches the pinned digest. Only an artifact that passes all of these at load is trusted; anything else is rejected before it enters the process.

The synthesis, grounded in Sigstore, SLSA, and NIST's supply-chain guidance, is that signing and provenance verified at load convert the model supply chain from assumptions into checks. Sign who, attest how, verify now. An artifact verified upstream but loaded unverified is not verified at all, so the load-time gate — checking signature, provenance, attestation, and digest against expected values — is the control on which every other supply-chain defense depends.

Why this matters for agents

Agent stacks load many artifacts automatically, so verification at load is the one control that protects all of them uniformly. If every model, adapter, and merge an agent pipeline loads must pass a load-time gate — verified signature from the expected publisher, valid provenance from an expected build, satisfied attestation policy, matching pinned digest — then the artifact, deserialization, adapter, and distribution attacks all fail at the same checkpoint. The agent trusts only what it can verify, at the moment it uses it.

The organizing lesson is that signing and provenance, verified at load, are the foundational agent supply-chain control, and the rest of the series' defenses (safe formats, sandboxing, drift detection) are depth around it. The mature tooling of software supply-chain security — Sigstore for signing, SLSA for provenance, verification at consumption — transfers to model artifacts, so an agent team's job is to adopt it and to verify at load. Sign who, attest how, verify now: do that, and the model supply chain stops being a chain of assumptions an attacker can break and becomes a chain of checks an attacker cannot pass.

Practitioner Toolkit

Copy-paste, strictly defensive artifacts you can use today. Nothing here attacks a real system.

artifact_trust_policy:
  signing:
    require_signature: true
    verify_against: expected_publisher_identity
    transparency_log: required
  provenance:
    require_attestation: true
    slsa_level: at_least_L3
    expected_build: pinned
  attestations:
    model_card: signed_and_policy_checked
  load_time:
    verify_signature: true
    verify_provenance: true
    verify_attestation_policy: true
    verify_pinned_digest: true
    on_fail: reject

# DEFENSIVE LOAD GATE — sign who, attest how, verify now
function verify_at_load(artifact):
    assert verify_signature(artifact, expected_publisher_key), "bad signer"
    assert verify_provenance(artifact, expected_build), "bad provenance"
    assert attestation_policy_met(artifact), "attestation policy failed"
    assert digest(artifact) == pinned_digest(artifact), "digest mismatch"
    return True   # only a fully-verified artifact is loaded

Glossary

Cryptographic signing

Binding an artifact to a producer's identity with a key, so a consumer can verify authenticity and integrity.

Sigstore

A project providing keyless signing and a public transparency log for software artifacts, applicable to models.

Build provenance

A signed attestation recording how an artifact was built — source, inputs, build system, and steps.

SLSA

A framework defining levels of supply-chain assurance through provenance and tamper-resistant builds.

Attestation

A signed, verifiable claim about an artifact, such as its provenance or a model card's assertions.

Transparency log

A public, append-only record of signing events enabling auditability of who signed what.

Verification at load

Checking signature, provenance, attestation, and digest at the moment of use, against expected values.

Pinned digest

A cryptographic hash of the exact intended artifact, checked at load to ensure the right bytes are used.

References

1. Gu et al., BadNets: Identifying Vulnerabilities in the Machine Learning Model Supply Chain (arXiv 1708.06733)
2. NIST SP 800-218, Secure Software Development Framework (SSDF)
3. NIST SP 800-161r1, Cybersecurity Supply Chain Risk Management Practices for Systems and Organizations
4. NIST AI 100-2 e2023, Adversarial Machine Learning: A Taxonomy and Terminology
5. SLSA: Supply-chain Levels for Software Artifacts
6. Sigstore project documentation