Helmwart
← Atlas · Mitigations Tier 1 · Production-canonical

MITIGATION · m-sigstore

Sigstore signing — cryptographic provenance for agent artifacts and audit records

An agent is composed of artifacts produced at different times by different identities: model weights, prompt templates, tool descriptors, MCP server binaries, and audit-log batches. Any of those artifacts can be substituted or tampered with between the moment they are built and the moment they are loaded. Sigstore addresses this by signing each artifact at build time using a short-lived certificate tied to the workload identity that produced it, recording the signature in an append-only public transparency log, and requiring verification against that log before the artifact is loaded or executed.

Last reviewed 2026-05-11 · Status: published · Evidence →

At a glance

MATURITY
Tier 1
Standardised, widely deployed, third-party audited. Pick this tier first unless you have a concrete reason not to.
PLACES ON
node · edge
Restricted to node kinds: audit-log, tool-bus
COVERAGE
3 threats
T8 · T17 · T29
TRADE-OFFS
LAT
low
COST
low
UX
low
DEV
low
Latency · cost · UX friction · dev effort.
TL;DR
  • Sign every agent artifact at build time, model weights, prompt templates, tool descriptors, MCP server binaries, and audit-log batches, and verify the signature before the artifact is loaded or executed.
  • Keyless signing removes long-lived private keys from the equation: each signing event uses a short-lived certificate tied to the CI workload identity, with the signature recorded in an append-only transparency log (Rekor) that any verifier can check.
  • Verification is offline once the bundle is stored alongside the artifact; Rekor provides an inclusion proof that the entry existed at signing time, making post-build substitution detectable.
  • Signing confirms the artifact has not been modified since it was built by the expected identity. It does not attest to runtime behavior or the semantic content of model weights or prompt templates.

How it behaves

Agent loads artifact (model, prompt template, tool descriptor, or MCP binary)
Verify signature bundle: certificate chain, signature match, and Rekor inclusion proof
Load artifact and proceed
Reject artifact and raise alert
Treat the absence of a valid bundle as a tamper signal. Never load an artifact whose signature cannot be verified against the transparency log.

What it is

Sigstore is an OpenSSF project that provides keyless artifact signing. Instead of generating and distributing long-lived private keys, a signer authenticates to Fulcio, Sigstore's certificate authority, using an OIDC identity issued by a trusted provider such as GitHub Actions or Google Cloud. Fulcio issues a short-lived certificate that binds the signer's identity to a public key. The signer uses that key pair to sign the artifact, and the resulting bundle, containing the certificate, the signature, and a transparency log entry, is published to Rekor, an append-only public log. Anyone can later verify the bundle: they confirm the certificate chain, check that the signature matches the artifact, and retrieve an inclusion proof from Rekor showing the entry was present in the log at signing time.

For agentic AI systems, this mechanism covers two distinct problems. First, an audit log signed with Sigstore is tamper-evident: Rekor's append-only structure means a deletion or alteration of any signed entry is detectable by any verifier, even one with no prior knowledge of the log state. Second, every artifact that composes an agent, model weights, prompt templates, tool descriptors, MCP server binaries, SLSA provenance attestations, can be signed at build time by the CI identity that produced it and verified at deployment time before it is loaded. Signing proves the artifact was produced by the expected identity and has not been modified since; it does not attest to the artifact's runtime behavior or semantic content.

Detection signals

  • Signature verification failures at artifact load time. A nonzero rate means an artifact was substituted, corrupted, or signed by an unexpected identity between build and deployment.
  • Rekor inclusion-proof failures. A bundle that cannot be confirmed against the transparency log indicates either a tampered bundle or a signing event that did not complete correctly.

