Where it sits
An agent acts through two kinds of plumbing that were never meant to carry the human's record. MCP integrates the agent with tools and data — it answers "how does the agent call a tool." A2A moves messages between agents — it answers "how does the agent talk to another agent." Neither produces a record the represented human can read, hold, and dispute.
Agency Receipts is the layer above both: the human-facing accountability layer those protocols deliberately do not provide. An agent acts through MCP and A2A, and Agency Receipts records, for the human, the outcome the agent produced through them.
MCP + A2A — the plumbing
│
├─ MCP (tool integration) connects an agent to tools and data
│ "how an agent calls a tool"
│
├─ A2A (agent-to-agent transport) moves messages between agents
│ "how an agent talks to another agent"
│
└─ Agency Receipts (sm-arp) the human ↔ agent accountability layer
"what the agent did, for whom, under what authority"
The two are complementary: MCP and A2A move the agent through the world, Agency Receipts holds the outcome to account. Neither does the other's job — plumbing does not attest, and a receipt does not integrate a tool or move a message.
The receipt primitive
A receipt binds, in one signed object, the facts a human and a third party need to understand and dispute one agent action.
| Fact | Field(s) | Notes |
|---|---|---|
| Who acted, for whom | issuer_did, principal_did | the agent and the human (or organisation) it represents |
| What, in one sentence | action.human_summary | readable without tooling, ≤ 280 Unicode code points |
| The action, structured | action.category, action.outcome | machine-readable description of the act |
| The evidence | evidence | optional references that substantiate the action under audit |
| Under what authority | authority_chain | links the action to a delegated-authority grant |
| Bound and ordered | signature, previous_receipt_hash | Ed25519 over canonical JSON; optionally chained to prior receipts |
The whole is signed with the issuing agent's Ed25519 key over a JCS-canonical encoding of the receipt. A receipt is therefore both immediately legible to a human and independently verifiable by a machine — neither property sacrificed for the other. The wire format is documented in full in the normative specification — see Papers & Specs.
The authority chain
The distinctive structure Agency Receipts adds beyond a signed log is the authority
chain. A receipt does not merely record what an agent did; it can link to the grant of
authority the action was taken under, via action.granted_by_receipt_id and the
authority_chain array of grant identifiers.
The pattern is a two- or three-receipt sequence: a principal emits a grant
receipt (action.category == "authority_granted") naming the scope, the
grantee, and an expiry; the agent's later action receipt references that grant;
and an optional revocation receipt can end the grant early. An auditor can walk
from any action back to the human grant at the root — answering not just "what did the agent do"
but "was it allowed to, and by whom."
v0.1 status. authority_chain is descriptive in v0.1 — a verifier
notes the referenced grant but does not yet evaluate it for validity, expiry, or scope coverage.
Full evaluation is normalized by the Delegated Authority Token (DAT) companion spec in v0.2. See
Primitives for sm-dat.
The atomic object: the Agency Receipt
The receipt is the atomic unit: a signed JSON record naming the agent, the human, the action, and
(optionally) the authority and the prior receipt in the issuer's chain. It is signed with Ed25519
over the JCS-canonical body (sans signature) — so a receipt verifies fully offline,
against nothing but the issuer's did:key.
receipt {
version ("arp/0.1")
receipt_id (UUIDv4, unique per issuer)
issuer_did (did:key of the acting agent)
principal_did (did:key of the represented human)
issued_at (RFC 3339, ±300s accept window)
action: { category, human_summary, outcome, ... }
authority_chain (optional — grant IDs this action relied on)
evidence (optional — screenshots, refs, witness co-signatures)
previous_receipt_hash (optional — chains to issuer's prior receipt)
jurisdiction (optional — principal_residence, action_locus, data_residency, applicable_regimes)
accessibility (optional — summary_language, alt_summaries, screen_reader_hints)
extensions (optional — namespace-prefixed fields for downstream consumers)
signature (Ed25519 over JCS(body sans signature))
}
When an issuer maintains a chain, each receipt's previous_receipt_hash is the
SHA-256 hash of the previous receipt including its signature, computed over the
JCS-canonical bytes. Deleting or reordering an issuer's receipts breaks the chain — the history is
tamper-evident, not just append-only.
What it consumes, produces, and does not do
An agent's completed action
The outcome an agent produced through MCP tool calls or A2A messages — the event the receipt records.
The Agency Receipt
One signed, one-sentence-readable, optionally hash-chained receipt, verifiable offline against the issuer's own did:key.
Authorization, ground truth, policy
It does not evaluate whether an action was authorized (v0.1 authority_chain is descriptive), does not prove the action occurred at the counterparty — it is the agent's own signed claim — and does not mandate which actions must be recorded.
Ecosystem positioning. Agency Receipts is the human-facing occurrence record
above MCP and A2A. It composes with sm-conformance for its badge and with
sm-dat for authority evaluation, and is complementary to the Attested Action
Envelope (sm-aae) — see Primitives and
agentenvelope.ai →.