Cryptographic Audit Chains

Traditional logs can be edited, redacted, backfilled, or “fixed up” after an incident. Cryptographic audit chains make that visible.

Every record commits to the previous record using a hash link. Change anything, and the chain breaks. This is tamper-evidence—not tamper-proof, but tamper-evident.

The core idea

For each audit entry:

1. Compute a content hash (or a commitment like a Merkle root)
2. Link it to the previous entry’s hash
3. Write the combined hash as the entry’s identifier

The pattern:

$$\text{entry_hash} = H(\text{merkle_root} ;|; \text{prev_hash})$$

If anyone modifies an older entry—changes a timestamp, alters a decision, removes a field—every subsequent hash link breaks. The verify_chain() function returns ok: false, and you know the chain has been tampered with.

Why this matters

Without cryptographic chaining:

• Logs can be silently altered
• Audit trails depend on database access controls alone
• “We logged it” doesn’t prove the log wasn’t changed after the fact

With cryptographic chaining:

• Alterations break the chain and are immediately visible
• Verification is independent—any party with the chain can check it
• The audit record becomes evidence, not just a log entry

Adding signatures

Hash chaining detects tampering. Signatures add authorship.

When Hexarch signs an audit record, it proves: “This commitment was produced by the expected authority at this time.” A third party can verify:

• The record wasn’t altered (hash verification)
• The record was produced by the claimed signer (signature verification)

This is how you hand evidence to an auditor, a customer, or an incident review—and they can validate it without trusting your database.

Selective disclosure

You often can’t—and shouldn’t—disclose the full decision context. PII, internal identifiers, business logic.

Merkle proofs solve this. You can reveal specific fields while proving they were part of the committed record:

• Show the actor_id and decision without exposing the full request payload
• Prove a field existed without revealing its value
• Satisfy compliance requirements without leaking sensitive data

The proof is verifiable: the partial reveal hashes back to the committed root.

Verification in practice

The Guardrails API provides:

• GET /audit-logs/verify — returns ok: true if the chain is intact
• verify_chain() in the SDK — programmatic verification

If verification fails, investigate. Something changed. The chain doesn’t lie.

Try it

• Proof Demo — trigger decisions and export evidence artifacts
• Proof Bundle Demo — selective disclosure and Merkle verification

Next steps

• Unverifiable Policy Logs — the problem cryptographic chains solve
• API Reference — verification endpoints
• Proof Demo Guide — step-by-step walkthrough