Why LLM Audit Trails Need Cryptographic Chaining (Not Just Logs)

Logs and audit trails are not the same thing. This distinction matters when you need to demonstrate compliance, investigate an incident, or prove that an AI system did or did not take a specific action.

What a log gives you

A log is a timestamped record of events. It can be modified - a DBA can delete records, a compromised system can rewrite them. It has no internal consistency check. You cannot prove a log is complete.

What a cryptographic audit trail gives you

Each record in Autrace's audit chain includes the event data, the hash of the previous record, and the hash of the current record (computed from event data + previous hash).

// Record N-1
{
  "id": "entry_7f3a",
  "timestamp": "2026-04-15T14:22:01.003Z",
  "verdict": "ALLOW",
  "model": "gpt-4o",
  "prev_hash": "sha256:0000...0000",
  "hash": "sha256:8b3f9a2c..."
}

// Record N
{
  "id": "entry_8c4b",
  "timestamp": "2026-04-15T14:22:03.441Z",
  "verdict": "BLOCK",
  "policy_id": "no-pii",
  "prev_hash": "sha256:8b3f9a2c...",  // must match record N-1 hash
  "hash": "sha256:d7e1f5ab..."        // computed from this record + prev_hash
}

Tamper detection

To verify the chain: compute the expected hash of each record, compare to stored hash, verify prev_hash matches the preceding record's hash. Any modification breaks the chain at that record and invalidates all subsequent records. You can detect deleted records, modified records, and prove the sequence of events.

Compliance implications

SOC 2 Type II requires demonstrating security controls operated continuously during the audit period. A chained audit trail is verifiable evidence - you can prove no records were deleted or modified. A standard append-only log cannot provide the same assurance.