← Blog

Receipt chains as tamper-evident audit trails

John Kearney
toolsmethodology

Every decision an agent makes should be logged. That is uncontroversial. The harder question is: how do you know the logs have not been tampered with?

Standard logging writes entries to a file or database. If someone with access modifies an entry, there is no way to detect the modification unless you have an independent copy to compare against. For routine operational logging, this is acceptable. For safety-critical agent decisions, it is not.

We implemented receipt chains in Authensor to solve this. Every agent action produces a receipt. The receipt contains the action request, the policy evaluation result, the decision (allow or deny), a timestamp, and a SHA-256 hash of the previous receipt. This last field is what makes the chain tamper-evident.

The mechanism is the same as a blockchain, minus the distributed consensus. Each receipt's hash depends on the content of the previous receipt. If you modify any receipt in the chain, its hash changes. That change propagates forward because every subsequent receipt includes the hash of its predecessor. To make a tampered chain consistent, you would need to recompute every hash from the point of modification to the end of the chain. If anyone has a copy of any receipt's hash from after the modification point, the tampering is detectable.

We chose SHA-256 because it is fast, widely implemented, and collision-resistant for practical purposes. The hash computation adds negligible latency to the receipt creation process. On our test hardware, hashing a receipt takes under 0.1 milliseconds.

The receipt format is structured JSON with a fixed schema. Fields include: receipt ID, timestamp (ISO 8601), agent ID, action type, action parameters, policy ID, evaluation result, decision, previous receipt hash, and current receipt hash. The schema is versioned so that future changes to the format are backward-compatible.

For compliance, receipt chains provide evidence that cannot be retroactively fabricated. If a regulator asks "what decisions did this agent make last Tuesday," you can provide the receipt chain for that period and they can verify its integrity by recomputing the hashes. This is stronger evidence than log files because it has cryptographic integrity.

For incident response, receipt chains let you reconstruct the exact sequence of events that led to a failure. You can trace backward from a harmful action through every prior decision. The chain shows which policy was active, what the evaluation result was, and whether the action was approved or bypassed. This is essential for root cause analysis.

We also implemented chain anchoring, where we periodically write chain state to an external append-only store. This provides an independent verification point. Even if the primary receipt store is completely compromised, the anchored checkpoints let you detect that the chain has been modified.

The receipt chain implementation is part of the Authensor control plane. It runs automatically for every action that passes through the policy engine. No additional configuration is required. The receipts are queryable through the API for integration with monitoring dashboards and compliance reporting tools.