When a regulator, an auditor, or a court asks a firm to account for an automated decision, the question behind the question is always the same: can we trust this record? A log line that says a decision was made, in a system where any administrator could later edit that line, proves very little. The evidential weight of a record comes not from its existence but from the properties that make it hard to alter without detection. Those properties are cryptographic, and they are not exotic. This article walks through the building blocks of a tamper-evident decision certificate, vendor-neutral and from first principles, so that engineering and compliance teams can reason about what they are actually relying on.
The aim here is to explain the mechanisms, not any particular implementation. The techniques described are decades old, well understood, and standardised. What is new is the obligation to apply them to AI decisions at scale.
Tamper-evident is not tamper-proof#
The first distinction worth getting right is between prevention and detection. A tamper-proof record is one that cannot be altered at all. In practice, on general-purpose computers, true tamper-proofing is extremely difficult and usually overclaimed. Anything written to disk can, in principle, be overwritten by someone with sufficient access.
A tamper-evident record sets a different and more achievable goal. It does not promise that no one can ever change the bytes. It promises that if anyone does change them, the change becomes detectable. For evidence, detectability is what matters. A record whose integrity can be independently verified, such that any later edit would be visible to anyone who checks, is one a firm can stand behind. The whole of the rest of this article is about how detection is engineered.
Content hashing: a fingerprint for the record#
The foundation is the cryptographic hash function. A hash function takes an input of any size, the full content of a decision record for instance, and produces a fixed-length output, the digest, that behaves like a fingerprint. Modern functions such as those in the SHA-2 family have two properties that make them useful here. They are deterministic, so the same input always yields the same digest. And they are collision-resistant, meaning it is computationally infeasible to find two different inputs that produce the same digest, or to engineer an input that matches a given digest.
The practical consequence is powerful. If you record the digest of a decision at the moment it is made, anyone can later recompute the digest from the stored record and compare. If the two match, the content is byte-for-byte what it was. If a single character has changed, the digest will differ completely, and the alteration is exposed. The digest is small and cheap to store and publish, while the protection it provides covers a record of any size.
Hashing alone, however, only protects you if the reference digest itself cannot be quietly swapped. If an attacker can edit both the record and the stored digest, the comparison always passes. So hashing is necessary but not sufficient. The remaining building blocks exist to protect the digests.
Append-only chaining: making history rigid#
The next idea borrows from a technique long predating modern distributed ledgers: hash chaining. Each record's digest is computed not only over its own content but also over the digest of the record before it. The records form a chain, where every link depends on the one before.
This small change has a large effect. To alter a record in the middle of the chain, an attacker would have to recompute that record's digest, which changes the input to the next record's digest, which changes the next, and so on to the end of the chain. A single edit invalidates everything that followed it. The history becomes rigid: you cannot quietly rewrite the past without rewriting everything since, and the more activity that has accumulated since a given entry, the more expensive and conspicuous tampering becomes.
A refinement on the simple chain is the Merkle tree, where digests are combined pairwise up to a single root digest that summarises the entire set. A Merkle structure lets you prove that one specific record belongs to the set, by revealing only a short path of digests rather than the whole history. This is what makes large append-only logs efficient to verify: you can confirm a single decision's inclusion without re-reading millions of others.
Digital signatures: proving who, not just what#
Hashing and chaining establish that content has not changed. They do not, by themselves, establish who created it. For that you need a digital signature.
A digital signature uses asymmetric cryptography, a key pair where a private key signs and a corresponding public key verifies. The signer computes the digest of the record and encrypts it with their private key. Anyone holding the public key can decrypt the signature, recompute the digest from the record, and confirm the two match. Because only the holder of the private key could have produced a signature that verifies against the public key, a valid signature binds the record to its origin.
In an audit context this answers a question hashing cannot: this record was produced by the system that holds this key, and has not been altered since it was signed. It also provides non-repudiation. The signer cannot credibly deny having produced a record that verifies against their own published key. The integrity of the whole scheme rests on the private key being kept secret and the public key being reliably distributed, which is why key management, rather than the mathematics, is usually the hard part in practice.
Trusted timestamping: proving when#
There is one dimension the techniques so far do not pin down: time. A signed, chained record proves what was decided and by whom, but a system clock can be set to any value. For evidence, when a decision was made is often as contested as what was decided. A firm needs to show that a record existed at a particular time and has not been back-dated.
This is the role of trusted timestamping, standardised in the IETF's Time-Stamp Protocol, RFC 3161. The mechanism is elegant. Rather than trusting your own clock, you send the digest of your record, never the record itself, to an independent Time Stamping Authority. The authority appends its own trusted time, signs the combination, and returns a timestamp token. Because the authority signs the digest, it attests that this exact content existed no later than that moment, without ever seeing the content.
The result is a record whose age can be proven against an independent party. Combined with a hash chain, timestamping provides both relative ordering, the chain shows the sequence, and absolute anchoring, the timestamp ties the sequence to real-world time. Back-dating a decision now requires forging the signature of an external authority, which is a far higher bar than editing a local clock.
Putting the pieces together#
A defensible decision certificate is the composition of these layers, each closing a gap the others leave open. The content is captured as a structured record. Its digest is computed, giving a verifiable fingerprint. The record is chained to those before it, making the history rigid. It is signed, binding it to its origin and making alteration detectable. And it is timestamped by an independent authority, anchoring it in time. Verification runs the same steps in reverse: recompute the digest, check it against the chain, verify the signature against the published key, and confirm the timestamp token. If every check passes, the record is what it claims to be, made when it claims, by whom it claims.
What this composition does not require is trust in the firm that produced it. That is the point. The verifier does not have to take the firm's word that a record is genuine; they can check it themselves with public information and standard tools. Evidence that depends on trusting the party presenting it is weak evidence. Evidence that can be independently verified is the kind that holds up.
For teams building toward the logging and traceability obligations now arriving under the EU AI Act and the expectations of conduct regulators, these are the primitives worth understanding. The regulations rarely prescribe a specific cryptographic design, but they do demand records that can be relied upon long after the fact, and reliability, at this level, is built from exactly these parts.
Build on evidence you can prove.#
Request early access to Aegis Trace and our technical documentation.