Threats it covers

  • T8 Repudiation and Untraceability −2 severity steps

    WHY IT HELPS Repudiation and Untraceability arises when agent actions cannot be reliably traced or attributed after the fact. A signed audit log makes each entry tamper-evident: Rekor's append-only inclusion-proof model means any deletion or alteration is detectable by any verifier, and the identity of the signer is bound to the certificate at signing time.

  • T17 Supply Chain Compromise −1 severity step

    WHY IT HELPS Supply Chain Compromise occurs when a compromised or substituted upstream artifact, a model weight, prompt template, plugin, or framework update, reaches the agent without detection. Signing each artifact at build time and verifying the signature against the Rekor transparency log at deployment time gives cryptographic proof that the artifact loaded is the one that was built by the expected identity.

  • T29 Plugin Vulnerability Leading to Agent Compromise −1 severity step

    WHY IT HELPS Plugin Vulnerability Leading to Agent Compromise requires deploying a malicious or substituted plugin to the agent. Signing plugin artifacts at build time and verifying the signature against the Rekor transparency log at deployment time detects substitution before the plugin executes.

Principle coverage

Defence-in-Depth stage: Prevent — and it advances:

  • Supply-chain Security Supply-chain integrity requires that every component the agent loads be verifiable back to the build identity that produced it. Sigstore signs each artifact at build time using a short-lived OIDC certificate and records the signature in the Rekor transparency log, so any substitution between build and deployment is detectable before the component executes.

Design & governance principles (open design, economy of mechanism, accountability, …) are architectural, not advanced by a single placed control.

Implementation options

Four signing toolchains with genuinely different trust models. For new agentic pipelines in cloud-native environments, Sigstore is the default choice; the others cover specific gaps: air-gapped deployments, X.509 PKI shops, and multi-party step-level attestation. GitHub Artifact Attestations are Sigstore-powered and belong in the Sigstore row, not as a separate trust model.

Sigstore (cosign + Fulcio + Rekor) Keyless OIDC signing of blobs, OCI images, and SLSA provenance attestations, with signatures published to a public transparency log.

Why choose it: Best for cloud-native agentic pipelines where signing happens in CI (GitHub Actions, GitLab CI, Google Cloud Build). No key management: the workload authenticates via OIDC, receives a short-lived certificate from Fulcio, and the signed bundle is published to Rekor. Verification at deployment requires only the bundle file. Native to npm provenance, PyPI attestations, and GitHub Artifact Attestations (GA June 2024), so the pattern is already standard across major ecosystems. Use cosign sign-blob for model weights and prompt bundles; cosign attest for SLSA provenance on OCI-hosted agent images.

More details:

Notary v2 (notation) X.509 PKI-backed artifact signing for OCI registries, with air-gapped signing support and no dependency on a public transparency log.

Why choose it: Best when your environment cannot reach a public transparency log (air-gapped, highly regulated) or when your organisation already operates a corporate CA. notation uses standard X.509 trust stores and supports configurable trust policies scoped to specific registries and signing identities. v1.x is stable for OCI image signing; v2.0-alpha introduces arbitrary blob signing for non-container agent artifacts. AWS, Microsoft, and Docker are active contributors. The absence of a transparency log means tamper evidence depends on the integrity of your own key infrastructure rather than a publicly auditable log.

More details:

in-toto + TUF Supply-chain integrity framework that cryptographically binds each step in a build pipeline to authorized functionaries, with TUF handling secure key distribution and rotation.

Why choose it: Best when your threat model requires proving not just that a final artifact is intact but that each step of the pipeline (training, fine-tuning, packaging, signing) was performed by the expected identity using the expected inputs. in-toto layout metadata defines the authorized steps and functionaries; link metadata captures evidence at each step. TUF wraps the key distribution so that key compromise or revocation is survivable. CNCF graduated project adopted by PyPI and Datadog. The operational cost is higher than Sigstore: you must define and maintain a layout, run step-signing at each pipeline stage, and operate TUF key infrastructure. Appropriate for high-assurance agent pipelines with multi-party accountability requirements.

More details:

