AI agent execution receipt vs audit log vs trace

A factual guide for choosing evidence when an AI agent claims it completed work.

Audit logs, traces, and verifiable receipts are related, but they are not interchangeable. The right choice depends on who needs to inspect the record, how much context must be preserved, and whether the reviewer can access the original system.

What an audit log records

An audit log is a chronological record of events that a system considers important. A web application may record a login, permission change, data export, API request, approval, or deletion. An AI application can add model calls, tool calls, agent decisions, and workflow transitions. The log is valuable because it creates an operational history. Security teams use it to investigate incidents, administrators use it to review access, and compliance teams use it to show that a control produced a record.

Audit logs are usually designed around the boundary of one organization or service. Their quality depends on the logger, retention policy, access controls, clock handling, redaction rules, and protection against alteration. A log entry may identify an actor and event while omitting the full prompt, tool arguments, output, upstream evidence, or the reason a later action was taken. Some systems solve those limits with append-only storage, hash chaining, restricted write paths, and longer retention. Others keep a best-effort application log.

The honest limitation is simple: an audit log proves that the logging system recorded an event. It does not automatically prove that an external action happened, that the output was correct, or that an outside reviewer has seen the complete context. An internal log can still be exactly the right tool for internal accountability. It just should not be described as more independent or complete than it is.

What a trace records

A trace follows a request as it moves through a system. A trace can contain a root span for an agent request and child spans for model calls, retrieval, tools, queues, databases, and external services. Each span can carry a duration, status, attributes, and links to related work. Trace IDs make it possible to connect events that were produced by different services, even when the work was concurrent.

Traces are especially good at answering operational questions. Which tool was slow? Did a retry happen? Where did an error begin? How much time did retrieval add? Did the request fan out to several services? Engineers can use those answers to improve reliability and understand cost. Traces can also help a reviewer reconstruct a workflow when the instrumentation is complete and the trace remains available.

Trace systems have their own boundaries. Sampling may remove spans. Sensitive fields may be redacted. A trace can show that a request reached a service without proving that the service returned accurate data. The trace backend may require an account, a specific viewer, or access to the original project. Trace context can also be difficult to hand to a customer or another AI client in a stable, compact form. The trace is an excellent diagnostic view, but it is not automatically a portable proof object.

What a verifiable receipt records

A verifiable receipt is a focused record of one execution or one explicitly logged report. At minimum, a useful receipt identifies the execution, the tool or action, the time the record was created, and the observed result. It should expose enough canonical data or integrity material for a reviewer to check that the public record has not silently changed. A receipt can also link to provenance, an upstream response hash, a verification endpoint, or a recovery state.

The word verifiable matters. A receipt is not just a screenshot, a model sentence, or a database row hidden behind the original application. The reviewer needs a stable public or shareable identity and a clear description of what the record does and does not establish. If the system executed the tool itself, it can say that. If a gateway observed another executor, it should say that. If an agent merely reported an action, the receipt should not promote that report into proof of execution.

Receipts are not replacements for operational telemetry. They are selected evidence for handoff and review. A trace can contain hundreds of useful spans while a receipt points to the one completed result that a customer needs to inspect. An audit log can preserve organization-wide governance while receipts make selected work portable across tools and teams. The strongest architecture uses all three with explicit boundaries.

Comparison table

Named tools and receipt-category alternatives

How to choose

Choose an audit log when the primary question is accountability inside a system. Define which events matter, which fields are sensitive, who can read them, how long they remain available, and how integrity is protected. For an AI agent, include enough context to distinguish a proposed action from a completed action. A log should not silently turn a plan into an event.

Choose a trace when the primary question is behavior across components. Instrument model calls, tool calls, retries, queues, and external requests with a shared trace context. Keep sampling and redaction visible to reviewers. If a trace is later used as customer evidence, document which spans were retained and which claims remain outside the trace.

Choose a verifiable receipt when the primary question is whether another reviewer can inspect one result after the original interaction. Include the request, actual tool arguments, observed result, timestamp, executor or provenance class, and integrity information. State whether Zambo executed, observed, or only logged the action. Link to a live verification path and preserve a recovery path when the work is blocked or paused.

AER-1, XAIP, and AAR

These three names describe related but distinct work. AER-1 is Zambo's open draft for a portable AI agent execution receipt vocabulary and a live reference implementation. XAIP refers here to the IETF datatracker draft draft-xkumakichi-xaip-receipts-03, an individual Informational submission with a standards-process history, examples, and test-vector orientation. AAR refers here to Agent Execution Record, the receipt format in the apd project, which focuses on recording execution facts for comparison with an APD contract. The labels are not interchangeable, and none should be presented as a finalized universal standard.

The practical difference is the boundary each work emphasizes. AER-1 is useful when a reviewer needs a public receipt identity and a direct verification path. XAIP is useful when readers need to study an evolving, citable protocol proposal and its test-vector approach. AAR is useful when the central question is whether a runtime execution can be compared with an APD contract. A fair comparison keeps those strengths visible instead of treating one vocabulary as a substitute for the others.

These works can coexist in an evidence stack. A trace can explain service timing, an audit log can support internal governance, an AAR can express contract-related execution facts, and an AER-1 style receipt can provide a public handoff. A system should state which artifact it produced and which question that artifact answers. Reviewers should consult the source document for each vocabulary before claiming interoperability.

What none of these proves by itself

None of the three artifacts proves that an external business outcome occurred unless the artifact includes independently checked evidence for that outcome. A record that says an email was sent does not prove delivery. A tool result that says a trade was prepared does not prove settlement. A model response that says a file was changed does not prove the file changed. Evidence must match the claim.

None of these artifacts replaces authorization. A complete record of an unauthorized action is still a record of an unauthorized action. Human approval, identity, permissions, and policy checks remain separate controls. Likewise, an integrity hash can show that recorded bytes are stable. It cannot make an incorrect value correct or establish a fact that the system never observed.

The practical test is whether the artifact lets a careful reviewer separate four things: what was requested, what the system attempted, what it observed, and what still needs confirmation. That separation is more valuable than a confident label. It is also why a verifiable receipt should link back to the execution boundary instead of presenting itself as a universal guarantee.

FAQ

@misc{zambo_receipt_comparison,
  author = {Zambo},
  title = {AI Agent Execution Receipt vs Audit Log vs Trace},
  year = {2026},
  url = {https://zambo.dev/compare/},
  note = {Accessed 2026-09-23}
}

Last updated: 2026-09-23. This page describes evidence boundaries, not a guarantee of external outcomes.