Audit receipts

Every chain that runs through Arclasp produces a signed receipt when it completes. The receipt is your audit trail: it records what happened, who decided what, and when. It’s cryptographically signed so tampering is detectable, and hash-chained across your organization so deletion of any receipt is detectable too.

Why receipts matter

Compliance, debugging, and trust all eventually need the same thing: a record of what your AI agents did that you can present to a third party and have them believe it. Arclasp receipts give you a tamper-evident record that authenticated users can verify through server-attested integrity checks.

What a receipt contains

When a chain completes, the backend assembles a receipt that captures the chain in full:

{
  "receipt_number": "PR-2026-00042",
  "chain_id": "chn_01HW...",
  "organization": "your-org-slug",
  "summary": "Vendor purchase workflow completed with human approval.",
  "started_at": "2026-06-13T14:22:00Z",
  "completed_at": "2026-06-13T14:24:15Z",
  "agents_involved": ["research-agent", "negotiation-agent", "email-agent", "commitment-agent"],
  "total_actions": 7,
  "cumulative_metrics": {
    "financial_exposure_usd": 11000,
    "external_communications_count": 1,
    "records_modified_count": 1,
    "external_domains_contacted": ["vendor.com"],
    "estimated_cost_usd": 0.42
  },
  "approvals": [...],
  "events_summary": [...],
  "policy_version": "2.0",
  "previous_receipt_hash": "sha256:8f3a...",
  "signature": "hmac-sha256:..."
}

The signature field is an HMAC-SHA256 over the entire structured data using a key held by the backend. The previous_receipt_hash links this receipt to the previous one for the same organization.

How signing works

When a receipt is generated, the backend:

Serializes the structured data to a canonical JSON form
Computes HMAC-SHA256(structured_data, server_secret) to produce the signature
Stores the receipt with both the structured data and the signature

The server secret never leaves the backend. The signature can only be produced by the backend, and any tampering with the structured data invalidates the signature.

How hash chaining works

Each receipt embeds the hash of the previous receipt for the same organization. This forms a chain: receipt N+1 references receipt N, which references receipt N-1, all the way back to the first receipt (the “genesis” receipt where previous_receipt_hash is null).

Receipt 1: previous_receipt_hash = null                ← genesis
Receipt 2: previous_receipt_hash = sha256(Receipt 1)
Receipt 3: previous_receipt_hash = sha256(Receipt 2)
Receipt 4: previous_receipt_hash = sha256(Receipt 3)
...

This means:

Tampering with any single receipt breaks its signature
Deleting a receipt entirely breaks the chain at that point (the next receipt’s previous_receipt_hash no longer matches anything)
Reordering receipts is detectable because the hash sequence is checkable

Authenticated verification can check receipt integrity and chain continuity through the backend.

Verification

Authenticated callers should use the v2 receipt verification endpoint:

GET /v1/verification/v2/receipts/{receipt_id}

The response reports server-attested receipt integrity status and receipt-chain status where supported. It does not expose raw receipt bodies, HMACs, predecessor hashes, or independent offline proof material. Public sharing uses an admin-issued opaque token:

GET /public/v2/verify/{opaque_token}

Plaintext public tokens are returned once at creation time. Existing links cannot be recovered later because Arclasp stores only a token hash. See Verification for token management routes, authenticated approval verification, and legacy migration guidance.

Verification from the SDK

The SDK exposes v2 helpers:

from arclasp.client import verify_receipt_v2, verify_public_token

result = await verify_receipt_v2("receipt-id-placeholder")

print(result.overall_status)
print(result.integrity.status)

public_result = await verify_public_token("opaque-token-placeholder")
print(public_result.overall_status)

The legacy verify_receipt() helper remains temporarily callable for compatibility with the legacy receipt verification route and emits a deprecation warning.

Receipt numbering

Receipts get human-readable numbers in the format PR-YYYY-NNNNN:

PR- is the Arclasp prefix
YYYY is the year the receipt was created
NNNNN is a zero-padded sequence number within your organization

Examples: PR-2026-00001, PR-2026-00042, PR-2026-15847. These numbers are useful for reference in your internal systems, support tickets, and compliance documentation. The underlying receipt is identified by its UUID; the number is the human-friendly label.

What this gives you

The combination of HMAC signing and hash chaining gives authenticated users a server-attested integrity check over stored receipt data. If you ever need to review what your agents did with a regulator, customer, or security team, the receipt is the tamper-evident record. Raw/offline evidence export is future work. That is the design goal of the receipt system: strong integrity evidence without overstating current public or offline verification capabilities.

Where to go next

Chain-level governance

Why we track the whole workflow, not just individual calls.

Policies

How decisions get made before receipts get generated.

Human approval

How approvals get recorded in receipts.

SDK reference

The full API surface, including verification.

Verification

Current public-token and authenticated v2 verification routes.

Get Started

Concepts

Framework Integration

Guides

Other

Audit receipts

Audit receipts

Why receipts matter

What a receipt contains

How signing works

How hash chaining works

Verification

Verification from the SDK

Receipt numbering

What this gives you

Where to go next

Chain-level governance

Policies

Human approval

SDK reference

Verification

​Audit receipts

​Why receipts matter

​What a receipt contains

​How signing works

​How hash chaining works

​Verification

​Verification from the SDK

​Receipt numbering

​What this gives you

​Where to go next

Chain-level governance

Policies

Human approval

SDK reference

Verification

Audit receipts

Why receipts matter

What a receipt contains

How signing works

How hash chaining works

Verification

Verification from the SDK

Receipt numbering

What this gives you

Where to go next