Agent Receipt Standard (ARS)

A verifiable receipt for autonomous actions—not just payments.

ARS gives you a signed JSON document that proves what an agent did, who authorized it, and what settled—without handing verifiers your raw prompts or tenant secrets. Anyone can check the Gateway signature offline.

What is ARS?

The Agent Receipt Standard (ARS) answers one question for auditors, downstream agents, and compliance tooling:

This action happened, under this policy, by this model configuration, with this payment and evidence proof—and here is the Gateway signature.

ARS composes authorization decisions, execution digests, evidence bindings, and funding receipts into one offline-verifiable envelope. Verifiers correlate the story without calling Paybond's live API for every field.

Why ARS exists

Multi-tool agents produce many side-effecting calls per intent. Operators and partners need:

• Portable proof they can verify outside Paybond's live API
• Stable correlation across authorization, Harbor evidence, funding transport, and settlement
• Agent-to-agent handoff without embedding full JSON in prompts

ARS ships that proof as a Gateway-signed JSON document with a published JSON Schema and public verify endpoint.

Where should I start?

Interactive example

How ARS relates to other artifacts

How it works

1. Authorize — Kit middleware checks spend policy and records a spend decision digest.
2. Execute — The guarded tool runs; argument and result digests bind what happened.
3. Submit evidence — Harbor evaluates the predicate; evidence and payee signature digests are recorded.
4. Compose receipt — Gateway assembles authorization, execution, evidence, payment, and outcome blocks, then signs canonical JSON.

For a hands-on walkthrough without writing integration code, use sandbox smoke (see API below) or Agent middleware.

Receipt structure

Every paybond.agent_receipt_v1 document composes the blocks below. Each row shows its purpose collapsed — expand for key fields.

Scopes: per action vs final outcome

API

After middleware evidence submit

Gateway composes and persists action receipts when Kit middleware completes the authorize → execute → evidence path. Fetch by receipt id or by intent + tool call:

HTTP (tenant-bound):

GET /protocol/v2/agent-receipts/{receipt_id}
GET /protocol/v2/agent-receipts?intent_id={uuid}&tool_call_id={id}

Kit:

const receipt = await paybond.agent.getReceipt({
  intentId: "…",
  toolCallId: "…",
});
// or: await paybond.agent.getReceipt({ receiptId: "…" });

const receipt = await paybond.agent.getReceipt({
  intentId: "…",
  toolCallId: "…",
});
// or: await paybond.agent.getReceipt({ receiptId: "…" });

CLI:

paybond login
paybond receipts get <receipt_id> --kind agent --format json
paybond receipts verify <receipt_id> --kind agent --format json

paybond login
paybond receipts get <receipt_id> --kind agent --format json
paybond receipts verify <receipt_id> --kind agent --format json

Offline verify (no tenant fetch): POST /protocol/v2/agent-receipts/verify with the full receipt JSON body, or Kit verifyAgentReceiptV1 / Python parity.

Sandbox-friendly workflow

Run a local middleware smoke path, then inspect receipts:

paybond dev loop --offline   # terminal 1
paybond dev trace            # terminal 2 — timeline at http://127.0.0.1:9477

paybond dev loop --offline   # terminal 1
paybond dev trace            # terminal 2 — timeline at http://127.0.0.1:9477

Or explicit smoke:

paybond login
paybond agent sandbox smoke \
  --operation paid-tool \
  --requested-spend-cents 100 \
  --evidence-preset cost_and_completion \
  --result-body '{"status":"ok","cost_cents":100}' \
  --format json

paybond login
paybond agent sandbox smoke \
  --operation paid-tool \
  --requested-spend-cents 100 \
  --evidence-preset cost_and_completion \
  --result-body '{"status":"ok","cost_cents":100}' \
  --format json

After evidence submit, use paybond receipts get … --kind agent with the returned receipt_id or derived id from intent + tool call. See Agent middleware for the full bind → execute → evidence flow.

MCP resource handoff

The Paybond MCP server publishes a resource template for agent-to-agent receipt handoff:

Hosts call resources/read on paybond://receipt/{receipt_id} to fetch signed JSON without embedding it in prompts. Details: MCP server — agent receipt resources. For MCP spend setup, see MCP agent spend controls.

Operator counter-signature (optional)

When present, operator_attestation is a detached Ed25519 signature over the Gateway message_digest_sha256_hex — not a second canonical body. Verifiers must confirm the attestation digest matches the Gateway digest before checking the operator key.

Gateway compose does not require this block. Kit attach helpers add it when an operator signing key is available (model attestation for downstream trust registries).

Audit export and Signal inputs

• Compliance bundles — opt-in agent_receipts include stores each receipt at agent_receipts/{receipt_id}.json. Verify with paybond receipts verify --kind agent or POST /protocol/v2/agent-receipts/verify. See Audit export compliance.
• Signal fraud inputs — AGENT_RECEIPT_VOLUME_SPIKE and AGENT_RECEIPT_POLICY_DRIFT derive from gateway receipt rows (score-neutral operator signals).

Derived views

PDFs are presentation-only; signed JSON remains canonical.

Specification

• Platform reference: Agent receipts
• Design doc: designs/agent-receipt-v1.md (repository)
• JSON Schema: GET /.well-known/agent-receipt-v1.json