Append-only, tamper-evident: what a real audit trail looks like

For centuries, ships kept their logs in bound books: pages sewn into the spine, numbered in sequence, entries in ink, one after another, day after day. A dishonest captain could write a lie — nothing stops a pen. But he could not unwrite yesterday. Tearing out a page left a stub and a gap in the numbering. An altered entry sat there in different ink for any court of inquiry to see. The book did not make captains honest. It made dishonesty laborious and visible, which for legal purposes is nearly the same thing.

That is the entire design philosophy of a real audit trail. The cryptography is new; the idea is older than the steam engine.

Why editable logs fail exactly when you need them

An audit log exists for the day someone with power did something wrong — and that someone often holds the keys to the log.

This is the structural problem most "audit logging" quietly ignores. In a typical system, audit records live in a database table, and the people most worth auditing — administrators, engineers, executives under pressure — have credentials that can update or delete rows in that table. The log shares infrastructure, privileges, and management with the very activity it is supposed to witness. When an incident matters enough to investigate, the first question any serious investigator asks is could the log have been altered? — and for an ordinary editable log, the honest answer is yes.

An editable log is testimony, and testimony from the accused. What an investigation needs is evidence: a record whose integrity does not depend on trusting the operators, because the operators are inside the circle of suspicion by definition.

Append-only is a discipline, not a table setting

Append-only means the log supports exactly one write operation: add an entry at the end. Nothing is ever updated or deleted; corrections are new entries that reference the entries they correct.

Accountants have worked this way for over five hundred years. In a proper ledger you never erase a mistaken posting — you post a correcting entry, and both remain visible forever. The discipline survived because it produces something erasure cannot: a record of what was believed when, not merely what is believed now. The error and its correction are both facts, and both stay on the books.

The same discipline applied to a health-data platform means the log accumulates events, never states: this consent was granted, this query ran, this dataset was released, this consent was revoked, this correction was filed. Replay the events and you can reconstruct what the system knew and did at any moment in its history — which is precisely what a regulator, a court, or a patient deserves to be able to ask.

But append-only by itself is still a promise made by the operator. The database engine enforces it only as long as nobody with sufficient privilege decides otherwise. To turn the promise into a property, violations have to become visible. That requires cryptography.

Hash chains and Merkle anchors, minus the hype

Tamper-evidence comes from two moves: make every entry mathematically depend on everything before it, then periodically place a fingerprint of the whole chain beyond the operator's reach.

The chain. Each log entry includes a cryptographic hash of the previous entry. Hashes are one-way fingerprints: change a single byte of any past entry and its hash changes, which changes the next entry's content, which changes its hash, and so on to the end of the log. Falsifying one historical record now requires rewriting every record after it — the digital equivalent of re-sewing the ship's logbook and forging every subsequent page.

The anchor. A sufficiently privileged insider could still rewrite the whole suffix in place. So at intervals, the system computes a compact digest — commonly the root of a Merkle tree built over recent entries — and anchors it somewhere that cannot be quietly replaced: write-once storage, an independent timestamping service, a location other parties also hold. Now rewriting history requires changing what witnesses outside the system already have. That is what "cryptographically anchored" means: external witnesses to the chain's state, nothing more mystical than that.

Notice what is absent: no blockchain, no consensus, no tokens. The useful properties — append-only structure, hash linking, external witnessing — predate cryptocurrency and do not require it. Certificate transparency, the public log system that watches the issuance of TLS certificates for the entire web, is the existence proof that anchored Merkle logs work at internet scale.

One honest limit: tamper-evident is not tamper-proof. The design does not prevent a determined insider from trying; it guarantees the attempt is detectable. For evidence, that is enough — courts have never required logbooks that physically resist forgery, only ones where forgery shows.

What the law actually asks for

HIPAA's Security Rule requires audit controls and six-year retention of related documentation; it specifies the goal and stays silent on the cryptography.

The Security Rule's audit controls standard, 45 CFR §164.312(b), is one sentence:

Implement hardware, software, and/or procedural mechanisms that record and examine activity in information systems that contain or use electronic protected health information.

Surrounding provisions require policies and documentation to be retained for six years. The GDPR comes at the same need from a different angle: the accountability principle in Article 5(2) makes controllers responsible for demonstrating compliance, not merely achieving it — and the ICO applies the same expectation under UK law. A tamper-evident trail is the cleanest demonstration that exists: not a policy binder describing what should have happened, but a mathematical record of what did.

Note how low the legal floor sits. An ordinary editable log, dutifully retained, can arguably satisfy the letter of these texts. The reason to build above the floor is not compliance; it is that the floor was written for a world of filing cabinets, and the standard worth meeting is evidence-grade.

Log the no

The most telling entries in a real audit trail are the refusals — the query that was blocked, the consent that was revoked, the release that did not happen.

A trail that records only successes is a press release. The events that prove a system's promises are the negative ones: the moment a revocation took effect and future queries stopped seeing a record; the moment a cohort came back smaller than the k-anonymity floor and the gate said no. If those events are first-class entries on the same chain as everything else, the system's restraint becomes as auditable as its activity.

This is how Mithras Health builds it. The platform's audit trail is append-only and cryptographically anchored, with six-year retention; consent grants and revocations, every federated query, every release, and every k ≥ 5 refusal land on the same spine, and no role on the platform — including ours — can edit an entry after the fact. It is one expression of a broader conviction that protections should be apparatus rather than policy: a policy fails open under pressure, while a hash chain fails loudly.

The old courts of admiralty trusted ships' logs not because sailors were thought honest, but because the book made dishonesty visible. Five hundred years of ledgers and two decades of hash trees teach the same short lesson. Trust the people, by all means. But bind the book.