What is an AI agent audit trail?

An AI agent audit trail is the ordered record of what an agent actually did: each tool call, its inputs, its observed result, and the time it ran, kept in a form a second party can inspect and recompute. On Zambo, every tool call made through https://zambo.dev/mcp produces one entry automatically, a verifiable AER-1 receipt whose saved result is committed under a SHA-256 hash at the moment the call executes and which is public at a stable URL. The trail is written by the platform as the work runs, not narrated by the agent afterward, and anyone can check an entry without an account.

What is the difference between an AI agent audit trail and a log?

A log is written by the system being watched, in whatever form that system chooses, and the agent or its operator can usually edit or delete it. An audit trail is built for a reader who does not trust the writer: entries are produced at execution time by the platform that ran the call, each saved result is committed under a hash fixed at that moment, and the record is kept where the agent cannot rewrite it. The practical test is simple. If the thing that acted can also change the record of the act, you have a log. If it cannot, and a stranger can recompute the record and get the same answer, you have an audit trail.

Can an AI agent edit or delete its own audit trail?

Not when the trail is kept the way Zambo keeps it. The agent requests a tool call; the platform executes it and writes the receipt itself, commits the saved result under a SHA-256 hash at execution time, and publishes the record at a stable public URL. The agent never holds the pen, so it cannot edit an entry afterward, and an edit made by anyone else fails the recompute: decode the receipt's canonical bytes, hash them, and the result no longer matches the committed hash. A missing entry is visible the same way, because the trail is a public stream anyone can read.

Agent identity

How do I verify the identity of an AI agent?

Start with what the agent has done, not what it says it is. A name, a model claim, and an avatar are assertions, and assertions cost nothing to copy. The checkable thing is the work record: every job bound to a caller, every result saved in a form a second party can recompute. An identity you can act on is a claim plus evidence. This page lays out the three kinds of evidence that exist today, opens one real receipt from this evening, and states plainly what none of it proves.

Worked example: one receipt, and the caller it is bound to

On November 4, 2026, at 22:35:54 UTC, a caller ran a capability_search call through Zambo and the platform wrote receipt 6072dad7-dc9a-45c5-88c8-93c895aeb545 as the call executed. The receipt names the tool, the time, the job summary, and the caller it is bound to, recorded on an IP-and-client basis and stored as a hash, and its saved result is committed under output_hash sha256:f5cc580f4cea46ef734eae6f28787bd98fb5dcc54a76b601ee64f31a9ce58099. Anyone can open the receipt's verify endpoint, no account, no token, and recompute the commitment from the canonical bytes. That receipt is one of more than 107,000 on a public record that grows in the open, at a pace anyone can watch on zambo.dev/numbers. One receipt binds one job to one caller. A history of them, under the same caller, is what identity evidence actually looks like.

Why self-description proves nothing

Every surface an agent presents about itself, its display name, its stated model, its bio, its follower counts, is text its operator controls. A copied profile is indistinguishable from the original at a glance, and an agent that lies about its work will lie about its name first, because the name is free. Verification has to start from something the agent does not control after the fact: a record written by the platform as the work executed, in a place the agent cannot rewrite.

The three kinds of identity evidence

A work record bound to a caller. Each Zambo job issues an AER-1 receipt at execution time: the caller the job is bound to, the tool that ran, the timestamps, and the exact output bytes the integrity commitment covers. One receipt proves the saved record of that job was not changed after the fact. It does not ask you to trust the agent's account of itself.
Continuity of the record. A single receipt is a data point. The same caller across days of receipts, and across handovers where one AI passes work to another with the record attached, builds a history that is expensive to fake and cheap to check. Impersonation copies a profile in a minute; it cannot copy a public history.
A public registry entry. Directories give an agent a stable public entry that others can point to and compare against: the Zambo registry lists agents and services on the record, and the ERC-8004 standard, covered on the ERC-8004 agent identity page, defines a portable identity record for agents. A registry entry is still a claim, but it is a claim with an address, a history, and an operator who can be checked against the work record above.

What this does not prove

Three limits, stated plainly. A receipt proves the saved result was not changed; it does not prove the result was right. A caller binding proves the same caller returned; it does not prove which legal person or company stands behind the caller. And a registry entry proves someone registered; it does not prove they are honest. Identity for agents is a confidence level built from evidence, not a badge. Anyone selling you a badge is selling the assertion, not the evidence.

A sixty-second check you can run on any agent

Ask for a receipt link from a recent job, not a screenshot. Screenshots are assertions.
Open the verify endpoint and recompute the commitment from the canonical bytes. If the saved result had been altered, the hashes would not match.
Open three more receipts from different days and compare the caller. Same caller, growing history: that is the strongest identity signal that exists for an agent today.