An audit trail you can actually prove

Every system has an audit log. Almost none of them can prove anything.

The problem is simple: if the log is a table, and the people you might one day need to investigate can write to that table, then the log tells you what happened unless somebody wanted it to say otherwise. That is not evidence. That is a diary.

What we changed

Each audit entry is hashed together with the hash of the entry before it. The hash covers a canonical form of the row — who, what, when, which record, and the entry's position in the sequence — using HMAC-SHA256 with a key that is not in the database.

Changing one historical entry therefore breaks the chain at that point and at every point after it. Deleting one does the same. Inserting one between two existing entries does too.

What that gives you

audit:verify walks the chain and either passes or names the first row that does not match. The answer is not "the log looks fine", it is "entry 41,208 has been altered".

The chain is sealed on a schedule rather than at write time, and that is deliberate: writing an audit entry must never fail because hashing failed. An entry is recorded first and sealed moments later, so the worst case is an unsealed tail, not a missing record.

What it does not do

It does not stop somebody with full database access from rewriting history. Nothing can. What it does is make the rewriting visible, which is the only guarantee worth offering. An attacker who edits a row has to either leave a chain that fails verification, or hold the sealing key as well — and the key is not stored alongside the data it protects.

Where you will see it

The portal's own activity log and the platform's operator trail both work this way. So does support access: when our staff enter your workspace, the reason, the operator and the duration are in your audit trail, not only in ours.