Skip to main content
SOC 2 reports are annual PDFs. Trust pages are self-asserted uptime. A live attestation is different: 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, and the percentage;
  • enforcementActions — receipts where an in-path check blocked (budget / model-allowlist / guardrail) or redacted (PII);
  • checkCoverage — per in-path check (AUTH, BUDGET, GUARDRAIL, PII, …), how many receipts 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 make the root un-fakeable:
  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 is already un-fakeable 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.