Proving an AI decision was not altered takes four mechanisms: an asymmetric signature over the record; a signing key the application cannot export, with a hardware attestation proving it; registration in a transparency log that returns an inclusion receipt; and checkpoints cosigned by a witness you do not control. Hash chaining alone proves nothing to anyone who does not already trust you.
Ross Jones — Founder, The Hopium Lab. Last modified 22 July 2026.
Twenty-four shipped products across fifteen sectors, several carrying evidence somebody else checks without trusting me. Architecture supports a conformity case and never confers one. Engineering, not legal advice.
What does non-repudiation actually require?
Non-repudiation is a legal outcome, not a cryptographic property, and the serious specifications say so themselves. RFC 9943 calls a Signed Statement non-repudiable in one narrow sense — it binds an Issuer to bytes — then concedes that registration only proves an Issuer produced the statement. Not that the claim is true. Not that the Issuer logged everything.
The legal lift comes from somewhere else. eIDAS Article 41(2) gives a qualified electronic time stamp a presumption of the accuracy of the date and time and of the integrity of the data bound to them. Article 41(1) does far less: it stops a non-qualified token being denied admissibility for being electronic, and nothing further. A presumption is a burden-shifting device. Cryptography narrows what has to be argued and never removes the argument.
United States practice has not moved either. Authentication still runs through FRE 901(b)(9) — evidence about a process or system, showing it produces an accurate result — and proposed Rule 707, whose comment period closed 16 February 2026, cannot take effect before 1 December 2027.
Who are you proving it to?
Three verifiers, three bars, and choosing the wrong one is where the budget disappears. Internal operations need detection, and a keyed chain in Postgres delivers it. An assessor needs a proof checkable offline against an export. Opposing counsel and a market surveillance authority need a presumption, which makes the timestamp authority a procurement decision.
The EU AI Act asks for none of this. Article 12 requires that a high-risk system technically allow automatic event logging; Article 19 floors retention at six months. Hashing, signing, anchoring and immutability appear nowhere in either text. Tamper-evidence is the gap between the compliance floor and the evidentiary bar, and the Regulation never asks you to close it. The obligation in detail is a separate note.
The commercial governance tier writes for none of the three. Kiteworks and Velt do name mechanisms — hash chaining, append-only writes, storage credentials separated from the writing system, periodic external attestation. The loop never closes. No page in the ranking set says who holds the signing key, or how a stranger checks anything without trusting the vendor.
An append-only claim from the party being audited is worth nothing on its own. The only question that matters is what a stranger can check, offline, while assuming you are the adversary.
Did the provenance standards arrive, or are they still drafts?
The provenance standards arrived in June 2026, and the commercial governance tier has not cited them once. RFC 9943 — Standards Track, formerly draft-ietf-scitt-architecture-22 — defines the Transparency Service, the Signed Statement, the Receipt and the Transparent Statement. RFC 9942 — Standards Track, COSE working group — registers COSE header parameters 394, 395 and 396 and profiles RFC 9162 Merkle trees with SHA-256. Only the API surface is unnumbered: draft-ietf-scitt-scrapi-11, 26 June 2026, in the RFC Editor queue post-IESG.
Citation trap, and currently the top organic result for "verifiable AI provenance". draft-ailex-vap-legal-ai-provenance-03 (2 March 2026, expires 3 September 2026) is an individual submission from AILEX LLC, trading as the "VeritasChain Standards Organization" — no working group, no RFC stream, no intended status, and boilerplate disclaiming IETF endorsement. draft-<surname>-* means somebody posted a document. draft-ietf-* means a working group owns the text.
Second trap. RFC 9162 is Experimental, and calling it what Certificate Transparency runs on is wrong in 2026. Chrome's log policy accepts RFC 6962 or C2SP static-ct-api v1.1.0, and since 15 April 2026 a certificate may qualify with SCTs exclusively from static-ct-api logs. Reach for RFC 9162 for the Merkle construction RFC 9942 profiles, nothing else.
Which mechanism proves what to a stranger?
Each mechanism proves exactly one thing, and the symmetric ones prove nothing at all to somebody who assumes you are lying.
| Mechanism | What a stranger can check offline | Where it breaks |
|---|---|---|
| HMAC or keyed hash chain | Nothing — verification needs the secret the operator holds | Rewrite record 5, recompute forward, every check passes |
| Asymmetric signature over the record | One key's holder signed those bytes, unchanged since | Silent on which key, absent a chain to a root the stranger trusts |
| Per-key HSM attestation | The key was generated inside that module and cannot leave it | Only where the platform emits one; otherwise the claim is your word |
| COSE Receipt (RFC 9942, header 394) | One record's inclusion in a named tree, without reading the rest | Inclusion in a tree, not the tree everyone else was shown |
| Witness cosignature (C2SP tlog-witness) | Append-only growth; equivocation becomes detectable | Witnesses you fund and run detect nothing |
| Qualified time stamp (eIDAS Art. 41(2)) | An interval before which the root existed, presumption attached | When the decision happened, or who held the data |
Where does the signing key have to live?
In hardware the application cannot export from, and — the part every governance page omits — hardware that will attest to that fact in a document you hand over. Google Cloud HSM issues a signed attestation statement per key version, chaining to Google and to the manufacturer (all Cloud HSM devices are Marvell, formerly Cavium). The key version's resource name appears in the 0x0102 key-ID field as a SHA-256 digest; extractability is a parsed field of its own, 0x0162. A stranger verifies that this key was generated in that module and cannot leave it.
AWS KMS makes the same claim from FIPS 140-3 Security Level 3 validated modules — plaintext keys never leave the HSMs and are never written to disk — and exposes no customer-obtainable per-key attestation. Only one of the two is evidence that fits in an export.
"Keys are in an HSM" is a sentence, not a control. The control is a per-key attestation a stranger can chain to a manufacturer root while assuming you are lying.
What stops a log serving two different histories?
Witness cosigning, and nothing else in the stack touches the problem. A correctly signed, genuinely append-only log can still serve an assessor one tree and everyone else another, every signature valid in both. A witness is a party that cosigns your checkpoint only after verifying it extends the checkpoint it signed previously; a checkpoint is the signed root, tree size and time for one epoch.
C2SP tlog-witness sets the mechanics. The witness must verify the checkpoint signature against the public keys it trusts for that origin, must persist the new checkpoint before responding, and should cosign using ML-DSA-44. The tlog-witness goal statement belongs in your threat model verbatim: "it must not be possible to partition clients from monitors."
Tamper-evident means modification is detectable afterwards, never prevented. Getting there without a chain and the domain-separation error that voids a Merkle proof are separate notes.
Does C2PA or an AIBOM prove a decision was not altered?
Neither C2PA nor an AIBOM does, and the reason is structural rather than a question of maturity. C2PA's integrity guarantee runs through a hard binding — a cryptographic hash of the asset bytes — so a manifest binds to a media artefact. A loan refusal, a triage recommendation and a tool call have no asset to bind to. C2PA 2.4 (April 2026) is explicit that it offers no judgement about whether provenance data is good or bad, only whether assertions validate. Correct for "this image came from a model". Useless for "this record is the one written at the time".
An AIBOM answers a third question: what was deployed. Two papers extend different base standards — arXiv 2510.07070 (Rajbahadur et al., ICSE-SEIP 2026) extends ISO/IEC 5962:2021, better known as SPDX; arXiv 2605.19755 (Radanliev et al., 17 March 2026) extends CycloneDX. Both describe a model and its lineage. Neither produces a per-decision record. A defensible case needs model identity, decision record and media provenance, and nothing published joins the three up.
How does the chain fail in production?
Five named ways, and cryptography is rarely the culprit.
- Symmetric self-attestation. An HMAC or a keyed chain verified with a secret the operator holds. Detection for you, evidence for nobody.
- Unattested custody. "Keys are in an HSM", no per-key attestation in the export. Custody rests on a vendor's compliance page.
- Split view. One tree for the assessor, another for everyone else, both internally consistent. Signatures cannot see it; a witness can.
- Dangling anchor. Anchors have operators and operators exit. Let's Encrypt made its RFC 6962 logs read-only on 30 November 2025 and shut them down on 28 February 2026.
- Ledger cargo cult. "Anchor it to a blockchain" without naming what it replaces. It replaces the timestamp authority, confers no Article 41(2) presumption and proves nothing about completeness.
What do you hand a verifier?
An export, a manifest, and checks that each fail on their own with no call home. Fork it.
# evidence-bundle.yaml — what a third party receives, and what they run.
# Every check must fail on its own, offline, assuming the operator is hostile.
bundle:
record: decision-record.cbor # Enveloped COSE, one decision
receipt: receipt.cbor # COSE Receipt, RFC 9942 header 394
checkpoint: checkpoint.txt # signed root + tree size + time
cosignatures: [witness-a.sig, witness-b.sig]
key_attestation: attestation.dat + chain/ # HSM-signed, per key version
timestamp: tst.der # RFC 3161 token over the root
checks:
- id: signature
verify: record validates under the public key whose key-version resource
name digests to the attestation's key-ID field
fails_if: algorithm is an HMAC or any symmetric MAC
- id: custody
verify: attestation chains to the manufacturer root; key-id digest matches
the signing key; extractability field says non-extractable
fails_if: custody rests on a compliance page rather than a per-key statement
- id: inclusion
verify: receipt proves the record is a leaf of the tree in checkpoint
fails_if: proof requires reading unrelated records to rebuild the root
- id: consistency
verify: checkpoint extends the checkpoint the witness signed previously
fails_if: two checkpoints share a tree size and differ in root hash
- id: witnessing
verify: cosigners are parties the operator does not run or fund, each
having verified the consistency proof before signing
fails_if: the witness set resolves to one legal entity
- id: time
verify: RFC 3161 token binds the root; genTime plus accuracy is an interval
fails_if: the record's own timestamp field is treated as evidence of when
completeness:
claim: none
reason: nothing here proves records were not withheld before registration
Deterministic replay is the other half — rebuild the answer without calling the model, or the record is decoration. What goes in each record is a separate note. Independence is an accredited property, held by conformity assessment bodies under ISO/IEC 17065 and ISO 42006. No vendor grants it to itself and I do not claim it: first-party tooling earns its place by needing nothing from its author at verification time. The Evidence Layer builds the bundle to fixed scope.
What is genuinely unsolved?
Completeness. Every record present can be proved authentic and unmodified; nothing proves that no record was withheld. RFC 9943 concedes it in its own security considerations — Issuers can refuse to register statements, or selectively submit some but not all of them. The same section concedes that a Transparency Service whose receipt-signing keys are compromised can roll back its statement sequence and issue fresh receipts under new credentials.
The AILEX draft advertises "completeness guarantees preventing selective logging". No working group has adopted it, no RFC stream carries it, and nothing in the published corpus delivers it. Extraordinary claim, ordinary document.
Trusted execution environments deserve one honest paragraph. A TEE can attest that specific code ran over specific inputs, narrowing the withholding window at generation. The side-channel record against TEEs is long and still growing. Scope them as hardening, never as the thing that closes the gap.
Three moves narrow the gap today. Register at generation rather than at export, so withholding means suppressing a call that already happened. Make the sequence number server-assigned, so gaps are visible rather than inferred. Hand the witness a monotonically increasing registration count, so a missing block becomes a number that does not add up. Partial, all three. Say partial.
Anyone selling completeness is selling the one thing the frontier has not built.