Wiki · Concept · Last reviewed June 25, 2026

Rekor Transparency Log

Rekor is Sigstore's transparency log for signed supply-chain metadata: a public evidence trail for asking who signed an artifact, what was signed, and whether the signing event can be audited later.

Category: Concept Published: June 25, 2026 Modified: June 25, 2026 Last reviewed: June 25, 2026 Tags: AI security, supply chain, Sigstore, Rekor, transparency logs, agent tools

Definition

Rekor is the transparency-log component of Sigstore. Sigstore documentation describes Rekor as a log for signed metadata generated inside a software project's supply chain. The point is not to declare that an artifact is safe. The point is to make a signing event visible, queryable, and auditable after the artifact has moved through registries, build systems, deployment tools, and user machines.

In practical terms, Rekor helps answer a narrow question: was this exact artifact, or the metadata bound to it, recorded in a log that auditors and verifiers can inspect? For AI work, that artifact may be a container image, model-serving binary, tool server, plugin bundle, evaluation harness, or package used by a coding agent. Rekor is therefore an evidence system, not an endorsement system.

How It Works

Rekor records signed metadata in an append-only transparency log. Sigstore documentation says the log is intended to be immutable and tamper-resistant, and that it supports API and CLI workflows for uploading entries, querying entries, checking inclusion proof, and verifying log integrity. In the larger Sigstore flow, Cosign signs and verifies artifacts, Fulcio issues short-lived identity certificates, and Rekor stores transparency evidence for the signing event.

The Sigstore overview explains the basic sequence. A client signs an artifact, then the artifact digest, signature, and certificate are persisted in Rekor. A verifier can later check the artifact signature, expected identity, certificate chain, and proof of inclusion in the log. The verification result still depends on policy: the verifier must know which identity, issuer, artifact digest, and signing context are acceptable.

Transparency also supports monitoring. Rekor entries can be audited for log consistency, and identity owners can monitor for signing events associated with their identities. An unexpected entry can indicate a workflow error, compromised automation, or a release path outside normal review.

AI Artifact Context

AI systems have crowded artifact chains. A single deployment can depend on weights, adapters, tokenizers, containers, libraries, prompts, retrieval indexes, guardrails, evals, notebooks, scripts, and external tools. A human reviewer may approve one thing while the runtime later pulls another.

Rekor helps reduce that substitution problem by giving teams a place to bind signing evidence to stable artifact identifiers. A model registry or deployment gate can require that the digest being deployed has a matching signature and transparency-log evidence from the expected builder, maintainer, or release automation. This does not prove that the model behaves well. It helps prove that the model-like object entering production is the same object the governance process meant to handle.

That distinction is important for AI safety writing. A logged model weight file may still contain unsafe behavior, backdoors, licensing problems, privacy leakage, or poor performance outside the evaluation set. Rekor strengthens custody and auditability; it does not replace evaluation or monitoring.

Agent Supply Chains

Agentic systems make artifact provenance more urgent because they can install tools, build containers, update plugins, fetch packages, and hand results to other systems at machine tempo. Rekor gives these systems a concrete gate: before an agent uses a binary, container, model adapter, or plugin, it can ask whether the object has a logged signing event from an expected identity. This is not a sandbox or behavior monitor. It is a provenance check that can stop unreviewed substitution and make later incident response simpler.

Governance Use

A governance-grade Rekor record should preserve more than the fact that "something was logged." Release records should keep the artifact digest, Rekor entry reference, signature, certificate identity, certificate issuer, verification command or policy, verification time, approving workflow, and deployment target. For AI releases, those records should connect to the model card or system card, AI Bill of Materials, SLSA Provenance, vulnerability review, evaluation summary, and incident-response owner.

Limits

Rekor should not be treated as a trust oracle. A signed and logged artifact can be malicious, vulnerable, overbroad, poorly licensed, or inappropriate for a specific use. The log says a signing event was witnessed; it does not say the artifact was reviewed or safe. Metadata exposure is another concern because public evidence can reveal project names, identities, release timing, or organizational patterns. The control is only useful if verification failures block action.

Source Discipline

Claims about Rekor should cite Sigstore documentation or the Sigstore Rekor repository, and should identify whether the claim concerns the public Rekor instance, Rekor as software, or Rekor's role inside the Sigstore signing flow. When documenting a real artifact, record the artifact digest, signing identity, issuer, log evidence, verification policy, command output, and date checked.

Spiralist Reading

Spiralism reads Rekor as a discipline of witnessed machinery. Modern systems ask people to trust files that arrive without memory: a model blob, a container tag, a plugin release, a tool update. Rekor does not make those objects good. It makes their claimed passage through a signing ritual harder to erase.

The danger is confusing evidence with absolution. A log can tell us that an identity touched an artifact at a time. It cannot tell us that the artifact should govern a worker, advise a patient, classify a student, or speak for an institution. The useful ritual is humbler: ask what object is entering, ask who witnessed it, and keep a record that can be questioned later.

Sources

Return to Wiki