Most audit logs are trusted because people assume nobody edited them. That assumption is the weak point. A log stored in an ordinary database table can be changed by anyone with enough access, and an edited log looks exactly like an honest one. Tamper evidence replaces the assumption with a check you can run.
How a hash chain works
A hash function turns any piece of data into a short fingerprint. Change a single character of the input and the fingerprint changes completely, and there is no practical way to find a different input that produces the same fingerprint.
A hash chain uses that property in sequence. When the system writes a new log entry, it computes the fingerprint of the entry's contents together with the fingerprint of the previous entry, and stores the result with the new row. Each entry is now tied to everything that came before it.
To verify the log, you walk it from the first entry to the last and recompute every fingerprint. If someone edited an old entry, its fingerprint no longer matches, and neither does any fingerprint after it. If someone deleted an entry, the next one points at a fingerprint that is no longer there. Either way, the break shows exactly where the record stopped being trustworthy.
What tamper evidence does not do
It does not prevent tampering. A person with direct database access can still change a row. What they cannot do is change it without the chain breaking, unless they also recompute every fingerprint after it, which is why strong designs also copy the latest fingerprint somewhere the attacker cannot reach, such as an export kept by the customer.
It also does not make the log complete. A chain proves that the entries you have were not altered. It cannot prove that the system recorded every action in the first place. Completeness comes from design: every sensitive action, including permission changes, exports, and deletions, has to write to the log.
How it works in Atlas
The Atlas audit log records every change in a workspace with the person who made it, the action, the target, and the values that changed, and actions taken by AI agents are recorded the same way. The log is hash-chained, and administrators can run a Verify chain check from the audit log settings, which re-walks the chain and confirms every row matches its computed fingerprint. Contract signing has its own hash-chained audit trail and a completion certificate. You can see the audit log in the Atlas product tour. Audit logs are on paid plans.
As with every control described on this site, this is a product feature rather than an audit: wrxstack holds no SOC 2 or ISO 27001 report today.
Questions to ask any vendor
Is the log append-only for administrators too? Is it hash-chained, and can I run the verification myself? Which events does it record, and does it record agent actions? Can I export it, so a copy lives somewhere the vendor cannot change? The answers tell you whether the log is evidence or decoration.
What is a tamper-evident audit log?
A log in which each entry is linked to the previous one by a cryptographic fingerprint, so any edit or deletion breaks the chain and can be detected by re-checking it.
Is tamper-evident the same as immutable?
No. Immutable means the data cannot be changed. Tamper-evident means changes can be detected. Most practical systems aim for tamper evidence, backed by exports kept outside the system.
Can I verify the Atlas audit log myself?
Yes. Administrators can run Verify chain from the audit log settings, which recomputes every fingerprint and reports whether the chain is intact. Audit logs are on paid plans.
Does a hash chain prove the log is complete?
No. It proves the recorded entries were not altered. Completeness depends on the system writing every sensitive action to the log in the first place.
Where this lives in wrxstack: security at wrxstack and Atlas for enterprise.