> ## Documentation Index
> Fetch the complete documentation index at: https://docs.wardin.ai/llms.txt
> Use this file to discover all available pages before exploring further.

# 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](/concepts/receipts) and anchored by a
Merkle root **anyone you authorize can reproduce**, without trusting Wardin and without
seeing a single prompt.

<Note>
  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.**
</Note>

## What it states

For a period, [`GET /v1/compliance/attestation`](/api-reference/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](/concepts/framework-coverage) in effect;
* **merkle.root** — an RFC 6962 Merkle root over the period's receipt chain hashes.

```bash theme={null}
curl -H "Authorization: Bearer wardin_sk_..." \
  "https://api.wardin.ai/v1/compliance/attestation?range=30d"
```

See [`GET /v1/compliance/attestation`](/api-reference/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](/concepts/offline-verification).
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`](/api-reference/compliance/attestation-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](/concepts/offline-verification) 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.

<Note>
  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.
</Note>

## 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](/concepts/framework-coverage) and the
[Evidence Bundle](/concepts/offline-verification) export.