Tamper-evident, and you don't have to take our word for it.

How the chain works

The same construction as the CLI's own --audit-log, run server-side per write instead of per scan.

Each row in the export carries a SHA-256 hash computed, at the moment it was written, over its own fields plus the hash of whatever row came immediately before it in the service-wide log. Editing that row's content after the fact, without also recomputing its hash, is what this check catches. What it does not do on its own is prove nothing was ever rewritten by someone with write access to the log itself, or that a row from your organization was never silently dropped - see "what this does and does not prove" below before you call it "tamper-evident end to end" in your own compliance language.

Verify it yourself

Export your audit log as NDJSON from the Team/Enterprise portal's Audit page. Each line is one record, and every record already carries the hash of the record immediately before it in the service-wide log as one of its own exported fields - you do not need to fetch anything else to check it. The last line is a manifest stating the record count and the service-wide chain position at export time. Recompute each record's hash from its own fields (including that stored predecessor hash) and compare it to the record's own hash field - a mismatch means that record was altered since it was written. This confirms internal consistency of what you exported; it is not an externally anchored proof (see below). The exact byte-for-byte procedure and a runnable reference script (under 100 lines, stdlib only) are handed to every Team or Enterprise customer during onboarding, so your own engineers or auditors can run it without depending on us to vouch for it. Ask your account contact, or email us, if you have not received it.

What this does and does not prove

• Proves, assuming the log itself was written honestly (see below): every record present in your export is internally consistent with its own recorded predecessor hash, which catches that record's content being edited after the fact - and, checked alongside it, that no record was duplicated or reordered within the file by something naive.
• Does not prove, from the export alone: that no record was omitted before export, or ordering against a deliberate adversary rather than an accidental one. We re-run the full genesis-to-head verification continuously on our side; a stronger per-customer completeness proof (inclusion proofs) is a scoped addition we have not built yet because no customer has asked for it.
• Does not defend against: a compromise of our own service. Every hash here is computed and stored by us; someone with write access to the audit database could in principle rewrite recent history and recompute hashes so the result still looks internally consistent, because nothing anchors the chain outside the log itself. Closing that gap needs an externally published chain-head (a periodic customer-visible digest, a third-party notarization service) - we do not publish one today. Tell us if a compromised-operator threat model is in your compliance scope.