How to Verify AI Model Provenance with Sigstore Signing

You verify an AI model's provenance by checking a cryptographic signature over the model's files against an identity you already trust. In practice: the publisher hashes every file in the model directory, signs that manifest, and ships the signature next to the weights; you recompute the hashes, check the signature, and confirm the signer is the identity you expect, such as a specific release workflow or a named publisher account. The OpenSSF model signing specification, implemented by the open-source sigstore/model-transparency project, does this with Sigstore's keyless signing or with conventional keys and certificates. A signature proves who produced the files and that they have not changed. It does not prove the model is safe, so pair it with format checks, evaluation and controls on what agents do with the model.

Why model provenance matters now

Models move through many hands: a base model from one publisher, a fine-tune from another team, quantized variants from a third, mirrored into an internal registry, pulled by a runtime. At each hop, a file can be swapped or altered. Hashes on a model card help only if the card itself is trustworthy and someone checks them.

Two kinds of tampering matter. The first is code execution on load, which affects pickle-based formats and is covered in are pickle model files safe?. The second is altered weights: a backdoor or degraded behaviour that loads cleanly in any format. Signing addresses both at the integrity level: if the bytes differ from what the publisher signed, verification fails.

For agents, provenance feeds directly into trust. An agent's behaviour depends on the model behind it, and a trust decision about the agent is weaker if nobody can say which weights it ran. This sits alongside the rest of securing the agent supply chain.

How OpenSSF model signing works

The design is deliberately simple, and it treats a model as a directory of files rather than a single blob:

Hash every file. The tool walks the model directory and computes a digest per file (large files can be hashed in shards so signing stays fast).
Build a manifest. The list of (file path, digest) pairs becomes the payload of an in-toto statement.
Sign it. The statement is wrapped in a DSSE envelope and signed. The result is a Sigstore bundle stored next to the model, for example as model.sig.
Verify. The verifier recomputes every file digest, checks that the manifest matches, and checks the signature and signer identity.

Because the manifest lists a digest for each file, an edited file fails verification, and that includes config and tokenizer files that change behaviour without touching the weights.

Three ways to sign

Method	How identity works	Good fit
Sigstore keyless (default)	Signer authenticates with OIDC (for example a CI workflow identity or a user account); a short-lived certificate is issued and the signature is recorded in a public transparency log	Public releases from CI; no long-lived signing key to protect
Private key	You hold a key pair; verifiers pin the public key	Air-gapped or private pipelines
Certificate	Signature chains to your own PKI	Organisations with an existing internal CA

The project also supports PKCS #11 hardware-backed keys as an optional install. Pick keyless for public distribution where you want a public log entry, and keys or certificates for internal models that must not appear in a public log.

A minimal sign-and-verify flow

The model_signing CLI from the project README shows the shape. Signing with Sigstore keyless opens an OIDC flow:

pip install model-signing
model_signing sign bert-base-uncased

Verification must pin who you expect the signer to be:

model_signing verify bert-base-uncased \
  --signature model.sig \
  --identity "$identity" \
  --identity-provider "$oidc_provider"

For key-based signing, the equivalent commands are model_signing sign key ... --private-key key.priv and model_signing verify key ... with the public key. Check the project's README for current flags before scripting it, since the CLI is evolving.

The step teams skip: pinning the identity

A signature that verifies proves that someone signed these exact files. It does not prove that the right someone did. With keyless signing, anyone can obtain a certificate for their own identity and sign a malicious model. Verification is meaningful only when you compare the signer to an expected value:

For CI-signed releases, pin the workflow identity (repository and workflow path) and the CI's OIDC issuer.
For a publisher, pin the account or domain identity they publish under, obtained through a channel you trust.
For internal models, pin your own key or CA.

Store the expected identities in configuration that is reviewed like code, and fail closed: a model with no signature, an invalid signature or an unexpected signer does not load.

Provenance verification checklist

Require a signature for every model your services and agents load; define the exception process for unsigned public models
Verify at ingestion into your internal registry and again at load time
Pin expected signer identity and identity provider (or public key / CA) per model source
Fail closed on missing, invalid or unexpected signatures
Sign your own fine-tunes and quantized variants in CI, so internal provenance does not stop at the base model
Record the model digest and signer in your AI bill of materials
Log, at load time, which signed model each agent runtime loaded
Re-verify after mirroring or format conversion; a converted file needs a new signature from the converter

What signing does not cover

Signing is an integrity and identity control. It does not tell you:

Whether the signer is honest or competent. A trusted publisher can still ship a poisoned dataset or a flawed model.
How the model was trained. Training provenance (data, code, compute) needs separate attestations, such as SLSA-style build provenance for the training pipeline.
What happens after load. A correctly signed model can still be steered by prompt injection or misused by an over-privileged agent.

That last gap is where agent governance takes over. Provenance from artefact to action needs two signed records: one proving which weights were loaded, and one proving what the agent did with them. The second is an audit-trail problem, covered in tamper-evident audit logs with cryptographic proofs, with a runnable teaching example in the signed audit log verification lab. How signed attestations feed agent trust decisions is covered in trust scores and attestations for agents.

How Praesidia fits

Praesidia does not sign model weights; use OpenSSF model signing for that. It covers the action side:

Discover. Agent discovery inventories the agents and MCP servers you register, the traces you send, and the GitHub and GitLab repositories you connect, so you know which agents need model provenance at all.
Secure. Model allow-lists on each governed connection are checked at dispatch, so agents use the models you approved. Trust scores weigh verified attestations from enrolled signing authorities; unverified or self-asserted attestations do not affect the score.
Prove. Praesidia records its decisions in an append-only, hash-chained audit trail, signed under the default configuration with your organisation's key, which you can verify offline with the open-source praesidia-verify tool. A signed record shows the record was not changed afterwards; it does not show that every action was captured.