Do I need an audit trail, or are logs enough?
Logs are enough for your own debugging. They are not enough when someone else must be persuaded, because a log is the system's own account of itself. An audit trail adds the properties a checker needs: saved results fixed at execution, source states shown, and receipts a third party can recompute without your systems.
Start with what a log is: a record the software writes about itself, for itself. For operations, that is exactly right. When an agent misbehaves at 3 a.m., the log is how you find the step. The failure appears when the log is asked to do a second job: persuade someone who does not trust the system, a client disputing a delivery, an auditor sampling a project, an insurer reviewing an incident. To that reader, the log's author is the subject of the question.
The audit trail differs in four properties, not in volume. The saved result is fixed at execution, so the entry cannot quietly become a better story later. The entry names its producer and its tool. The sources behind the step show their states, resolved, not resolved, or not checked, so the trail includes its own doubts. And the record can be recomputed by a third party from a published format (AER-1, IETF Internet-draft-zambo-aer1-21), which is the property that turns a printout into evidence.
The decision rule is audience-based. If the only reader is you, logs suffice, and richer tooling is overhead. The moment a record must convince a client, an auditor, a regulator, or a future you who no longer remembers the job, you need the trail. Most working systems keep both: logs for the night of the incident, the trail for the morning after.
Checklist: the four-property audit test
Take any record your system keeps and ask: 1. Was the saved result fixed at execution, so it cannot be edited into a better story? 2. Does each entry name its producer and tool? 3. Do entries show source states, including not checked? 4. Can a third party recompute the record without your systems or your help? Four yeses: an audit trail. Any no: a log with ambitions. Score your current setup before your next client asks the question.
Worked example
Property 4 is testable in public: any receipt from a public handover, for example the job at https://zambo.dev/handover/45434a17-4afc-486a-9646-e689bcee4297 , can be recomputed at https://zambo.dev/verify/ by a reader with no account and no access to the system that produced it. That is the operational difference this page is about.
Frequently asked questions
Our logs are exported and timestamped. Is that an audit trail?
It is a stronger log. Export and timestamps help integrity in transit, but the entries were still authored by the system under question and cannot be independently recomputed. For internal review that may be plenty; for a skeptical third party it is the weak rung.
Do I need an audit trail for every agent, even internal ones?
Need follows audience. Internal automation whose output only you consume can live on logs. The trail is for work that leaves the building: client deliverables, regulated records, money movement, and anything an incident review would reconstruct.
Can I turn existing logs into an audit trail later?
You can summarize them into a report, but you cannot retroactively give entries the fixed-at-execution property. The trail starts when the recording does, which is why the decision belongs at setup, not at dispute.
By Brennan Zambo, founder of Zambo.
Last verified: 2026-10-17.
Try a handover
A handover gives your client one proof link with verifiable receipts to review, then Accept or Flag.
try it: say 'use zambo to hand this over to <client>' in your ai