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.

Partner external attestations

ARS optionally carries external_attestations[] for partner-native proofs. Supported sources today:

• SEP-2828 — MCP decision/outcome receipt pairs
• x402 — signed delivery receipts
• AP2 — signed agent mandates (agent_mandate_v1), protocol authorization receipts (protocol_authorization_receipt_v1), and protocol settlement receipts (protocol_settlement_receipt_v1)

Kit verifies each artifact locally and normalizes it to a digest entry on the signed receipt. When a verified agent_mandate_v1 entry is present, compose also promotes its digest into load-bearing authorization.mandate_digest_sha256_hex (and optional mandate_reference_id); offline verify fail-closes if those fields disagree with the matching attestation. See Kit agent integrations — external attestations.

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 (and when agent-receipt signing is configured). Persisted receipts are first-write-wins: identical recomposes are idempotent; a different digest for the same receipt_id conflicts and leaves the stored row unchanged. Compose or persist failures surface as structured agent_receipt fields on the Harbor evidence response (compose_status, optional warning_code / warning_message) — do not assume a receipt always exists after evidence success.

Fetch by receipt id or by intent and 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 TypeScript/Python verify helpers. Pass ?validity_tier=operational|primary|attested (default operational) when auditors need a stronger multi-party bar — see Verify modes.

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 and tool call. See Agent middleware for the full bind → execute → evidence flow.

MCP resource handoff

The Paybond MCP server’s ARS role is agent-to-agent receipt handoff—not a full auditor console:

Hosts call resources/read on paybond://receipt/{receipt_id} to fetch signed JSON without embedding it in prompts. Verification failure returns a clear error. Readonly tools paybond_get_agent_receipt_v1 and paybond_verify_agent_receipt_v1 (optional validity_tier) mirror the settlement-receipt pattern. Validity tiers beyond a quick handoff check, continuity-chain, inclusion proofs, owner disclosure, and ACTA/PEF/SCITT adapters stay on Kit TypeScript/Python, CLI, and Gateway. 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. The attestation operator_did must equal authorization.agent.operator_did.

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). Authenticated verify with trust_mode=tenant_registry defaults operator registry checks on (empty registry rejects the attestation). Public Gateway JWKS verify leaves registry checks opt-in unless you request the attested validity tier.

Verify modes (validity tiers)

Auditors and downstream verifiers can require a named bar beyond “Gateway signature verifies”:

Gateway: POST /protocol/v2/agent-receipts/verify?validity_tier=primary (or attested). Offline verify helpers use the same tier names. Details: Agent receipts — trust model.

Continuity across a run

For multi-step agent runs, action compose may attach optional continuity fields (run_id, sequence_number, prev_message_digest_sha256_hex) that hash-link each action receipt to the prior one in the same run. Verify fail-closes when continuity is present and broken. Receipts without continuity remain valid at the requested validity tier.

Mandate binding and settlement outcome

When an AP2 mandate attestation is attached, the signed receipt may also carry load-bearing authorization fields:

For intent-terminal receipts, compose also sets a categorical outcome.settlement_outcome:

references.settlement_receipt_id remains available as today. Older receipts without these optional fields remain valid.

Tenant transparency (inclusion proofs)

When a receipt persists, Gateway also appends an idempotent leaf (message_digest_sha256_hex) to a tenant-scoped append-only Merkle log (RFC 6962-style). Possession of signed JSON plus an inclusion proof proves issuance against a published Signed Tree Head (STH):

Offline helpers: Kit TypeScript/Python verifyAgentReceiptInclusion / verify_agent_receipt_inclusion. Cross-tenant proof fetch returns not found. This is not a public world log — leaves never leave the authenticated tenant boundary.

Interop export adapters

After you have a verified ARS receipt, Kit can project or wrap it for partner ecosystems without changing the native wire format:

• ACTA — decision-receipt shaped JSON for MCP/governance handoff
• PEF — content-addressed Payment Evidence Frame (claim_type=paybond_agent_receipt_v1); audit export includes a companion *.pef.json alongside the signed receipt
• SCITT — COSE Signed Statement over the ARS message digest for registration elsewhere

These are export adapters over a verified receipt — not alternate compose paths.

Confidential owner disclosure

When an operator needs a confidential handoff beyond the public receipt, Kit can encrypt a derived, still hash-only disclosure package to an owner's key. The signed public receipt stays digest-only; owner disclosure is a separate artifact and is never part of the signed body.

Optional TEE / ZK digest slots

The schema reserves optional slots for TEE execution and ZK policy-proof digests. Verifiers accept well-formed digests when present; Gateway compose does not emit them yet.

Audit export and Signal inputs

• Compliance bundles — opt-in agent_receipts include stores each receipt at agent_receipts/{receipt_id}.json plus a PEF companion *.pef.json. Verify with paybond receipts verify --kind agent or POST /protocol/v2/agent-receipts/verify. See Ledger and provenance.
• 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. Before rendering or accepting a PDF, run the verification gate documented in Agent receipt PDF export: verify signed JSON first, validate paybond.agent_receipt_pdf_export_manifest_v1, stamp receipt_id and message_digest_sha256_hex in the footer, and never embed unsigned JSON as authority.

Specification

• Platform reference: Agent receipts
• Conformance: kit/agent-receipt/conformance/ in the repository
• JSON Schema: GET /.well-known/agent-receipt-v1.json
• Signing keys (JWKS): GET /.well-known/agent-receipt-signing-keys.json