Live Attestation

A per-tenant, externally-verifiable runtime statement over Wardin’s signed receipt chain, anchored by a reproducible RFC 6962 Merkle root.

A live attestation is a statement about what your gateway actually did, for a period — computed from the signed receipt chain and anchored by a Merkle root anyone you authorize can reproduce, without trusting Wardin and without seeing a single prompt.

An attestation is only as strong as its stated scope. Wardin attests to gateway-routed traffic only — requests it processed and signed. It does not cover AI activity that bypasses the gateway, and it is not a compliance certification (SOC 2 / ISO / EU AI Act) and not legal advice. The scope and disclaimer fields are returned with every attestation; surface them verbatim. Claim language is draft, pending compliance-counsel review.

What it states

For a period, GET /v1/compliance/attestation returns:

• receipts — signed receipts produced for gateway-routed traffic;
• chainVerified — whether the hash chain recomputed end-to-end with no gap or break in sequence (a single altered field breaks every later hash);
• signaturesVerified — whether every receipt’s ED25519 signature verified against the signing-key registry;
• policyEvaluated — receipts carrying signed in-path check records (across both receipt kinds), and the percentage;
• modelReceipts / toolReceipts — the split of the period into model-inference vs agent tool-call receipts; the two carry different checks, so they anchor the coverage denominators below;
• enforcementActions — receipts where an in-path check blocked (BUDGET, ALLOWLIST, or GUARDRAIL on a model call; AGENT_IDENTITY or TOOL_ALLOWLIST on a tool call) or redacted (a GUARDRAIL REDACTED result). A genuine upstream/provider failure (UPSTREAM FAIL) is not an enforcement action — it’s counted separately as upstreamFailures;
• checkCoverage — per in-path check, receipts carrying it and applicableReceipts (the receipts that could carry it: model checks BUDGET/ALLOWLIST/GUARDRAIL over modelReceipts, tool checks AGENT_IDENTITY/TOOL_ALLOWLIST over toolReceipts, UPSTREAM over all). pct is receipts / applicableReceipts, floored — so a check’s coverage is never diluted by receipts of the other kind that could never carry it;
• packsInForce — the framework packs in effect;
• merkle.root — an RFC 6962 Merkle root over the period’s receipt chain hashes.

curl -H "Authorization: Bearer wardin_sk_..." \
  "https://api.wardin.ai/v1/compliance/attestation?range=30d"

See GET /v1/compliance/attestation for the full response shape.

Why it’s trustworthy without trusting us

The Merkle root commits to which receipts exist and their order — using each receipt’s this_hash (its chain hash) as the leaf. The leaf is a hash, never prompt or response content, so an inclusion proof reveals structure, not content. Two independent facts mean the root can’t be forged without detection:

1. Each receipt is individually ED25519-signed — verify any leaf’s signature against Wardin’s published signing-key registry.
2. The leaves chain — each this_hash commits to the previous, so the set can’t be reordered or padded without breaking the chain.

To prove one receipt is covered by an attestation, request GET /v1/compliance/attestation/receipts/{id}/inclusion — a content-free audit path you verify against merkle.root.

Reproduce the root yourself

The Merkle tree is RFC 6962 (the Certificate-Transparency standard), SHA-256, with domain-separated leaf and node prefixes. Any auditor can reimplement it in any language:

MTH([])       = SHA-256()                                  # empty
MTH([d0])     = SHA-256(0x00 || d0)                         # leaf: 0x00 prefix
MTH(D[0:n])   = SHA-256(0x01 || MTH(D[0:k]) || MTH(D[k:n])) # node: 0x01 prefix
              where k is the largest power of two < n

Leaves d0…d(n-1) are the receipts’ this_hash bytes, in ascending seq order (exactly the order the Evidence Bundle lists them). Inclusion-proof verification walks the same split structure: reconstruct the root from your leaf, its index, the treeSize, and the sibling proof path, then compare to root. The 0x00 / 0x01 prefixes are what stop the “duplicate the last node” forgery that plagues naive Merkle trees.

Publishing the root to a public transparency log (CT-style), so the attestation itself is tamper-evident beyond “recompute from the receipts you were shown”, is in development. Today the root is reproducible from the period’s signed receipts, which already can’t be forged without forging ED25519 signatures.

Where to see it

The EVIDENCE stage renders the live attestation for your tenant — receipts, chain status, policy-evaluated coverage, enforcement actions, the Merkle root, and the packs in force — alongside the framework coverage map and the Evidence Bundle export.