Verifiable Transparency Logs for Model Provenance

A model trained honestly and a model quietly poisoned somewhere in its pipeline can look identical: same file size, same architecture, same weights arranged in a way that passes every conventional scan. The only thing separating a trustworthy model from a compromised one is the record of how it was made, and that record means nothing if someone can edit it after the fact. This piece looks at transparency logs that are cryptographically tamper-evident rather than just procedurally trusted, and what it actually takes to build one that holds up when someone tries to break it.

Modern AI systems get built from layers nobody fully controls. A team fine-tunes a pre-trained model pulled off a public hub, trains it on a dataset assembled by some third party, runs the whole thing through an automated pipeline stitched together from open-source libraries, and ships the result. Each layer is a place where something can go wrong quietly, without anyone noticing until much later, if ever.

Software dealt with a version of this problem already. A backdoor in source code can hide in a function nobody reads closely, but it's still text; someone with enough patience finds it eventually. A poisoned model works differently, and the difference matters. The gap between a clean model and a compromised one might be a subtle shift in a handful of weight values, invisible to reverse engineering and undetectable by the malware scanners built for traditional software. There's no equivalent of reading the code here, because the "logic" of a neural network is smeared across millions or billions of numbers that mean nothing on inspection.

So the open-source model ecosystem inherited software's core trust assumption (that transparency of artifacts builds trust) without inheriting the mechanism that made the assumption true in the first place. Source code is transparent because you can read it, and weights simply are not, no matter how carefully you squint at them.

That leaves the operational log as the last line of defense, and built the ordinary way, it's a weak one. Most training and deployment logs can be edited, deleted, or regenerated after the fact, which means they carry no evidentiary weight about what actually happened. OWASP's Top 10 for LLM Applications, in its 2025 edition, lists Supply Chain as LLM03 and calls out weak model provenance by name: no guarantees on the origin of the model. MITRE's ATLAS framework documents supply chain compromise as one of the primary ways attackers get initial access to AI systems. Neither of these is a hypothetical raised by cautious researchers in a conference room; both are documented patterns from groups whose whole job is tracking how these systems actually get attacked, and a log that can be silently altered is a claim dressed up to look like evidence.

What "verifiable" actually means here

People use "auditable" and "verifiable" as if they're the same word, but the gap between them matters more than it should. Auditable means a human can look at a record and form a judgment about it. Verifiable means something sturdier: a third party with no reason to trust whoever made the claim can independently confirm it's true. Most of what passes for "AI transparency" today is auditable at best, which is a lower bar than it sounds.

A transparency log, in the sense used here, is a cryptographically secured, append-only record. It captures who trained or published a model, when, and what the model contained at that moment. What makes it useful isn't the detail; it's that any outside party can check whether a specific model appears in the log by verifying a proof of inclusion, without needing to trust whoever runs the log. The trust lives in the math, and nobody has to take anyone's word for anything, which is the entire point and also, frankly, the part people find hardest to get used to.

The mechanism underneath most of these systems is a Merkle tree. Each entry contributes to a hierarchical structure of hashes, where every node is a function of the nodes beneath it. Change a single bit anywhere in that structure and the fingerprint at the top changes completely; there's no quiet edit that doesn't ripple upward and become visible. Tampering isn't just against the rules here; it's structurally detectable, which is a different and much stronger guarantee than a policy or an audit trail can offer.

The append-only design closes off the most obvious workaround: editing history after the fact. New entries get added, but nothing already in the log can be altered or removed without breaking the chain connecting it to everything after it. This defends against what's sometimes called a split-view attack, where an insider releases a quietly modified model under a legitimate signature, but only to certain users, betting nobody compares notes. If the log is public and append-only, that action shows up in the same record everyone checks, and there's no version of the story where it stays hidden.

Transparency research uses a traceability scale running from T0 (no traceability at all) up to T4 (independently verifiable provenance). Most enterprise AI deployments today fall well short of the highest tiers. That's a description of where the field stands, not a jab at any particular company, and it's why the rest of this piece spends so much time on what T4 actually requires instead of pretending it's already the norm. NIST's AI Risk Management Framework and its Secure Software Development Framework both name supply chain risk as a category worth worrying about. Neither one defines a cryptographically durable integrity guarantee for closing that risk. That gap between naming the risk and having a mechanism that resolves it is exactly the space transparency logs are built to fill.

Sigstore and Rekor: how the leading open-source implementation works end to end

Sigstore wasn't built for AI models originally, and that history is worth understanding. It solved the same problem for software artifacts, code signing, before anyone stretched the pattern over ML pipelines. That lineage matters, because the approach already got stress-tested against a related, more mature threat model before AI ever borrowed it.

