An A2A Agent Card cannot, on its own, prove that a task happened. The card is a manifest that describes an agent, and it may carry a digital signature over that description. Showing that a specific task ran, and what state and outputs it produced, needs a separate object: a verifiable task receipt. The A2A specification does not define one.
This article explains what the A2A v1.0.1 specification establishes about Agent Cards and tasks, where those mechanisms stop, and what any receipt design has to specify. It does not describe the receipt format, cryptography, storage, or verification steps of a particular implementation. Those details are not published in the protocol specification or in any source this article can cite, so they are not reconstructed here.
As an Amazon Associate I earn from qualifying purchases.
What an Agent Card describes
In A2A, a server makes its Agent Card available, and clients use the card to find suitable agents and configure how they interact with them. The specification names three discovery approaches: a well-known URI pattern, registries or catalogs, and direct configuration.
The card carries these fields:
- agent identity and description
- supported interfaces
- version
- capabilities
- security schemes and security requirements
- input and output modes
- skills
- an optional signatures field
Every item on that list describes the agent as a standing offer of service. None of it records a particular request, a particular run, or what the agent returned.
#1 Best Overall
What signing the card adds
The specification permits an Agent Card to be digitally signed. The A2A Protocol v1.0.1 specification states:
“Agent Cards MAY be digitally signed using JSON Web Signature (JWS) as defined in RFC 7515 to ensure authenticity and integrity.”
Signing is optional. Before signing, the card’s JSON must be canonicalized using the JSON Canonicalization Scheme (JCS, RFC 8785), and the signer must follow the field-presence rules the specification documents. Canonicalization matters because a verifier has to reproduce the exact bytes that were signed. Without a fixed canonical form, a change as trivial as whitespace or key order could make a valid signature fail.
What a card signature establishes is narrow. The card’s canonical content was signed by a key, which supports the card’s authenticity and integrity. It says nothing about the work the agent later performed under that card.
What an A2A task records
A2A tracks work as a task. According to the specification, a task has:
- a unique ID
- a current status, made up of a state and, optionally, a message and a timestamp
- optional artifacts, which are the outputs a task may carry
- optional history
- optional metadata
A client can follow a task in three ways. Streaming delivers status updates and artifact updates as they occur. Get Task retrieves the task’s state at the time of the call. Push notifications are a further supported mechanism, available when they are configured.
Rank #4
Why streamed updates are not evidence on their own
The specification cautions that a client using streaming may miss status updates after it disconnects and reconnects. It also states that messages must not be treated as a reliable delivery mechanism for critical information.
Quick wins for a faster PC:
Fix the driver behind crashes, sound loss and screen glitchesFind Drivers →Repair Windows errors before they cause bigger problemsFix Now →That caution is the central constraint for any receipt. A record assembled only from the events a client happened to receive can have gaps in exactly the places a later review would examine. Retrieving a task returns its state at the moment of the call, so a receipt design still has to decide when state is captured and how it handles intermediate updates that were never received.
Independent reader supportYour contribution helps us test, update, and keep practical guides available for everyone.Can an A2A Agent Card prove a task happened?
No. A card identifies an agent and describes what it offers, and its signature, when present, covers the card rather than any task the agent runs. The table sets out what each A2A object can and cannot show.
| Object | What it describes | Signature defined by the specification | Can it show that a specific task ran? |
|---|---|---|---|
| Agent Card | Agent identity and description, interfaces, version, capabilities, security requirements, input and output modes, skills | Yes, optional; JWS with JCS canonicalization | No. It describes the agent, not individual runs. |
| Task | Unique ID, status (state, optional message and timestamp), optional artifacts, history, and metadata | Not defined | Partly. It carries an ID, status, and possible artifacts, but the specification defines no signature or verification step for them. |
| Streamed status and artifact updates | Changes to a task’s status or artifacts as they occur | Not defined | Incompletely. A client may miss updates after a disconnect, and the specification does not treat messages as reliable delivery for critical information. |
| Task state returned by Get Task | The task’s state at the time of retrieval | Not defined | For that moment only. It is not a verified history of the task. |
| Verifiable task receipt | Whatever its design defines | Depends on the design | Only if its contents, binding, and verification rules are specified. A2A does not define one. |
What a verifiable task receipt has to define
Because A2A leaves receipts undefined, any receipt design has to answer the questions below before anyone can say what it proves. Each answer changes what a verifier is entitled to conclude.
- Contents. Which fields are recorded, such as the task ID, context, state, artifact identifiers or hashes, and timestamps.
- Binding. How the receipt is tied to a specific task and its artifacts, and to the Agent Card and version under which the task ran.
- Integrity mechanism. Whether the receipt is signed, hashed, chained to earlier receipts, anchored externally, or checked some other way. Each mechanism supports different claims.
- Key ownership. Who controls the signing keys, and whether the card signature and receipt signatures use the same keys or separate ones.
- Rotation and replay. How keys are rotated, and how duplicate or replayed receipts are detected.
- Offline verification. What a verifier needs, such as the receipt, public key material, and canonicalization rules, to check a receipt without contacting the agent.
- Failures and gaps. How failed tasks, retries, duplicate events, reconnects, omitted updates, and later artifact changes are represented, so that a missing event is visible rather than silent.
- Storage and retention. Where receipts are kept, how they are retrieved, how long they persist, and what they reveal about inputs or the parties involved.
- Versions and libraries. The A2A version and software libraries relied on. A claim about security or reliability is only as specific as the versions behind it.
What this article does not establish
The title refers to an implementation, and this article cannot confirm its receipt format, signing scheme, key handling, storage, verification procedure, test results, or performance. None of those are documented in the A2A specification or in a source cited here. The protocol text supports the background above and nothing beyond it. Any claim about how a particular system signs, stores, or verifies receipts would need that system’s own design documentation or source code behind it.
Quick Recap
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
