The session summary problem
Sessions are the wrong unit for accountability. A session mixes forty calls into one narrative, and the narrative is produced by the same system whose work is in question. Steps that failed quietly get narrated as completed. Results that were never observed get reported as facts. Even an honest summary cannot help: it describes the work from inside the work.
Calls are the right unit. A call has a definite input, a definite observed output, and a definite time. Recorded individually, calls can be counted, sampled, recomputed, and matched against claims. That is the difference between auditing and interviewing.
What one call's record should hold
- The tool and the inputs, exactly as sent, not paraphrased.
- The output the system observed, saved as the result of record.
- The time the call ran.
- A digest over the saved result, so any later change to the record is detectable by recomputation.
- A stable address where a reviewer can open the record without the producer's account or permission.
That is the AER-1 receipt shape: every Zambo tool call, in Claude, ChatGPT, Gemini, Cursor, or any MCP client, leaves one automatically, at a public URL, in the format IETF Internet-Draft draft-zambo-aer1-23 defines.
Two call records from today, open them
Real records, not screenshots
The public demo ran a prompt_shield check this morning and left receipt 91e376b1, saved 2026-10-18T11:36:51Z. A routine system heartbeat left receipt 5604e79b the same morning. Open either, read what the call was and what it returned, and check it at the public verifier. An audit trail you cannot open is a claim, and these are the opposite of claims.
Run the audit after the fact
- Pull the call records for the period, in order, from the receipts rather than from the session list.
- Recompute a sample, or all of them. Each digest either matches its saved result or it does not. Mismatches are findings, not rounding errors.
- Match claims to calls. Take the report the AI produced and find the call behind each factual claim. A claim with no call behind it is labeled unproven.
- Write up the gaps with the passes. Missing calls, failed calls, and calls nobody can explain go in the same document as the verified ones.
The zambo.dev audit trail pages cover how the records roll up to the session level when you need the wider view. The per call record stays the ground truth underneath.
Not a spend audit
Teams also audit LLM calls for money: tokens in, tokens out, cost per workflow. That audit matters, and it answers a different question. A spend audit can tell you a call was expensive. Only a work audit can tell you what the call did, what it returned, and whether the report built on it is standing on a real result. When the question is accountability, a client dispute, a compliance review, an incident, the spend ledger is the footnote and the call record is the evidence.
Put today on the record
The cheapest audit is the one you never have to reconstruct. Run today's work through Zambo and every call leaves its record as it happens, free to start, no account needed for the public trail. A $0.99 Day Pass covers a full day of work at full volume: tonight, the audit is a read, not an excavation.
Questions, answered
What is an LLM call audit?
An LLM call audit is a review of AI work at the level of individual calls. Each call keeps its own record: the tool, the inputs exactly as sent, the output the system observed, and the time, bound by a digest over the saved result so a later edit is detectable. The audit recomputes those digests, matches the claims in any report against the calls behind them, and labels claims with no call behind them as unproven. It replaces the session summary, written by the AI about itself, with records made when the calls ran.
Is there a way to audit LLM tool calls?
Yes. Route the calls through a layer that records each one as it happens. On Zambo, every tool call made by Claude, ChatGPT, Gemini, Cursor, or any MCP client leaves a verifiable AER-1 receipt at a public URL, holding the tool, the inputs, the observed output, and the time. Auditing later is then mechanical: pull the receipts for the period, recompute the digests, and match claims to calls. Calls made outside a recording layer cannot be audited afterward, which is why the recording has to happen during the work, not after a dispute starts.
What should one call's audit record contain?
Five things: the tool that was called, the inputs exactly as sent, the output the system observed saved as the result of record, the time the call ran, and a digest over the saved result so any later change shows up on recomputation. It also needs a stable address where a reviewer can open it without the producer's account. Records missing the digest can be edited silently. Records missing the observed output audit the intention instead of the work.
How is an LLM call audit different from a spend audit?
A spend audit tracks tokens and cost: which workflows burn budget and where the waste is. A call audit tracks work: what each call did, what it returned, and whether the claims built on it hold. Both are worth running, and they answer different questions. When the question is accountability, a dispute, a compliance review, or an incident, the call record is the evidence and the spend ledger is context.
What does an LLM call audit not prove?
It does not prove the work was correct. A call can be perfectly recorded and still return a wrong answer, and the audit will show the wrong answer arriving, intact. What the audit proves is that the record is complete for the calls that ran through it, that the saved results were not changed since they were saved, and that every claim in a report either traces to a call or is labeled unproven. Correctness is judged by the reader, standing on a record that cannot be quietly rewritten.