Agent-to-Agent (A2A)
Accountability Protocol
1. Abstract
With the rise of the Agentic Economy, there is a critical need for a deterministic mechanism to verify actions between independent AI systems. Existing protocols (e.g., MCP) provide Connectivity but lack cryptographic Non-repudiation.
The A2A Accountability Protocol (v0.4) defines a standardized method for a bilateral cryptographic handshake, strict Intent Binding with tool context, and a streaming immutable DAG ledger for machine-to-machine interactions.
2. Terminology
Agent A (Initiator)
The AI system initiating a request to execute a high-value action.
Agent B (Executor / Tool)
The AI system or MCP tool receiving the request.
Trust Proxy
A middleware component implementing the protocol and acting as a trusted Signer on behalf of the agent.
VC (Verifiable Credential)
A cryptographically signed mandate (Policy) defining the risk budget of the agent.
3. Transaction Lifecycle (The Handshake)
The protocol consists of three mandatory phases and one optional phase (Ack) for bilateral Non-repudiation:
Proposal (Intent Envelope)
Proxy A intercepts the call, canonicalizes the arguments, adds a binding to the MCP schema and expiration time (TTL), signs the payload (Proxy-only or Dual-Sign), and sends it to Proxy B.
Acceptance Receipt
Proxy B evaluates the policies. If the validation passes, it generates a policy_eval_hash, signs the agreement to execute, and returns the receipt.
Execution Envelope & Ack
After completing the task, Proxy B hashes the result (output_hash), records the status, and signs the final envelope. Optionally: Proxy A returns a Receipt Acknowledgement to finalize the proof cycle.
4. Data Formats (Data Envelopes)
intent_hash) MUST be computed strictly as SHA-256( JCS(Envelope WITHOUT "signatures" field) ), where JCS is the JSON Canonicalization Scheme (RFC 8785). This allows adding multiple signatures without breaking the base envelope hash.
4.1. Intent Envelope
The signatures array requires mandatory kid (key ID) and signed_digest fields.
{ "envelope_type": "IntentEnvelope", "spec_version": "0.4", "trace_id": "urn:uuid:550e8400-e29b-41d4-a716-446655440000", "timestamp": "2026-03-10T10:15:30.123Z", "expires_at": "2026-03-10T10:16:00.000Z", "initiator": { "did": "did:workload:payment-agent-01", "vc_ref": "urn:credential:treasury-auth-099" }, "target": { "did": "did:workload:stripe-mcp-server", "mcp_deployment_id": "stripe-prod-cluster-1", // Eliminates session ephemerality "tool_name": "execute_wire_transfer", "tool_schema_hash": "e3b0...285", // Protection against API contract changes "mcp_session_id": "sess_98765abc" }, "payload": { "args_hash": "a5b9...9f1", "nonce": "8f42d9a1" }, "signatures": [ { "role": "proxy", "kid": "did:workload:proxy-A#key-1", // Mandatory for the verifier "agent_attestation_ref": "urn:attestation:sgx:a1b2...", "alg": "EdDSA", "signed_digest": "c4d3...e21", // Hash representing the signed payload "value": "eyJhbGciOiJFZERTQSJ9..." } ] }
4.2. Acceptance Receipt
{ "envelope_type": "AcceptanceReceipt", "spec_version": "0.4", "trace_id": "urn:uuid:550e...", "timestamp": "2026-03-10T10:15:30.300Z", "expires_at": "2026-03-10T10:16:00.000Z", "intent_hash": "c4d3...e21", "policy_eval_hash": "b7f8...1a2", "decision": "ACCEPTED", "signatures": [ {...} ] }
4.3. Execution Envelope
{ "envelope_type": "ExecutionEnvelope", "spec_version": "0.4", "trace_id": "urn:uuid:550e...", "timestamp": "2026-03-10T10:15:31.050Z", "intent_hash": "c4d3...e21", // Binding "acceptance_hash": "8f42...1a2", "status": "COMPLETED", "result": { "output_hash": "9f86...d46" }, "signatures": [ {...} ] }
5. Validation Rules (Must Enforce)
Time Management and Clock Skew:
- Time Model:
expires_atMUST be strictly greater thantimestamp. The TTL window is calculated asexpires_at - timestamp. - Clock Skew Rule: Verifier MUST reject if
current_time > expires_at + skew_tolerance. RECOMMENDEDskew_toleranceis 5 seconds.
Anti-Replay (Belt and Suspenders):
- Proxy A (Sender) MUST ensure nonce uniqueness per
(initiator.did, nonce)before signing and emitting the Intent. - Proxy B (Receiver) MUST enforce nonce uniqueness per
(initiator.did, nonce)until the absolute expiration timeexpires_at + skew_toleranceis reached.
Dual-Signature Policy:
- For High-Value actions (fund management, IAM), the protocol SHOULD require Dual-Signature (countersigning): a distinct signature from the Agent itself + a validating signature from the Proxy within the
signatures[]array. In Low-Trust environments, Proxy-only signatures are acceptable only if anagent_attestation_refis provided.
6. Streaming Ledger (DAG Architecture)
To support logic branching and multi-agent delegations, the protocol utilizes a Directed Acyclic Graph (DAG).
Merkle Leaf Definition: The base nodes (Leaves) for constructing the Merkle tree are the entry_hash values, which MUST be computed strictly as:SHA-256( JCS(LedgerEntry WITHOUT "entry_hash") )
{ "entry_id": 104593, "trace_id": "urn:uuid:550e...", "event_type": "EXECUTION_RECORD", "prev_entry_hashes": [ "f8a...1b9", // Intent entry "2c4...e81" // Acceptance entry ], "artifact": { /* ExecutionEnvelope */ }, "entry_hash": "7a2...8c4" }
7. Privacy Guidance
The Execution Ledger publicly records the existence of a transaction, but it must never leak trade secrets (e.g., PII or API keys transmitted to an MCP tool).
args_hash and output_hash are permitted on-chain. In the event of a dispute, parties are required to provide the original JSON (Off-chain), which the arbitrator will process via SHA-256 to verify against the hash in the ledger.
8. Dispute Resolution (Dispute Pack)
A standard Dispute Pack provides independent cryptographic evidence of origin, sufficient for legal arbitration.
- A linked DAG of JSON artifacts (Intent, Acceptance, Execution, Ack).
-
inclusion_proof: A Merkle Path proof connecting the entry to the root. -
anchor_ref: The L2 blockchain receipt (transaction hash).