← Blog
Security·Matheus Pavaneli

What makes an audit trail actually tamper-evident

A log you can edit is not evidence. Here's what hash-chaining, atomic commits, and append-only guarantees really buy you — and how Seal enforces them.

Most "audit logs" are just a table someone can UPDATE. That's a record, not evidence. If the history of who approved what can be quietly rewritten, it proves nothing.

The direct answer

An audit trail is tamper-evident when every entry is hash-chained to the one before it, written atomically with the state change it records, and stored append-only with no update or delete path. Any change to a past entry breaks the chain and is detectable.

Hash-chaining, briefly

Each event includes a hash of the previous event. Alter an old entry and every subsequent hash no longer matches — verification catches it immediately. You don't have to trust the storage; you can check it.

Atomic by co-commit

A decision and its audit record must land in the same transaction. If they don't, you get drift: a status with no explanation, or an audit entry for a change that rolled back. Seal co-commits them, so that gap can't exist.

Append-only, enforced twice

The log has no update or delete path in application code, and a database guard rejects mutation attempts outright. Append-only isn't a convention here — it's a property of the system.

Why it matters for agents

When an autonomous agent takes a sensitive action, "who approved this and when" is exactly the question you'll be asked later. A tamper-evident chain answers it with proof, not with a table you hope no one touched.