Agent receipts

An agent receipt (paybond.agent_receipt_v1) is Paybond's portable signed JSON artifact for a single autonomous action or an intent-terminal outcome. It answers:

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

Public guide: Agent Receipt Standard (ARS).

Agent receipts complement — they do not replace — existing Paybond artifacts:

Agent receipts compose those pieces into one offline-verifiable envelope using digests and references.

When receipts are emitted

Runtime compose runs in Gateway after Kit middleware completes the authorize → execute → evidence path for action scope. Receipt ids are deterministic: sha256(intent_id and "\x00" and tool_call_id) hex for action scope.

When PAYBOND_AGENT_RECEIPT_SIGNING_KEY_HEX is configured, compose or persist failures surface as a structured agent_receipt object on the Harbor evidence response (compose_status, optional warning_code / warning_message). Evidence success is not rolled back — clients must not assume a receipt always exists. Signing disabled → compose is skipped without that fail-closed signal.

Persisted receipts are first-write-wins: a recompose with the same digest is idempotent; a different digest for the same receipt_id returns a conflict and leaves the stored row unchanged.

Privacy model

Receipts are hash-only for prompts, tool arguments, tool results, and evidence payloads. The schema rejects raw sensitive fields. Tenants can require prompt_hash_sha256_hex and config_hash_sha256_hex without exposing prompt text to verifiers.

Trust model

1. Gateway signature — Composite receipts are signed by Paybond Gateway with a dedicated agent-receipt key (same rotation posture as other Gateway signing keys).
2. Payee evidence — Referenced by evidence.payee_signature_digest_sha256_hex; Gateway does not re-sign payee evidence.
3. Operator counter-signature (optional) — operator_attestation signs the Gateway message_digest_sha256_hex for model attestation; client attach helpers add it when an operator signing key is available. Authenticated trust_mode=tenant_registry defaults operator registry checks on (empty trusted set rejects the attestation). Public Gateway JWKS verify (trust_mode=gateway) leaves registry checks opt-in unless you request the attested validity tier.
4. Offline verify — Client libraries and Gateway expose verify helpers; Gateway publishes the JSON Schema at GET /.well-known/agent-receipt-v1.json and Gateway signing keys at GET /.well-known/agent-receipt-signing-keys.json. Verify helpers accept optional expectedSigningPublicKeys / expected_signing_public_keys to require the receipt pubkey appear in a configured trust set (Gateway applies this automatically when signing keys are configured).
5. Partner emit (tenant_registry) — Partners may sign receipts with their own key. Tenants register those keys in the trusted agent key registry. Authenticated verify with ?trust_mode=tenant_registry resolves active keys bound to authorization.agent.operator_did under the caller's tenant realm only.
6. Validity tiers — Request ?validity_tier=operational|primary|attested on verify (default operational). Offline verify helpers expose the same modes (requiredValidityTier / required_validity_tier):
   • operational — Gateway signature and schema and receipt_id binding
   • primary — operational and Harbor-verified payee signature digest present and consistent with the intent
   • attested — primary and operator attestation with registry-checked signing key
7. Continuity — Action compose may attach optional continuity (run_id, sequence_number, prev_message_digest_sha256_hex) linking prior action receipts in the same run. Offline verify fail-closes on malformed continuity and, when an expected prior digest is supplied, on digest mismatch. Continuity-chain verify helpers validate ordered run histories. Receipts without continuity remain valid at the requested tier based on signature and attestations alone.
8. Mandate binding — When a verified AP2 agent_mandate_v1 external attestation is present, compose promotes its digest (and optional reference_id) into load-bearing authorization.mandate_digest_sha256_hex / mandate_reference_id. Offline verify fail-closes if those fields disagree with matching external_attestations entries. Older receipts without authorization mandate fields remain valid.
9. Categorical settlement outcome — Intent-terminal compose sets outcome.settlement_outcome (SETTLED | PENDING_FINALITY | REVERSED | FAILED) from Harbor terminal states while keeping references.settlement_receipt_id. The field is rejected on action scope; older intent-terminal receipts without it remain valid.
10. Tenant transparency — On successful persist, Gateway appends an idempotent Merkle leaf (message_digest_sha256_hex) to a per-tenant append-only log. Clients fetch GET /protocol/v2/agent-receipts/{id}/inclusion-proof and GET /protocol/v2/agent-receipts/tree-head (Signed Tree Head under the agent-receipt signing key). Offline helpers verifyAgentReceiptInclusion / verify_agent_receipt_inclusion prove issuance against a published tree head. Cross-tenant proof fetch is denied. This is not a public world log.
11. Interop export adapters — Kit helpers project or wrap a verified ARS receipt for partner ecosystems without changing the native wire format:
    • ACTA — decision-receipt shaped JSON for MCP/governance handoff (projectAgentReceiptToActaDecisionReceipt)
    • PEF — content-addressed Payment Evidence Frame (claim_type=paybond_agent_receipt_v1, JCS frame_id); audit export includes companion *.pef.json
    • SCITT — COSE_Sign1 Signed Statement over the ARS message digest for registration elsewhere
12. Optional TEE / ZK digests — Schema reserves slots for TEE execution and ZK policy-proof digests. Verifiers accept well-formed digests when present; Gateway compose does not emit them until a verified attestation source exists.
13. 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.

ARS does not claim set-completeness against suppression (no call → no receipt).

Discovery and API routes

See also v2 protocol trust for related discovery routes and Gateway API reference for the full route table.

Developer surfaces

TypeScript and Python Kit, the CLI, and Gateway HTTP routes are the partner-facing surfaces. Compose and persist run in Gateway; partners verify and fetch through Kit or the protocol APIs below.

What receipts prove (and do not): Trust model. Conformance vectors: kit/agent-receipt/conformance/.

Related

• Agent Receipt Standard guide
• Intent lifecycle
• Agent receipt PDF export (derived view) — verification gate, manifest schema, footer stamp requirements
• Agent receipt OTEL mapping
• MCP server resource handoff
• Agent integrations — emit or consume
• Settlement with existing payment providers
• v2 protocol trust