Immutable audit log
An immutable audit log is an append-only record of system events in which each entry is cryptographically linked to the one before it, so no entry can be edited or deleted without breaking the chain. It provides tamper-evident proof of who did what, and when, across a system's history.
An immutable audit log works by hash-chaining: every time an entry is written — a login, a permission change, a resource deleted — the system computes a cryptographic fingerprint of that entry's contents together with the fingerprint of the entry immediately before it. That combined fingerprint is stored with the new entry, which means the next entry to be written will, in turn, hash against it. The effect is a chain of entries, each one mathematically dependent on everything that came before it, stretching back to the very first record in the log. No entry exists in isolation; its validity is provable only in the context of the whole sequence.
This is what separates an immutable audit log from an ordinary one. A conventional log file or database table can usually be edited or deleted by anyone with sufficient write access — restricting who holds that access is a policy, and policies can be misconfigured, bypassed, or overridden by an insider. Hash-chaining changes what tampering requires: altering or deleting one old entry invalidates the fingerprint of every entry written after it, so covering the change means recomputing the entire remainder of the chain, not editing a single row in isolation. That's still possible for someone with unrestricted access to the raw storage, which is why immutable logs pair hash-chaining with a way to check the chain against a reference the tamperer doesn't control — an exported copy, a periodic checkpoint, or storage that simply refuses to overwrite or delete. Either way, the question moves from who do we trust to does the chain still add up.
Why it matters
Audit logs exist to answer one question under pressure: who did this, and when. That's the question a security team asks during incident response, a regulator asks during a compliance review, and a court asks during a dispute. An ordinary log answers it only as long as no one had a reason to alter it — and the moment an attacker gains write access to a system, the log of their own actions is usually the first thing they modify or erase. A hash-chained log makes that harder to pull off cleanly: erasing a past entry means recomputing every fingerprint that follows it, and the result still has to match a reference the attacker doesn't control, so the tampering shows up the moment anyone checks. That property is what turns a log from a convenience into evidence.
How Sencai helps
Sencai keeps an append-only, hash-chained audit log of every action taken across every connected cloud account and every fleet-managed server — provisioning, configuration changes, access changes, all of it. Because the chain is continuous, answering "who changed this, and when" becomes a query against the log instead of a reconstruction project. Sencai doesn't hold ISO 27001 or SOC 2 certification, and says so directly; what it hands a security or compliance review instead is the underlying evidence, including an exportable audit trail, which is often closer to what such a review actually asks for than a certificate.
Explore security and compliance →