Roughly how it works during a training run: the pipeline connects to Sigstore's Certificate Authority and requests a short-lived certificate, bound to an OpenID Connect token representing either a workload identity or a specific developer. That certificate lives just long enough to sign one model, and that narrowness is the design, not an accident; it shrinks the window of misuse dramatically. Even if someone compromises a credential later, it's already expired and useless to them. The signature and its certificate get written into Rekor, Sigstore's append-only transparency log. When the finished model gets uploaded to storage, the certificate and its proof of inclusion travel with it, attached as evidence rather than sitting off to the side as a separate claim someone has to take on faith.

Underneath, there's a three-layer structure doing distinct work: a Sigstore Bundle wrapped around a DSSE Envelope, wrapped around an In-Toto Statement. Each layer answers a different question: one handles integrity, making sure content hasn't changed; one handles authenticity, tying content to a verified identity; one handles transparency, making sure the whole transaction is discoverable in the public log. Together they cover the three things a provenance claim needs before it's worth anything at all.

In 2025, Google released the first stable version of its model signing library, built with NVIDIA and HiddenLayer under the Open Source Security Foundation. The practical effect: anyone deploying a model can verify the file they're running is exactly the one the developers produced, bit for bit, instead of trusting a filename or a checksum posted somewhere that could itself have been tampered with. A few months later, in August 2025, Google's Open Source Security Team published Rekor as a public dataset on BigQuery, an easily queryable mirror of the transparency log. Small change, large consequence: auditors no longer need to stand up their own log infrastructure to check whether a signing event happened, since they can query it the way they'd query any other dataset.

What does this actually stop? A rogue employee at a model provider can't quietly swap in a modified model and release it under the company's legitimate signature, because that signing event lands in a public log the instant it happens, and anyone can go check, not just the company's own security team. That's the split-view problem from the section above, addressed in a concrete, deployed system instead of staying a theoretical property on a whiteboard. This kind of signing is fast becoming the reasonable default for ML pipelines, and the SLSA framework, originally built for software supply-chain attestation, has stretched to cover AI-specific stages: training pipeline steps and fine-tuning lineage, not just the final artifact sitting at the end.

What the log needs to record: the AI Bill of Materials

A transparency log proves a record hasn't been altered since it was written, but it says nothing about whether the record was any good to begin with. That's a separate problem, one the AI Bill of Materials, or AIBOM, exists to solve.

The concept stretches the software world's SBOM, which lists the components and dependencies inside a piece of software, into AI-specific territory: model weights, references to the datasets used in training, learning rates, environment configurations, and the preprocessing steps applied before training ever started. Each field carries more weight than it looks like it should. In federated architectures especially, knowing which model got used isn't enough; you need the full conditions under which it got produced, because two models with identical architecture trained under different conditions can behave in wildly different ways.

One useful reference point is the Atlas framework, described by Spoczynski and colleagues in 2025, which shows what full-stack reproducibility capture actually looks like in practice: environment variables, container state, and granular dependency tracking. That's the granularity an AIBOM is meant to encode, not a high-level summary of what went into the model somewhere along the way.

By 2025 and into 2026, two formats reached genuine production maturity. CycloneDX ML-BOM, at version 1.7 and maintained under OWASP, is built for practical CI/CD automation; the OWASP AIBOM Generator produces it directly from metadata pulled off Hugging Face. SPDX 3.0's AI Profile carries ISO/IEC 5962 lineage, giving it more regulatory weight in procurement settings and lining it up with the structure of the NIST AI RMF. Neither format wins outright; they solve for different environments.

Here's the condition tying this section back to the last one: an AIBOM that isn't cryptographically signed or anchored to an immutable log is just a document, and documents get spoofed. An adversary can insert a malicious dependency into a manifest, or swap out a component reference, and nothing in the AIBOM format itself catches it. The AIBOM and the transparency log are interdependent parts of the same problem, not two competing approaches to it. One defines what should be recorded, and the other guarantees the record can't be quietly changed later.

Regulatory pressure on this front moved fast, in a narrow window. Within roughly six months across 2025 and 2026, CISA published minimum elements for AI-specific SBOMs, NIST referenced AIBOM principles in updates to its AI RMF, and ISO/IEC 42001's requirements around inventory, supplier governance, and change control lined up almost directly with what an AIBOM is meant to capture. Three unrelated bodies didn't land on the same idea by accident. The gap between what companies were tracking and what regulators expected them to track had gotten wide enough that it needed closing from several directions at once.

Extending provenance to model outputs: C2PA content credentials

Everything above answers one question: where did this model come from, and has its record been tampered with? It doesn't answer a related but distinct one: given a specific piece of content (an image, a paragraph, a video clip), what produced it, and what happened to it afterward? That's a separate layer of provenance, and it needs its own mechanism entirely.

C2PA Content Credentials fill that role. A Content Credential is a cryptographically bound structure embedded directly in a digital asset, recording its origin, any modifications made to it, and whether AI touched it at any point. Think of it as a manifest that travels with the file itself, rather than a claim published somewhere separate that could drift out of sync with the actual content over time.

