Agent execution attestation: a claim with a record behind it.

An agent execution attestation is a statement that an AI agent executed a call: this tool ran, on these inputs, and produced this result. On its own, the statement is only as strong as whoever made it. Zambo is the verifiable work layer for AI, and its answer is to make the attestation a record instead: every call leaves an AER-1 verifiable receipt that binds the inputs, the saved result, and the provenance class under digests any receiver can recompute. A receipt proves the saved result was not changed since it was saved. That narrow, checkable claim is what an attestation worth relying on is made of.

Worked example: one attestation, checked end to end

Receipt 3f724778-aaff-4b6f-b5fc-8079cd7fc711 records a live_price call made on October 15, 2026 at 22:02:51 UTC, provenance class EXECUTED BY ZAMBO. The recorded inputs, the single field symbol set to BTC, are committed under input hash sha256:f4a0911390334f5fb4042fc3ebdec2a0cebc5bb3862bdbb6b2ec0ecb9231be26. The saved result reads BTC $82,343.00 USD, up 0.82% in 24 hours, and it is committed under output digest sha256:8f505a0d8c021d9df85fce3a35c1580fde3d9db249cd25c1c9de15a362d6ac4b. The public verify endpoint recomputes the digest from the saved bytes and reports the commitment check as a pass, expected hash equal to computed hash, with the provenance and metadata bindings also passing. You can rerun the same check at the public verifier and reach the same answer, without an account and without asking whoever ran the call.

Notice what the attestation adds and what it does not. The provenance class names who stands behind the call, and the digests bind that claim to these exact inputs and this exact result. The check does not judge whether the price was a good price or live_price was the right tool. It shows you the saved result, intact, attributed, so your judgment runs on the actual record instead of on a summary of it.

Try it on a fresh call: the live demo runs one real call and hands you its verifiable receipt, no signup.

Published October 15, 2026. Updated October 17, 2026. Written against AER-1, IETF Internet-Draft revision 23: draft-zambo-aer1-23. AER-1 is an IETF Internet-Draft, not a finalized standard.

Agent execution attestation

What the word usually means, and why it is not enough. An attestation is a statement by a party: the platform, the operator, or the agent itself asserts that work was executed and a result came back. Attestations assign responsibility, and a named attester can be held to their statement. But nothing in a bare statement lets a receiver recompute anything. A false or careless attestation is indistinguishable from a true one, because the only evidence offered is the attester's word, and the attester is the party being checked.

What the word means here. In the AER-1 sense, the attestation is carried by the verifiable execution receipt itself: minted at execution time by the system that ran the call, carrying the recorded inputs, the saved result, and the provenance class, each committed under SHA-256 digests, at a public URL. Whether the agent runs in Claude, ChatGPT, Gemini, Cursor, or Grok, the receiver's check is the same mechanical one: recompute the digests, compare, read the saved result. The attester's honesty stops being the load-bearing part, because the verdict comes from the bytes. If a so-called attestation ships no record behind it, call it what it is: a claim.

Scope, stated once and applied everywhere on this page: a verifiable receipt proves the saved result was not changed since it was saved. It does not prove the result was correct, and it does not prove an external event happened beyond what the record itself shows.

What an attestation has to bind

An attestation that binds nothing specific attests to nothing in particular. A complete agent execution attestation binds, at minimum:

  • The recorded inputs. The exact inputs the call ran on, committed under an input hash, so the attestation cannot quietly migrate to a different request later.
  • The saved result. The output as it was saved at execution time, committed under an output digest. This is the commitment the receiver recomputes.
  • The provenance class. The label that says who ran or reported the action. This is where the attestation lives inside the record: a declared, checkable part of it, bound to the result it describes.
  • The tool. The tool name, its version, and its scope, so the record says what executed, not just that something did.
  • The moment and the position. The execution timestamp, and, when the call is one step of a larger job, the receipt's position in the run's ordered step sequence, whose digests fold into the workflow's hash chain and root.

Bind those five and the attestation stops being a vibe. It becomes a set of commitments, each of which a receiver can test without permission, an account, or a relationship with the attester.

A statement versus a record

Attestation answers who; the receipt answers what. The provenance class tells you who stands behind the work, which matters: responsibility has to land somewhere, and a record with no provenance is an orphan. But who is only half the question. The other half is what exactly ran and what exactly came back, and that half cannot be settled by a statement, only by a record whose commitments recompute.

Ask for both, in one artifact. The attestation without the record asks you to believe. The record without the attestation gives you bytes with no one accountable for them. The AER-1 receipt carries the provenance class inside the committed record, so the statement and the evidence travel together and neither can be swapped without breaking the digests. The execution certificate page applies the same test to certificates, and the audit trail page shows what a run of these records adds up to.

The format underneath: AER-1

The receipts used in every section above follow one open format: AER-1, IETF Internet-Draft revision 23 (draft-zambo-aer1-23). AER-1 is an IETF Internet-Draft, not a finalized standard. It defines the per-step verifiable receipt and the workflow record that links receipts for a run, so a receipt produced in one place can be checked by a receiver somewhere else, with no account on the system that produced it and no cooperation from the operator who ran the agent.

To put receipts under your own agent's work: start with the live demo for a single checked call, then a Zambo Day Pass for a day of calls with a verifiable receipt under each one. The general method this page applies is laid out in Verify AI work: check the record, not the summary.

Questions, answered

What is an agent execution attestation?

An agent execution attestation is a statement that an AI agent executed a specific call and produced a specific result. In the AER-1 sense, the attestation is carried by a verifiable receipt: a record minted at execution time that binds the tool, the recorded inputs, the saved result, and the provenance class under SHA-256 digests a receiver can recompute. The statement says who stands behind the work; the receipt lets anyone check the work itself.

What does an agent execution attestation prove?

Carried by a verifiable receipt, it proves the saved result was not changed since it was saved, and it lets anyone read that saved result and recompute its digest. It does not prove the result was correct, and it does not prove an external event happened beyond what the record itself shows.

How do I verify an agent execution attestation?

Open the receipt behind the attestation, take the saved result bytes exactly as they are saved, recompute the SHA-256 digest over those bytes, and compare it with the digest in the receipt. A match means the saved result is intact, and the provenance class in the record tells you who ran or reported the call. The public verifier at zambo.dev/verify runs the same checks in the open, free, with no account.

What is the difference between an attestation and a verifiable receipt?

An attestation is a statement by a party: someone asserts the work happened, and its force ends at that party's credibility. A verifiable receipt is a record a receiver recomputes, so its force does not depend on believing anyone. The attestation belongs inside the record, as its provenance class, bound to the exact result it describes.

What does an agent execution attestation bind?

A complete attestation binds the recorded inputs under an input hash, the saved result under an output digest, the tool name, version, and scope, the execution timestamp, and the provenance class that says who ran or reported the action. When the call is one step of a larger job, the receipt also takes a position in the run's step sequence, so the attestation covers the step in context, not in isolation.

Related