Quick wins for a faster PC:
Repair Windows errors before they cause bigger problemsFix Now →Scan for outdated or missing drivers - takes under a minuteDriver Scan →Clear out junk files and repair common Windows errorsFree Scan →iTechGuides is reader-supported. When you buy through links on our site, we may earn an affiliate commission. As an Amazon Associate I earn from qualifying purchases. Learn more
An A2A Agent Card signature can show that an agent’s published description has not been altered since it was signed. It cannot show that a task ran, what it produced, or that its recorded outcome is still accurate. Those claims need a separate task record with its own defined contents and verification rules. The A2A Protocol v1.0.1 specification defines Agent Cards, task objects and an optional card signature. It does not define a general-purpose signed task receipt.
This article separates what the protocol establishes from what a receipt design would still have to specify. It does not describe the receipt format, key handling, storage, verification steps, performance or testing of the implementation named in the title. The sources behind this article do not document those details, so any claim about them would be unsupported.
Three questions that get blurred together
People asking how to verify what an AI agent did are usually asking three different things at once. Each one maps to a different object:
- Who is this agent, and what can it do? That is the Agent Card.
- What work was requested, and what state did the server report for it? That is the task object and its status and artifacts.
- Can a third party confirm that a specific task record is unchanged? That is a task receipt, which the A2A specification does not define.
Most confusion comes from answering the third question with an object built for the first.
#1 Best Overall
What an Agent Card contains
An A2A server makes its Agent Card available so that clients can discover a suitable agent and configure an interaction with it. The specification lists three discovery approaches: a well-known URI pattern, registries or catalogs, and direct configuration.
The card describes the agent. Its fields include:
- agent identity and description
- supported interfaces
- version
- capabilities
- security schemes and security requirements
- input and output modes
- skills
- an optional signatures field
Nothing in those fields records a past task. A card tells a client what an agent claims to be and how to reach it, not what it has done.
What the optional card signature proves
The A2A Protocol v1.0.1 specification allows an Agent Card to be digitally signed. The exact wording is:
“Agent Cards MAY be digitally signed using JSON Web Signature (JWS) as defined in RFC 7515 to ensure authenticity and integrity.”
Before signing, the card’s JSON content must be canonicalized with JSON Canonicalization Scheme (JCS, RFC 8785), and the specification’s field-presence rules apply. Signing is optional. A card without signatures remains a valid card under the specification.
A valid signature supports two statements about the card: its content is authentic relative to the signing key, and it has not changed since signing. It says nothing about whether a particular key should be trusted. That depends on how a verifier obtains and evaluates the key, which the card specification does not settle for task records.
What a task record contains
A2A tasks are stateful. According to the specification, a task has:
The Tool Desk
Outbyte PC Repair FREEClear out junk files and repair common Windows errorsFree Scan →Outbyte Driver Updater FREEScan for outdated or missing drivers - takes under a minuteDriver Scan →- a unique task ID
- a current status, which includes a state and may include a message and timestamp
- optional artifacts, the outputs the task produces
- optional history
- optional metadata
Clients can learn about a task in three ways. Streaming delivers task status updates and artifact updates as they happen. Get Task retrieves the task’s state later. Push notifications send updates to a configured endpoint. Each path returns the server’s reported state. None of them, as described in the specification, attaches a signature to that state.
Rank #3
Why a card signature is not a task receipt
The table below compares the objects the specification defines with the receipt the title describes. Entries marked as not stated are not covered by the A2A v1.0.1 specification.
| Object | What it describes | Signing under A2A v1.0.1 | What it can support |
|---|---|---|---|
| Agent Card | Identity, interfaces, version, capabilities, security requirements, skills | Optional; JWS signature over JCS-canonicalized content | Authenticity and integrity of the card content relative to the signing key |
| Task and status | Task ID, current state, optional message and timestamp, optional history | Not defined by the specification | Not stated as evidence of integrity; reflects the state the server reports |
| Artifacts | Outputs a task produces | Not defined by the specification | Not stated for integrity or provenance |
| Task receipt (as named in the title) | Not defined by the specification | Implementation-specific; not documented in the sources for this article | Depends on its defined contents; not established here |
The practical consequence is that a valid Agent Card signature does not carry over to a task. If a receipt needs integrity, it needs its own signature or its own verifiable binding, and the verifier must know which object was signed.
Where stream-based records can have gaps
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.
Windows Errors? Fix Them Before They Spread
Repair common Windows errors and clear accumulated junk for a smoother, more stable PC - no reinstall needed.Free scan · no reinstallOutdated Drivers Are Slowing You Down
One free scan finds every outdated or missing driver and matches the right update for your exact hardware.Free scan · exact hardware matchA receipt built only from streamed events can therefore have holes that the client never sees. The obvious recovery path is Get Task, which returns the task’s current state. However, Get Task answers “what is the state now,” not “what were all the states along the way.” Whether a client can reconstruct every missed transition depends on whether the server exposes task history, and the specification lists history as optional. A receipt design that relies on the stream alone should say how it detects a gap and how it fills one.
Rank #4
What a verifiable task receipt has to define
A receipt is not a protocol feature until its contents, binding and verification are specified. The questions below are the design decisions any receipt design would need to answer. They are not claims about the implementation named in the title.
Claims and binding
A receipt should state exactly what it asserts. Possible claims include that a task with a given ID existed, reached a stated state, and produced an artifact with a given identifier or hash. Each claim needs a binding to the task. The design must say which fields are included, for example task ID, context, state, artifact identifiers or hashes and timestamps, and how those fields are tied together.
Signing, canonicalization and key ownership
The receipt may be signed, hashed, chained to earlier receipts, externally anchored, or verified some other way. Each choice implies a different trust model. A signed receipt needs a canonical byte form so that signer and verifier compute the same input. The design must also name who controls the signing key, and whether the key that signs task receipts is the same key that signs the Agent Card. Reusing a card key would mix two objects with different claims.
Free tools Windows power users keep installed
One-click scans. No signup required.
Replay, tampering and key rotation
A verifier needs to reject a receipt that is copied from one task and presented as another, and to detect edits to a stored record. Duplicate events and reconnect replays must not produce duplicate receipts with conflicting content. Key rotation raises a separate question: a receipt signed under an old key must remain verifiable after the key changes, or the design must say that it does not.
Offline verification
A design should list what a verifier needs in order to check one receipt without contacting the server: the receipt itself, the public key or key history, the canonicalization rules, and any artifact data needed to recompute a hash. If a verifier must call the agent to confirm a receipt, the receipt provides less independent assurance than its name suggests.
Retention and privacy
Receipts can outlive the tasks they describe and can expose inputs or outputs. A design should state how long receipts are kept, where they are stored, who can retrieve them, and whether artifacts are stored in the receipt or only referenced by hash. Hashing an artifact does not hide it from anyone who already holds a copy.
Failures, retries and missing events
A receipt has to represent outcomes that are not successes. A failed task, a retried task, a task whose stream dropped, and an artifact that changed after first delivery each need a defined representation. Without that, a receipt set can look complete while omitting the events that matter most. The design should also say whether an absent receipt means the task never ran, or that the receipt was never produced.
Do these 3 things before closing this tab:
1Fix the driver behind crashes, sound loss and screen glitches2Repair Windows errors before they cause bigger problems3Scan for outdated or missing drivers - takes under a minuteChecklist for evaluating an implementation account
When an implementation write-up claims verifiable task records, check whether it supplies the following. Each item is a condition for judging the claim, not a finding about any specific project.
Quick Recap
- The exact A2A version and the software libraries used, so that protocol behavior can be matched to the specification.
- A definition of the receipt’s serialized contents, including which fields bind it to the task.
- The signing or hashing method, the canonicalization rules, and the party that controls each key.
- A statement of whether the Agent Card signature is reused, and if so, for what purpose.
- The storage location, retrieval method, and the inputs a verifier needs to check one receipt.
- Handling of failed tasks, retries, duplicate events, reconnects, omitted updates and later artifact changes.
- Evidence for any security or reliability claim, such as source code, design notes, reproducible examples, or test procedures with results.
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.
