AI Agent Audit Trails: Hash-Chained Receipts and Tamper Evidence

When an AI agent makes a decision, you need a record of what it decided, why, and what happened as a result. When regulators or auditors ask for this record, you need proof that no one has altered it. Hash-chained receipts solve both problems.

What Goes in a Receipt

Each receipt captures a single agent action:

• Action type: tool call, response generation, approval request, policy evaluation
• Input: what the agent received (user message, tool response, context)
• Decision: what the policy engine decided (allow, deny, require approval)
• Output: what the agent produced (tool call parameters, generated text)
• Metadata: timestamp, agent ID, user ID, session ID, model version
• Previous hash: SHA-256 hash of the immediately preceding receipt

How Hash Chaining Works

Each receipt's hash is computed over its own content plus the previous receipt's hash. This creates a linked chain:

Receipt 1: hash = SHA256(content_1 + "genesis")
Receipt 2: hash = SHA256(content_2 + hash_1)
Receipt 3: hash = SHA256(content_3 + hash_2)

To verify the chain, recompute each hash and confirm it matches. If any receipt has been modified, its hash changes, and every subsequent receipt's previous-hash field no longer matches.

This gives you two properties:

Tamper detection. Any modification to any receipt is detectable by anyone with access to the chain.

Ordering proof. The chain establishes a strict order of events that cannot be retroactively altered.

Storage

Store receipts in an append-only data store. Options:

• PostgreSQL table with row-level security that prevents UPDATE and DELETE
• Object storage (S3, GCS) with versioning and deletion protection
• Write-ahead log shipped to immutable archival storage

The storage layer should not allow the application to modify existing records. Even the admin should not have casual write access to the receipt store.

Verification

Build verification into your operational workflows:

• Continuous verification: A background process that periodically walks the chain and confirms integrity
• On-demand verification: An API endpoint that verifies a specific receipt and its ancestry
• Export for audit: Generate a portable chain verification report for external auditors

Practical Considerations

Performance. SHA-256 hashing adds microseconds per receipt. It is not a performance concern. The bottleneck is storage I/O, which you would have for any logging system.

Chain breaks. If the system crashes mid-write, the chain may have a gap. Handle this by writing the receipt atomically (transaction for SQL, atomic put for object storage) and rebuilding the chain tip on restart.

Multi-agent chains. In systems with multiple agents, each agent can maintain its own chain, or a central service can maintain a single chain across all agents. The single-chain approach is simpler to verify but creates a serialization bottleneck.

Authensor implements receipt chains in its control plane, generating a receipt for every policy evaluation with configurable storage backends.