Compliance audit packs

An agent run already hash-chains every receipt it produces: each model call and sandbox execution, in order, across kinds. An audit pack packages that whole chain into a single signed, self-verifying export you can hand to an auditor, a regulator, or a customer's compliance team. It carries no prompt, completion, or code. Like everything else Sable signs, it is metadata only.

Requesting a pack

POST /v1/runs/{run_id}/audit (session-authed, Bearer sess_…) returns the pack for a run you own.

curl https://api.buildsable.com/v1/runs/my-agent-42/audit \
-H "Authorization: Bearer $SABLE_SESSION_TOKEN"

What is in the pack

{
  "format": "sable-audit-pack/v1",
  "run_id": "my-agent-42",
  "summary": {
    "receipts": 4,
    "models": ["sable", "sable-llama-3.3-70b"],
    "total_cost_micro_usd": 1830,
    "started_at": "2026-08-31T09:00:00Z",
    "ended_at": "2026-08-31T09:04:12Z"
  },
  "chain": {
    "head_hash": "a91f…",
    "manifest_sha256": "7c02…",
    "recompute": "sha256( chain(n-1) || sha256(receipt(n)) )"
  },
  "anchor": {
    "state": "anchored",
    "memo": "sable-runs:v1:<root>",
    "signature": "<base58 Solana signature>"
  },
  "manifest_proof": {
    "proof": "eyJ2Ijoi…",
    "signature": "0x4f8c…",
    "signer": "0xA1b2…9F"
  },
  "receipts": [
    {
      "seq": 0,
      "request_id": "req_8f3c…",
      "kind": "chat",
      "prev_hash": "0000…",
      "chain_hash": "3b6d…",
      "receipt": "eyJ2Ijox…",
      "signature": "0x…",
      "signer": "0xA1b2…9F",
      "model": "sable",
      "provider": "anthropic",
      "cost_micro_usd": 540,
      "status": "ok"
    }
  ],
  "verify": {
    "receipts": "POST /v1/receipts/verify { receipt, signature }",
    "manifest": "POST /v1/receipts/verify { receipt: manifest_proof.proof, signature: manifest_proof.signature }"
  },
  "standards": ["eu-ai-act-article-12", "soc2-model-lineage"],
  "trust_model": "attested by the Sable gateway over its hash chain, publicly anchored when an anchor exists, not zero-knowledge"
}

Each entry in receipts is a full, independently signed receipt plus its position in the chain (seq, prev_hash, chain_hash) and its model lineage (model, provider, and, when a flagship id resolved to a different engine, the receipt's own engine field). head_hash is the chain head that one hash proves the entire ordered run from.

Verifying a pack

The pack is designed to be checked by a third party who does not trust Sable and does not need a Sable account. There are three independent checks, in increasing strength.

1. Verify each receipt. Every element of receipts verifies on its own through the public POST /v1/receipts/verify, or locally with any secp256k1 / EIP-191 library against the pinned deployment signer (see Verifying a receipt).

2. Recompute the chain. Walk the receipts in seq order and recompute chain(n) = sha256( chain(n-1) ‖ sha256(receipt(n)) ). The final value must equal chain.head_hash. Any inserted, removed, or altered receipt breaks this and every later link.

3. Verify the manifest as a unit. manifest_proof is a single signed statement over the ordered manifest (its manifest_sha256), so one verification covers the pack as a whole rather than receipt by receipt. It uses the same public endpoint as everything else:

curl https://api.buildsable.com/v1/receipts/verify \
-H 'content-type: application/json' \
-d '{"receipt": "<manifest_proof.proof>", "signature": "<manifest_proof.signature>"}'

Anchoring

When the deployment's anchor account is funded, run heads are batch-anchored to Solana as memo sable-runs:v1:<root>, and the pack reports the finalized signature under anchor. Until a batch finalizes, anchor.state is honestly awaiting_anchor: the pack never fabricates settlement. A public anchor is what lets a verifier confirm the run head existed at a point in time without taking Sable's word for it.

Where a pack fits

The pack is shaped for two recurring evidence requests.

EU AI Act, Article 12 (record-keeping / logging). Article 12 requires automatic, tamper-evident, traceable event logging over the lifecycle of a high-risk AI system. An audit pack is exactly that for the inference and execution events Sable served: automatically recorded, hash-chained so any edit is detectable, and independently verifiable without trusting the operator that produced it.
SOC 2 model-lineage evidence. When a control asks you to prove which model served each request, the per-receipt model / provider / engine lineage, bound into the signed chain, answers it with evidence rather than a screenshot.

Honest scope

Sable produces the verifiable record; it does not certify compliance. A pack proves that these requests ran, on these models, in this order, at this cost, and that the record has not been altered since it was signed. It does not assert that your use of those requests satisfies the EU AI Act, SOC 2, or any other framework. That determination is yours and your auditor's; the pack is the evidence you bring to it. The standards field names the frameworks a pack is shaped for, not frameworks Sable attests you meet.

And, as with every Sable artifact, the pack is metadata only: it carries fingerprints, token counts, costs, and hashes, never prompts, completions, or submitted code. An auditor can verify what ran without ever seeing what was in it.