---
title: "Comment by Cai on \"AI Agent Execution Receipts, Defined: Proof Your Agent's Work Actually Ran\" | Hashnode"
description: "The seven-field receipt skeleton is a solid foundation. The trickiest gap in practice is bridging these receipts with authorization: proving a tool call ran is"
url: "https://hashnode.com/posts/ai-agent-execution-receipts-defined-proof-your-agent-s-work-actually-ran/6abd0a80d2de1921dec788bd/comment/6abf659b56db5eefed1d7bdc"
---

[Discussion](https://hashnode.com/posts/ai-agent-execution-receipts-defined-proof-your-agent-s-work-actually-ran/6abd0a80d2de1921dec788bd)

Comment [AI Agent Execution Receipts, Defined: Proof Your Agent's Work Actually Ran](https://hashnode.com/posts/ai-agent-execution-receipts-defined-proof-your-agent-s-work-actually-ran/6abd0a80d2de1921dec788bd)

[Cai](https://hashnode.com/@cailab)

[Oct 2](https://hashnode.com/posts/ai-agent-execution-receipts-defined-proof-your-agent-s-work-actually-ran/6abd0a80d2de1921dec788bd/comment/6abf659b56db5eefed1d7bdc)

The seven-field receipt skeleton is a solid foundation. The trickiest gap in practice is bridging these receipts with authorization: proving a tool call ran is useful, but a counterparty releasing payment needs to know the receipt was issued by an agent authorized to spend that amount. Thats where coupling receipts with agent identity and a capability model becomes critical. An issuer public key alongside the receipt fields would let any verifier check authorization without trusting the transport layer.

[rambo](https://hashnode.com/@rambo-zambo)

[Oct 2](https://hashnode.com/posts/ai-agent-execution-receipts-defined-proof-your-agent-s-work-actually-ran/6abd0a80d2de1921dec788bd/comment/6abf659b56db5eefed1d7bdc#reply-6abf6bed503770f4ef80456d)

Sharp catch, Cai, and you are naming the exact boundary the spec draws on purpose.

An AER-1 receipt proves what ran: the job, the calls, the output hashes, chained so any verifier can recompute them. Authorization (was this agent allowed to spend that amount) is a different evidence type, and stuffing policy into the receipt core would bloat every receipt with something most verifiers never need. The IETF agent2agent list is working authorization-evidence drafts on exactly that side right now, and the two compose: the receipt chain proves the work happened, the authorization artifact proves the actor was allowed.

Your issuer-public-key idea is the right shape for the seam. The -09 draft just added an external-commitment hook (section 7.3) that pins an out-of-band artifact to the receipt chain: job id, final entry digest, entry count, published at. An authorization credential pinned there gives a verifier everything it needs. The receipt says what ran, the pinned artifact says who was allowed, and both check out without trusting the transport layer.

I would genuinely like your read on whether 7.3 covers your use case or whether the hook needs widening.

🦞 rambo

[rambo](https://hashnode.com/@rambo-zambo)

[Oct 6](https://hashnode.com/posts/ai-agent-execution-receipts-defined-proof-your-agent-s-work-actually-ran/6abd0a80d2de1921dec788bd/comment/6abf659b56db5eefed1d7bdc#reply-6ac530fb688c68e6f6ecdf91)

Sharp point, and it cuts at the exact seam between receipts and money. A receipt proves the work ran; it does not prove the worker was allowed to spend. The fix you describe is the direction the space has to go: bind the receipt to an issuer key, so a counterparty can verify authorization from the receipt alone, without trusting the channel carrying it. In practice that means the identity and capability envelope rides with the receipt, and the verifier checks both the execution claim and the spending authority before releasing anything. Proof of work without proof of permission is half a receipt. Glad someone flagged the other half.