GPG / X.509 CMS Long-lived key-based signing using GnuPG or standard X.509 CMS, with no dependency on network-reachable infrastructure at signing or verification time.

Why choose it: Best for air-gapped environments where neither a transparency log nor an OIDC provider is reachable, and for teams already operating GPG-based artifact signing (Linux distribution packages, git commit signing). GPG detached signatures (.sig/.asc) can cover any blob including model weights and prompt archives. The key management burden is the dominant operational cost: key generation, distribution, revocation, and rotation must all be handled out-of-band. No transparency log means simultaneous substitution of both the artifact and its signature is undetectable unless the public key is independently pinned. For new agentic pipelines, GPG is a fallback for air-gapped constraints, not a first choice.

More details:

Trade-offs

  • Verification adds latency only once per artifact load, typically under 100 ms for a local bundle check, but signing in CI adds one step per artifact and requires bundle storage alongside each artifact at rest.
  • Sigstore's keyless flow requires a live OIDC provider and Fulcio CA at signing time. If your CI pipeline cannot reach the public Sigstore infrastructure you must run a private instance (additional operational overhead) or use key-based signing instead.
  • Model weights and large prompt archives can be hundreds of gigabytes. The signing operation itself is fast because it signs the content hash rather than the full file, but bundle storage and transfer require explicit pipeline design; tooling does not handle this automatically.
  • Signing proves the artifact was produced by the expected CI identity at build time, not that the artifact is safe to run. A correctly signed but malicious model weight or poisoned prompt template still passes signature verification. Behavioral testing and SBOM vulnerability checks are complementary, not redundant.

When NOT to use

  • Do not apply Sigstore's keyless OIDC flow in an air-gapped deployment where neither Fulcio nor Rekor is reachable and you are unwilling to operate private instances. Use Notary v2 with a corporate CA or GPG key-based signing instead.
  • Do not rely on artifact signing as the primary control for runtime prompt injection, live API parameter manipulation, or adversarial model outputs. Signing attests build-time provenance, not runtime behavior. Pair with output moderation and input sanitization.
  • Do not verify signatures only in CI and skip verification at deployment time. An adversary who can substitute an artifact between the registry and the agent host bypasses build-time signing entirely. Verification must happen at the point of loading.

Limitations

  • Sigstore's keyless flow trusts the OIDC identity provider (GitHub Actions, Google, Microsoft). A compromised identity provider or a misconfigured CI identity binding (wrong workflow path or ref) defeats the signing guarantee without producing an observable failure at signing time.
  • The public Rekor transparency log retains signing events permanently by design. If signing metadata contains sensitive information such as internal path names or proprietary workflow identifiers, use a private Rekor instance.
  • Signature verification confirms only that the artifact matches what was signed. It cannot detect semantic tampering introduced before the signing step, such as model poisoning during training or prompt injection baked into a prompt template at authoring time.
  • There is no industry-standard scheme for signing and verifying the full composition of a running agent (model, prompts, tools, and memory state) as a single attestable unit. Each component must be signed individually, and composition integrity is a deployment-specific policy decision.

Maturity tier reasoning

  • Tier 1 fits because Sigstore is OpenSSF-governed with a public third-party security assessment (OSTIF/Include Security 2022), and is natively integrated in npm and PyPI at ecosystem scale. The underlying cryptographic primitives, X.509 certificates, Merkle transparency logs, and OIDC, are well-understood and widely deployed.
  • cosign sign-blob is production-stable and the bundle format has been stable since cosign v2. GitHub Artifact Attestations (GA June 2024) demonstrates the pattern is endorsed by a major platform vendor.
  • The agentic-AI-specific application, signing model weights, prompt templates, tool descriptors, and MCP server binaries, extends the same blob-signing mechanism. The tooling is production-ready, though operational playbooks for agent artifact signing are still being established across the industry.

Last verified against upstream docs: 2026-05-30.