For most of computing history, trust was implicit. You installed the package from npm because it was on npm. You believed the photo in your feed because photos were hard to fake convincingly. You trusted the data in your warehouse because someone you knew had loaded it. None of that trust was verified — it was assumed, because forging the alternative was expensive or obvious.

That assumption has collapsed on three fronts simultaneously, and the collapse is why digital provenance — the verifiable record of a digital asset’s origin, authorship, modifications, and chain of custody — has gone from a niche concern to, in Gartner’s framing, one of the Top 10 Strategic Technology Trends for 2026. The same analysts estimate that organisations that fail to invest in provenance by 2029 face sanction risks potentially in the billions. This is no longer just good hygiene; it’s becoming a trust differentiator and a hard compliance requirement.

Three collapses, one cause

Software. Attackers learned that the cheapest way into thousands of organisations is through the build pipeline, not the firewall. SolarWinds, Log4Shell, CodeCov, and the 2025 GhostAction campaign all showed the same thing: a compromised build or a typosquatted dependency reaches every downstream consumer at once. Knowing what is in your software stopped being enough; you now have to prove where it came from and how it was built.

AI-generated content. Synthetic media went from a curiosity to a flood. Deepfake incidents grew roughly 900% from 2023 to 2025 (one count puts it at over 8 million incidents in 2025), and analysts project synthetic content could account for up to 90% of online media. When anyone can generate an indistinguishable image, video, voice, or document, “seeing is believing” is dead. You need a way to know what’s real that doesn’t depend on the content looking real.

Data. As data feeds analytics, decisions, and — increasingly — AI model training, “where did this data come from, and can I trust it?” became a question with legal and financial weight: copyright, consent, contamination, and auditability all hang on it.

The common cause beneath all three: the cost of forging a convincing fake dropped to near zero, so trust now has to be proven rather than assumed. Provenance is how you prove it.

Provenance vs. lineage: a distinction worth getting right

Two terms get used loosely, and developers should keep them separate. Provenance answers “is this authentic, and where did it come from?” — proof of origin, authorship, and integrity. Lineage answers “how did this move and transform?” — the flow of data or an artifact across systems. Provenance is about trustworthiness at a point; lineage is about the path. You generally need both: provenance to decide whether to trust the source, lineage to understand the downstream blast radius if you can’t. This post is about provenance, but the two interlock constantly, especially for data.

What regulation just did to the timeline

Adoption was already growing; regulation fixed the deadline. The compliance clock is concrete and, as of 2026, largely already running:

• EU AI Act, Article 50 — enforceable from August 2, 2026 — requires deployers of AI systems to disclose when content has been artificially generated or manipulated, using both visible markings and machine-readable metadata.
• US Executive Order 14028 requires federal software suppliers to provide verifiable provenance, and the EU Cyber Resilience Act imposes similar build-integrity obligations on software sold in the EU.
• California SB 942 (the AI Transparency Act) took effect in January 2026, with the New York Stop Deepfakes Act and others following.
• The US CISA endorsed content credentials as a key countermeasure in a January 2025 advisory on multimedia integrity, recommending adoption by government and critical-infrastructure operators.

If you ship software to governments, or produce AI-generated content for public distribution, or handle regulated data, provenance is no longer optional — it’s an audit item.

The five primitives behind all of it

Here’s the unifying insight for developers, and the reason this is one post and not three unrelated ones: whether you’re vouching for a container image, a dataset, or a photograph, the cryptographic machinery is the same. A provenance system is built from five primitives stacked together.

1. Cryptographic hashing. A digest (e.g. SHA-256) of the artifact is its tamper-evident fingerprint: change one byte and the hash changes. This is how integrity is checked — the digest is the artifact’s identity.
2. Digital signatures. A key (tied to an identity) signs the digest, binding who vouches for this to exactly this artifact. A valid signature means an identity stood behind this specific bytes.
3. Attestations / manifests. Signed metadata that makes claims about the artifact — how it was built, which tools touched it, what edits were applied, what model generated it. This is where “provenance” becomes rich rather than just “unchanged.”
4. Chain of custody. Linked records connecting the artifact from its origin through every modification to its current state, so the whole history — not just the latest step — is verifiable.
5. Transparency logs. A tamper-evident, append-only public ledger (the model Sigstore’s Rekor uses) records signing events, so tampering or backdated claims can be detected even if a key is later compromised.