This isn't theoretical. OpenAI embeds C2PA metadata in images generated by DALL·E 3, so any recipient can check, using tools built around the open standard, whether an image was AI-generated and what's happened to it since. In December 2025, the C2PA Specification reached version 2.3, adding support for live video streaming and for manifests attached to unstructured text. That's a meaningful expansion; earlier versions were built with media files in mind, and stretching coverage to real-time streams and plain text closes a gap that mattered more each year as LLM-generated text got harder to spot at a glance.

Government interest followed close behind. CISA's January 2025 advisory, "Strengthening Multimedia Integrity in the Generative AI Era," recommended that government agencies and critical infrastructure operators adopt content credentials as standard practice. That's a notable vote of confidence from an agency whose whole job is assessing what actually reduces risk, not what sounds good in a press release.

Put together, here's what a complete provenance chain looks like: the training log establishes what produced the model, the AIBOM establishes what the model actually consisted of, and the content credential establishes what that model, in turn, produced. Three links, each cryptographically bound to the one before it, and dropping any one leaves the chain with a gap wide enough to drive an attack through.

C2PA has limits worth naming plainly. It records which tool produced a given output; it doesn't reach back into that tool's training history. Model-level provenance and output-level provenance answer different questions, and neither substitutes for the other, no matter how tempting it is to treat one as covering for the gaps in the other.

Decentralized and cryptographic alternatives for higher-assurance environments

Sigstore's public log works because it's public. Wide, ongoing scrutiny is what makes tampering detectable in practice, not just in theory; a public log nobody's watching doesn't buy you much. So what happens in environments where publishing an open log isn't on the table at all, because the organization operates under classification requirements, competitive sensitivity, or regulatory constraints that make a fully public record a nonstarter?

Permissioned blockchain architectures step in here. Systems built on something like Hyperledger Fabric, integrated with TensorFlow Federated, record provenance at the level of individual training samples and individual model updates, using the same Merkle-tree hashing but storing only compact metadata on-chain rather than full datasets. This fits federated learning particularly well, where by design no single party controls the whole training process or holds custody of all the data, and a shared, tamper-evident ledger gives every participant the same guarantee without a central trusted authority sitting in the middle.

Simulation research from 2024 on blockchain-enabled audit systems found compliance readiness improving by more than half compared to traditional audit approaches. Worth being precise about what that number measures: it's a gain in audit transparency and process efficiency, not a standalone security guarantee. A poorly designed blockchain-based log can still fail, and the improvement is about how much easier compliance verification becomes, not a claim that the underlying system can't be broken.

Zero-knowledge proofs solve a different problem, one easy to overlook until it becomes urgent: how do you prove a model was trained on a specific dataset, or according to a specific procedure, without revealing that dataset or the model's weights to whoever's checking? For models trained on medical records, financial data, or anything else where publishing a full training log would itself be a privacy violation, this isn't an edge case; it's the whole design constraint. Researchers have demonstrated working zero-knowledge proofs for logistic regression and for neural networks, in work from Eisenhofer and colleagues in 2025 and Abbaszadeh and colleagues in 2024. Deep neural networks at production scale remain computationally expensive to prove this way, though; the technique is real and improving, not yet a drop-in fix for every model size out there.

One more thing belongs here, and it's easy to shrug off because it doesn't feel urgent yet: post-quantum migration. The digital signatures underpinning model lineage today, the ones Sigstore and similar systems rely on, sit on classical cryptography expected to become forgeable once sufficiently capable quantum computers exist. Model artifacts tend to have long operational lifetimes; a model signed today might still be running in production well past the point its signature scheme stops being considered safe. Organizations maintaining long-lived models need a migration plan toward post-quantum signature schemes now, not as a scramble later.

None of these (permissioned blockchain, zero-knowledge proofs, hybrid combinations layered with federated logging) amounts to a universal upgrade over Sigstore's public model. Which one fits depends entirely on the threat model in front of you: what you're protecting, who you don't trust, what you're not allowed to publish in the first place.

What the Foundation Model Transparency Index reveals about where the field actually stands

Stanford CRFM's Foundation Model Transparency Index is the most thorough annual attempt to measure, across the whole industry, how transparent model developers actually are about how their systems get built. The 2025 numbers tell a story running against the direction most people would guess.

The average score across evaluated companies fell sharply from 2024 to 2025. That's not a plateau; it's a fairly steep regression, happening at exactly the moment model deployment was accelerating across nearly every industry you can name. Transparency practices, in aggregate, are not keeping pace with how fast these systems are getting shipped.

