Signed Receipts vs Trace Logs: The Agent Audit Trail That Actually Proves What Happened

Signed Receipts vs Trace Logs: The Agent Audit Trail That Actually Proves What Happened

When an AI agent runs on its own — calling tools, writing to a database, sending an email, moving money — you eventually have to answer one question: *what did it actually do?*

Most teams answer that with a trace log. Trace logs are great for debugging. They are the wrong tool for proof. The moment the question shifts from "why did my agent behave weirdly?" to "can you prove to me — a customer, an auditor, a regulator — that this is exactly what happened, unaltered?", a log line stops being enough.

That's the difference between a trace log you're asked to trust and a signed receipt you can verify.

What a trace log actually is

A trace log is an application writing down what it thinks it did. LangSmith, OpenTelemetry spans, a logger.info() in your agent loop — all the same category. The properties that matter here:

• It's produced by the same system it describes. The agent narrates its own history.
• It's mutable. A log line is a row in a table or a string in a file. Anyone with write access can add, edit, or delete it, and nothing about the remaining logs reveals that it happened.
• It has no independent authenticity. If you export a trace and email it to a customer, there is nothing in the export that ties it to the platform that generated it. It's text. Text can be typed.

For debugging, none of that matters — you trust your own logs because you have no reason not to. For an audit trail, all of it matters, because the entire point of an audit trail is to be believed by someone who has a reason *not* to trust you.

What a signed receipt adds

A signed receipt is a record of an action plus a cryptographic signature over that record, produced by a key the acting system controls. On [a2a cloud](/blog/the-cloud-wasnt-built-for-autonomous-ai-agents), every agent action emits an Ed25519-signed receipt. Concretely, a receipt binds together:

• What happened — the action, its inputs, and its result (e.g. post_tweet → HTTP 201; send_email → accepted by the mailbox; a tool call and the row it wrote).
• Who did it — which agent, under which scope. Agents on a2a act through [scoped grants](/blog/scoped-grants-agent-delegation), so the receipt records the *delegated authority* the action ran under, not just the fact that something ran.
• When — a timestamp inside the signed payload, not a mutable column beside it.
• A signature — over all of the above, using the agent's key.

The useful property is tamper-evidence. You can't quietly change what a receipt says, because the signature would no longer verify. You can't fabricate a receipt for an action that never happened, because you don't hold the key. And anyone you hand the receipt to can check it *without trusting you* — they verify the signature against the public key. The proof travels with the artifact.

That's the whole game: a trace log makes a claim; a signed receipt makes a claim you can independently check.

Where this stops being academic

Three situations turn "nice-to-have" into "the reason the deal closed."

1. A dispute. A customer says your agent did something it shouldn't have — charged them, emailed the wrong person, deleted a record. With trace logs, it's your word against theirs, and your logs are the ones you could have edited. With signed receipts, you produce a tamper-evident record of exactly what ran, under what scope, when. The conversation ends.

2. Regulation — EU AI Act Article 12. For high-risk AI systems, Article 12 requires automatic recording of events (logs) over the lifetime of the system, at a level that enables traceability of the system's functioning. The spirit is a record you can stand behind, not a debug stream you rotate out in seven days. Signed receipts are logging built for that spirit: durable, attributable, and tamper-evident by construction rather than by policy. When the requirement is *traceability you can defend*, "trust our logs" is a weak answer and "here is the signed, verifiable record" is a strong one.

3. A SOC 2 audit. SOC 2 is, in practice, a hunt for evidence that your controls actually operate. "We restrict what the agent can access" is a control; the auditor wants proof it held on every run. Signed receipts that record the scope each action executed under are exactly that evidence — generated automatically, per action, instead of assembled by hand from screenshots and log exports the week before the audit.

In all three, the common thread is the same: someone with a reason to doubt you is asking for proof, and a mutable log written by the system under scrutiny is not proof.

"Can't I just make my logs immutable?"

You can push logs to append-only or WORM storage, and you should — it raises the bar. But append-only storage proves *nobody deleted a row in this store*. It does not prove *this specific record was produced by that specific agent under that specific authority* — and it doesn't travel. Hand an immutable-store log to a third party and they still just have text, plus your assurance about where it came from. A signature closes both gaps at once: authenticity (who produced it) and integrity (it wasn't changed), in an artifact anyone can verify offline. The two are complementary — durable storage of signed receipts is the strong form.

Keep the trace logs

None of this means throw away tracing. Trace logs are the right tool for *understanding* your agent — latency, token spend, why a chain took a weird branch. Keep them. The point is that debugging and proof are different jobs, and most agent stacks only ship the debugging one. When the question is "prove what happened," you want a receipt, not a log.

How it works on a2a cloud

Every agent you deploy on a2a gets a managed Postgres database, an MCP server, an API, a frontend — and signed receipts for its runs, on by default. You don't wire up a signing pipeline; it's part of the runtime. We rely on it ourselves: [our entire go-to-market is an agent on a2a cloud, and every move it makes leaves a signed receipt](/blog/our-gtm-is-an-agent-signed-receipt).

If you're building something that will one day have to answer *what did it actually do* — to a customer, an auditor, or a regulator — start with an agent whose answer is verifiable:

• [Deploy a LangGraph Agent in 60 Seconds](/blog/deploy-langgraph-agent-60-seconds) — with Postgres, MCP, and signed receipts from the first run.
• [How to Give AI Agents Database Access Without Handing Over Production](/blog/give-ai-agents-database-access-without-handing-over-production) — scope the access, then have the receipts to prove it stayed scoped.