Stack these and you get the property that matters: anyone can independently verify origin and integrity, without trusting an intermediary. That independent verifiability is what separates real provenance from a metadata field anyone could fake.

The honest framing, set up front

One caution belongs at the start, not buried at the end, because it’s the most misunderstood point about provenance: provenance certifies history, not truth. A provenance record can prove that a specific tool signed a specific artifact and that it hasn’t been altered since. It cannot prove that the claim made is true — that the camera was pointed at what the caption says, that the dataset was collected ethically, that the code does what it claims. Provenance establishes that a claim was made and the artifact wasn’t tampered with afterward. It provides transparency, not judgement. Build with that boundary in mind and provenance is powerful; forget it and you’ll over-trust a green checkmark.

Why SBOMs aren’t enough

Start by clearing up a common confusion, because many teams think they’ve solved provenance when they’ve only solved inventory. A Software Bill of Materials (SBOM) tells you what’s inside an artifact: “this build contains these components at these versions.” The 2021 US Executive Order’s SBOM mandate did the industry a real service by forcing teams to actually know their dependencies.

But an SBOM has a hard scope limit: it doesn’t tell you whether the artifact was built from the code you think it was, or whether the build process itself was compromised. That’s exactly the gap SolarWinds and GhostAction exploited — the components were “legitimate,” but the build was subverted. As the post-GhostAction consensus puts it: SBOMs tell you what’s inside; provenance proves where it came from and how it was built. Large buyers increasingly demand both. SBOM is the ingredient list; provenance is the tamper-evident seal and the factory record.

Build provenance with SLSA

The framework that defines build provenance is SLSA — Supply-chain Levels for Software Artifacts (pronounced “salsa”), a vendor-neutral OpenSSF project. SLSA answers a precise question that SBOM, VEX, and the NIST SSDF don’t: is the artifact a consumer received the same artifact a build system produced from a specific source under documented controls?

It’s structured as a maturity ladder, which makes adoption incremental rather than all-or-nothing:

• Level 1 — provenance exists: the build emits a description of how the artifact was made. Not tamper-resistant yet, but you have a record.
• Level 2 — provenance is signed and produced by a hosted build service, so tampering is detectable.
• Level 3 — provenance comes from a hardened, isolated build with verified source control, resistant to forgery even by a determined insider.

The provenance itself is a SLSA provenance predicate wrapped in an in-toto attestation (in a DSSE envelope) — capturing builder identity, build instructions, parameters, and dependency digests. In practice it’s a JSON document the build platform writes per release and a verifier reads to make a trust decision:

{
  "_type": "https://in-toto.io/Statement/v1",
  "subject": [{ "name": "my-artifact", "digest": { "sha256": "abc123..." } }],
  "predicateType": "https://slsa.dev/provenance/v1",
  "predicate": {
    "buildDefinition": {
      "buildType": "https://github.com/slsa-framework/slsa-github-generator",
      "externalParameters": {
        "repository": "https://github.com/org/repo",
        "ref": "refs/heads/main"
      }
    },
    "runDetails": { "builder": { "id": ".../generator_generic_slsa3.yml" } }
  }
}

