Privacy

Attest never persists files, evidence or claims. That is a design property of the product, and every layer is built so that it stays true without anyone having to remember it.

What Attest holds, and for how long

| What | Where it lives | How long | | --- | --- | --- | | Uploaded files (batches, drafts) | Parsed from the request into process memory | Until deleted, evicted, expired after six hours, or the process restarts | | Claims and evidence sent inline | Process memory for the duration of the request | The request | | Draft review jobs | Process memory | Until collected, then five minutes, or evicted | | The verdict, spans and provenance | The response, and nowhere else | Not at all |

The container enforces it: the Attest service runs on a read-only root filesystem with every capability dropped, so a bug that tried to write a board pack to disk would fail rather than succeed quietly.

The only durable trace of a document is the SHA-256 fileHash returned per upload, so an audit can later ask "was this verdict produced against the document I signed off" by hashing the file it still holds. A hash is not the document and cannot be turned back into one.

What Kerf holds

Kerf is given an address and returns the page. The address and the Markdown live in the job, in memory, until the job is collected or ages out, and a restart forgets both. Nothing is written to disk or a database, and the gateway's request log records the route rather than the address.

Two things follow from fetching a page on your behalf. The site sees Quorum's address and user agent rather than yours, so it cannot attribute the fetch to you. And the service's own log line names the host of the address, so an operator can see which sites the fleet is hitting; the path and query string are not logged. An address whose hostname alone is sensitive should not be sent through a shared service.

A job belongs to the workspace that started it. An id from another workspace answers 404, the same as an id that never existed.

What the API gateway keeps

Authentication, limits, credits and the dashboard live in a gateway in front of Attest, and the gateway does have a database. It is deliberately blind to content. It holds:

• The API key registry: id, name, workspace, scopes, limits and timestamps. Never the key itself.
• Connected MCP clients and hashes of their tokens.
• Usage counts per credential, per hour and per route: requests, errors, rate limits, claims, latency and credits.
• A request log with time, credential, route, status, latency, claims and credits, kept 30 days.

There is no field in any of those for a claim, a document, a span or an evidence id. Request bodies stream through the gateway to Attest and are never buffered whole, logged or written anywhere.

What this means for you

• A verdict is reproducible from the document you still hold plus the hashes and versions in the provenance block. It is not retrievable from Quorum, because Quorum does not have it.
• Revoking a key or disconnecting a client leaves behind only counts.
• Restarting Attest leaves nothing behind at all, and restarting Kerf forgets every job and every page it held.
• Delete batches and drafts when the work is done rather than waiting for expiry.

Model providers

Attest sends claims and evidence to a hosted model provider to measure them, for inference only, and keeps nothing of the exchange beyond the counts above. The provider and model that produced an answer are named in its provenance block.