Where does the opacity concentrate? Training data and training compute, specifically, which happen to be exactly the two categories a well-built provenance log is designed to make verifiable. The parts of the process companies are least willing to disclose are the same parts this piece has been arguing need cryptographic proof instead of a company's word. That's not really a coincidence.

The gap between best and worst performers is wide enough to sit with for a second. IBM scored near the top of the range in 2025, while xAI and Midjourney scored 14. That spread isn't explained by technical difficulty, since none of these companies faces a fundamentally different engineering challenge in documenting what they did. It reflects priority: some companies decided transparency was worth building toward, and some didn't bother.

A subtler finding, and maybe the more important one: DeepSeek scored 32 and Alibaba scored 26, despite both releasing open-weight models. That cuts against an assumption a lot of people carry into this conversation without examining it. Releasing a model's weights is not the same thing as publishing a verifiable record of how it got trained, and you can hand someone a file while still telling them nothing true about where it came from.

FMTI's evaluators flagged specific methodological gaps behind these low scores: limited involvement from independent third parties, low reproducibility of claimed results, inadequate reporting on overlap between training and test data. Read that list again; it reads almost like a checklist of exactly what a properly implemented transparency log, paired with a real AIBOM, would address directly. It's the same gap described from two angles: one from a research index measuring disclosure, one from an engineering standpoint describing what verification actually requires on the ground.

As of August 2025, the inability to verify a model's provenance stopped being purely a security concern and became a compliance one too. Regulatory frameworks are starting to attach real consequences to opacity, in a way market incentives alone never quite managed on their own.

What a real implementation actually requires

Here's a distinction worth holding onto: a tamper-evident log of an incomplete or inaccurate record proves nothing useful. Build the most cryptographically sound transparency system in the world, and you can still end up with something defensible on paper but not actually auditable in any way that matters, if what's going into the log isn't complete or accurate to begin with. The log is necessary, but it's not, by itself, sufficient, and a lot of teams stop right at "we have a log" and call the problem solved when it isn't.

So what does a genuinely complete implementation need, at the pipeline level? Signing has to happen at every material stage: dataset ingestion, the training run itself, any fine-tuning after, and deployment. A single signature applied only at the final step leaves everything upstream unattested, which defeats most of the point; an attacker who compromises an earlier stage just needs that final signature to go through cleanly. Environment reproducibility has to get captured alongside the model, following the Atlas framework's approach: container state, exact package versions, environment variables. A hash of the model weights without a record of the environment that produced them isn't fully reproducible, because identical weights trained under different conditions can behave differently in ways that matter later. And identity has to bind tightly to each signing event, using something like Sigstore's short-lived certificate model, so a signed artifact can never quietly get separated from the identity that actually produced it.

There's a formalized concept worth naming here: the AI Model Passport, described in 2025 research published through ScienceDirect. It's a structured, machine-interpretable identity and verification record for a model, built specifically to fill a gap human-readable documentation can't cover at scale. Documentation written for people to read doesn't scale to thousands of models moving through automated pipelines, while a passport format machines can parse and check does.

Technical implementation is half the problem. Governance is the other half, and it's easy to underinvest in because it never shows up in a system diagram. Who has authority to issue a signing identity, and what's the process for revoking it when someone leaves or a credential gets compromised? How long do logs need retention, and under whose jurisdictional rules? How do third-party auditors get access to query these logs without standing up their own infrastructure just to ask a question? The Rekor BigQuery dataset mentioned earlier is a genuinely useful model here: it makes a public log queryable by anyone, instead of forcing every auditor to run a copy of the infrastructure themselves.

The post-quantum migration question raised above isn't a someday problem. It belongs on today's checklist, because model artifacts signed under current schemes may need those signatures revalidated against post-quantum alternatives before the models' operational lifetimes actually run out. Waiting until the migration feels urgent means waiting until it's too late for some slice of what's already in production.

For models trained on sensitive data, meanwhile, privacy-preserving provenance can't be an afterthought bolted onto a finished system. Zero-knowledge proofs and selective disclosure mechanisms need to be part of the architecture from day one, so a provenance claim can get verified without exposing the training data the claim is actually about. Retrofitting privacy onto a system that wasn't built with it in mind tends to produce compromises nobody's happy with, and by then the cost of redoing it properly has gone up considerably.

What does all this add up to, when it works the way it's supposed to? A verifiable provenance system should let any authorized auditor reconstruct who trained a model, on what data, in what environment, at what time, and confirm nothing in that record got altered after the fact, all without taking the model's developer at their word. That's the floor, not the ceiling, and judging by where the Foundation Model Transparency Index says the industry actually sits, most of the field isn't there yet. The pieces (Sigstore and Rekor, the AIBOM formats, C2PA, zero-knowledge proofs) are already built and already running in parts of the industry today, though. What's missing in most organizations isn't the technology; it's the decision to put it all together and treat provenance as something that has to be proven, not just claimed and taken on faith.