The subject.digest binds the attestation to one exact artifact (primitive #1), and the predicate is the attestation of how it was built (primitive #3).

Keyless signing with Sigstore

The signing layer (primitives #2 and #5) is where Sigstore has become the de-facto standard, because it removed the worst part of signing: key management. Its three components:

• Cosign — signs and verifies container images and artifacts.
• Fulcio — issues short-lived certificates tied to an OIDC identity (your GitHub, Google, or workload identity) instead of a long-lived key.
• Rekor — a transparency log that records every signing event.

The magic is keyless signing: you authenticate via OIDC, Fulcio issues an ephemeral certificate bound to that identity, you sign, and the event lands in Rekor — no long-lived private key to store, rotate, or leak. This is why Sigstore adoption spread fast across npm, PyPI, and Kubernetes. (One caution from practitioners: don’t quietly fall back to long-lived static keys without a rotation plan — that reintroduces exactly the risk Sigstore removed.)

The verification gate: “no provenance, no deploy”

Generating provenance is worthless if nothing checks it. The payoff comes at the verification gate, where cloud registries and admission controllers enforce a simple policy: no valid provenance, no deploy. The full pipeline looks like this:

The verification logic is small but decisive, applied to build integrity:

def admit(artifact, provenance, policy) -> bool:
    # 1. integrity: provenance is bound to THIS exact artifact
    if provenance.subject.digest.sha256 != sha256(artifact):
        return reject("digest mismatch — not the artifact we verified")
    # 2. authenticity: signature verifies against a Sigstore identity in Rekor
    if not verify_signature(provenance, rekor=True):
        return reject("signature/transparency-log check failed")
    # 3. policy: built from the source and pipeline we expect
    if (provenance.repository, provenance.workflow, provenance.ref) not in policy.allowed:
        return reject("unexpected build source — possible tampering")
    return True   # only now does it deploy

Tooling makes each step turnkey: GitHub artifact attestations generate signed SLSA provenance from Actions; Red Hat’s Konflux issues in-toto attestations tied to policy; and GUAC (Graph for Understanding Artifact Composition) stitches provenance, SBOMs, and attestations into a queryable graph across your whole estate, so you can answer “where is this compromised dependency, and what did it build?” in one place.

A pragmatic adoption roadmap

The specifications are mature and the tooling exists, so the path is well-trodden: start at Level 1 by turning on provenance generation in CI (GitHub artifact attestations are the lowest-friction on-ramp); move to Level 2 by signing with Sigstore and recording in Rekor; target Level 3 for your most critical artifacts with hardened, isolated builds; and add the verification gate so unverified artifacts can’t promote to production. Regulation (EO 14028, the CRA) makes Levels 1–2 effectively table stakes for anyone selling software to regulated buyers.

The same primitives for data and AI models

Everything above is artifact-agnostic, which is why it extends naturally to data provenance. Recall the distinction: provenance (origin, authenticity, trustworthiness) versus lineage (flow and transformation). Apply the same primitives — hash the dataset, sign a manifest attesting its source and collection method, chain the transformations, log it — and you can answer “is this data what it claims to be?” with cryptographic confidence rather than a spreadsheet and good faith.

This matters most for AI, where two provenance questions are now business-critical. First, training-data provenance: what went into the model, and can you prove the rights, consent, and absence of contamination behind it — increasingly a legal and audit requirement. Second, model provenance: a model is itself a supply-chain artifact, so sign your model weights, treat the model card as an attestation, and verify model provenance before loading — the same way you’d verify a container image.

Why detection lost, and provenance won

The instinctive response to deepfakes is detection: build a classifier that spots fakes. That’s a losing battle. Generative models improve continuously, so any detector is perpetually one model version behind, and analysts project synthetic content could reach up to 90% of online media. You cannot win by inspecting the pixels.

C2PA inverts the problem. Instead of detecting fakes after the fact, it proves authenticity at the point of creation. Content that carries valid credentials doesn’t need to be detected as real — it cryptographically proves its origin and edit history. The losing game (spot the fake) becomes a winnable one (verify the genuine). That’s why the US CISA endorsed content credentials as a key countermeasure in its January 2025 advisory on multimedia integrity in the generative-AI era.

C2PA Content Credentials: a nutrition label for media

The Coalition for Content Provenance and Authenticity (C2PA) — with over 6,000 members and affiliates as of January 2026 — produces the open standard now treated as the global reference. Its Content Credentials are often described as a “nutrition label” for digital content, and structurally they’re just primitives applied to a media file:

• Assertions — the claims: “captured by this camera,” “edited with Photoshop,” “generated by AI model X.”
• Manifest — a tamper-evident record of the creation history and every edit/transform applied.
• Signature — a cryptographic signature by the creator or tool, verifiable by anyone (primitive #2).
• Chain of custody — the full provenance chain from creation through all modifications to the current state (primitive #4), bound to the asset’s hash (primitive #1).

A verifier checks whether the manifest is well-formed, signed by a trusted source, and still bound to the asset. It’s the exact same model — signed, hashed, chained claims — applied to a JPEG instead of a JAR.

Adoption is real in 2026 (and uneven)

Content Credentials moved into production across the whole content pipeline:

• Capture: camera makers Leica, Nikon, and Canon sign at the hardware level; Canon moved C2PA-compliant capture into newsroom workflows. Devices like Samsung Galaxy S25 and Google Pixel 10 support it natively.
• Creation/editing: Adobe Content Credentials and Microsoft (auto-labelling AI content in Bing and Designer); Intel is working on chip-level signing.
• AI generation: OpenAI adds C2PA metadata to generated media and announced a layered approach with SynthID plus public verification; Google has SynthID verification live in Gemini and is expanding C2PA verification across Search and Chrome, with Content Credentials in Google Photos.
• Distribution: LinkedIn and TikTok display verification icons.

The weak point — and it’s the big one — is preservation. Most social and messaging platforms still strip embedded metadata, and uploads, screenshots, exports, and recompression frequently break it. As of 2026, signed content often arrives at the viewer with its credential gone. C2PA is a strong signal, not a guarantee, when used alone.

Watermarking and durable content credentials

The fix for stripping is defence in depth for media. Because metadata can be removed, you pair it with marks that survive transformation:

• Invisible watermarking (e.g. SynthID) embeds a signal into the pixels or audio that survives platform transfers, recompression, and many edits.
• Fingerprinting lets you match content against a registry even with no embedded data at all.

The emerging best practice — and what the EU Code of Practice specifies as multi-layer marking, mapping to a “Durable Content Credentials” architecture — is to combine C2PA metadata + an invisible watermark + (optionally) fingerprinting. Metadata gives you the rich, verifiable manifest when it survives; the watermark gives you a durable fallback when the metadata is stripped. No single layer is foolproof; the stack is what holds up in the wild.

The compliance mandate

This is where the regulatory clock becomes a concrete engineering requirement for anyone shipping AI features:

• EU AI Act Article 50, enforceable August 2, 2026, requires deployers to disclose AI-generated or manipulated content using both visible markings and machine-readable metadata — which is precisely the C2PA-plus-watermark stack.
• California SB 942 (AI Transparency Act) took effect January 2026; the New York Stop Deepfakes Act and others are arriving.

If your product generates or significantly manipulates content for public distribution, labelling it with durable provenance is now a legal obligation, not a nice-to-have. The compliance clock is already running.

The honest limits (read this before you trust a checkmark)

A responsible provenance implementation is defined as much by what it doesn’t claim as what it does. Four limits matter:

1. Provenance certifies history, not truth. This is the most acute for media. A credential proves a device signed a file and it wasn’t altered since — it cannot verify that the camera was pointed at what the caption claims, that the scene wasn’t staged, or that the content is used in good faith. A credential establishes that a claim was made, not that the claim reflects reality.
2. Metadata stripping is endemic. Until platforms preserve credentials end to end, expect them to vanish in transit — which is why the watermark layer isn’t optional.
3. Adoption is incomplete. C2PA is necessary but structurally insufficient in isolation; treat it as one signal among several, not proof.
4. Provenance can carry privacy risk. Identity assertions in a manifest can create surveillance exposure — who created what, when, where. Balance disclosure against the creator’s privacy, and prefer minimal or pseudonymous assertions where identity isn’t required.

Build with these in mind and you get genuine value; ignore them and you’ll either over-trust a green badge or leak creator identity.

The builder’s playbook, and the whole picture

For an AI or content product in 2026, the practical implementation is: sign at creation (embed Content Credentials), add a durable invisible watermark, verify on ingestion and display, surface the “nutrition label” in your UI so users can inspect provenance, and treat the result as a signal, not a verdict — combined with other context, never as sole proof of truth. For generative features specifically, labelling output this way is how you meet Article 50.

Software, data, and AI-generated content all rest on the same five primitives: hash the artifact, sign it with an identity, attest to its origin and history, chain the modifications, and log it so anyone can independently verify. Implicit trust is gone across all three domains for the same reason — fakes became free — and verifiable provenance is the replacement. As of 2026 it’s simultaneously a trust differentiator and a hard compliance requirement, and the engineering is mature enough that the question is no longer whether to adopt it but how fast.

The throughline for developers is a single habit: sign what you produce, and verify what you consume — whether it’s a container image, a dataset, a model, or a video. That habit, applied consistently, is what rebuilds trust in a world where nothing can be trusted on sight.