# How privacy works How AnonRouter separates identity from content, runs the content plane in an attested confidential VM, and where compatibility mode changes the guarantee. Most model gateways authenticate you and forward your prompt from the same place. That one system can associate your identity with your content. AnonRouter offers a private ticket flow that separates those roles before the request leaves your client, and it never intentionally writes prompts or responses to disk. This page is the whole picture in one place: the idea, the ticket that makes it work, the request lifecycle, the guarantees, and where those guarantees stop. ## The core idea: separate who from what A private router is not about promising to be careful with your data. It is about arranging the system so the sensitive join never exists in the first place. In the private ticket flow, AnonRouter splits a request across roles that each hold only one half of it: * The **control plane** knows **who you are** (your key, balance, and policy). It never receives your prompt. * The **relay** sees **what you sent** (the prompt and response) but never learns your key or account. * The **provider worker** holds the **provider credential** and the authorized payload, but never sees your account. Because identity lives on one side and content on the other, neither side can say who sent which prompt. The single-use ticket is what lets them cooperate without ever introducing you to each other. ### The content side runs in a confidential VM Separating the roles answers *"can any one component link you to a prompt?"* It does not by itself answer *"what stops the content side from keeping the prompt anyway?"* The relay, compatibility broker, and provider workers run inside an **Intel TDX confidential VM (CVM)**. TLS for `api.anonrouter.ai` terminates inside that CVM, not at an ordinary proxy in front of it. The host operator cannot inspect the running VM's memory to read prompts. The part that matters is that this is **checkable rather than promised**: the plane will attest to itself, credential-free, to anyone who asks. ```bash NONCE=$(openssl rand -hex 32) curl -s "https://api.anonrouter.ai/v1/gateway/attestation?nonce=$NONCE" ``` See [verify AnonRouter itself](/tee-verification#verify-anonrouter-itself-hop-1) for what that document proves and how to check it without writing a verifier. On a narrow screen, scroll the diagram horizontally to follow the control plane, confidential content plane, and provider boundary.
Your client the privacy split happens here IDENTITY AND CONTROL PLANE control.anonrouter.ai Knows your key, account, balance, and policy. Receives model and priced limits, never the prompt. Mints one-use opaque ticket bound to model · limits · policy INTEL TDX · CONFIDENTIAL VM api.anonrouter.ai TLS terminates inside the attested CVM Ticket relay prompt + ticket · no stable key or account Provider workers isolated credentials · model-bound payload Optional compatibility broker lives here too 1 · key + content-free limits 2 · opaque ticket 3 · ticket + prompt verify attestation before sending EXTERNAL MODEL PROVIDER Sees plaintext on ordinary routes. Provider E2EE routes keep it encrypted. 4 · provider call 5 · usage metadata only for settlement COMPATIBILITY MODE One URL, but key and prompt meet in the CVM. Host-blind, but not unlinkable like the ticket flow. No prompt or response is intentionally persisted by AnonRouter.
## What a ticket is A ticket is a short-lived, single-use authorization that stands in for your identity. You spend your key once, with the control plane, to obtain a ticket; you then hand the ticket (not your key) to the relay that actually serves the request. Every ticket is: * **Opaque.** It carries no readable account information. * **Single-use.** It is redeemed exactly once and then rejected forever. * **Short-lived.** It expires in roughly 30 seconds, so a leaked ticket has almost no window. * **Request-bound.** It is minted for a specific model, a specific output-token limit, and a digest of the request's routing and reasoning policy. A ticket cannot be replayed against a different or larger request than the one it was issued for. ## The lifecycle of a request 1. **Authenticate once, privately.** Your client calls the control plane at `POST /v1/inference/tickets` with your inference key, naming the model and output limit. The control plane verifies the key and confirms you can afford the request. See [authentication](/authentication) and [the quickstart](/quickstart) for the exact calls. 2. **Reserve, then mint.** The control plane reserves the **worst-case** cost of the request (the most it could cost at the requested output limit) against your balance, then mints a single-use ticket bound to that request. This is the last point at which your identity and the request meet. 3. **Redeem at the relay.** Your client sends the completion to the relay with the ticket in the `x-anonrouter-ticket` header. The relay redeems the ticket once, checks that the request matches what the ticket was bound to, and never receives your key or account. 4. **Fence each provider attempt.** Before any provider call, the attempt is fenced with its own single-use dispatch authorization. If the provider fails before any output, [failover](/provider-routing#automatic-failover) may authorize one more attempt on a different provider, but only within the plan the ticket bound: within the workspace's retry limit (never more than 3 attempts in all), never below the privacy floor, within the amount already reserved, and never for an E2EE request. A ticket cannot fan out beyond that bound, and a replayed or altered attempt is refused. Each fallback does send the request to one more provider, which is why a workspace can limit retries or turn fallback off. 5. **Serve.** The provider worker, holding only the provider credential and the authorized payload, calls the model provider and streams the response back through the relay to you. 6. **Settle.** Billing is finalized from usage metadata (token counts, status, latency) only. The reserved amount is settled to the real cost and the remainder released. Content is never read to bill. See [metering and settlement](/metering). ## Security properties | Property | How it is enforced | | ---------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Unlinkability | Identity is held only by the control plane; content is held only by the relay. Neither can join the two, so no record maps you to a prompt. | | Single use and replay safety | A ticket is redeemed exactly once and then permanently rejected. A replayed or expired ticket is refused before any provider work. | | Request binding | The ticket is bound to the model, the output-token limit, and a policy digest. It cannot be upgraded to a bigger or different request after issuance. | | Worst-case reservation | Funds are held for the maximum the request could cost before the first attempt, so serving never needs to consult your balance or identity again. | | No content at rest | Prompts, responses, system prompts, files, tool arguments, and raw provider bodies are never written to disk. Keys are stored only as a hash. | | Confidential execution | The relay, the compatibility broker and every provider worker run inside an Intel TDX confidential VM that terminates TLS in-enclave, so content never reaches a host an operator can read it off. [Verifiable on demand](/tee-verification#verify-anonrouter-itself-hop-1), credential-free. | | Fail closed | If a privacy or authorization check cannot be satisfied, the request is refused rather than served on a weaker footing. | ## What is and is not retained Operational records may contain account and credential identifiers, provider and model identifiers, token counts, estimated and final cost, request status and latency, request identifiers and timestamps, and billing, security, and rate-limit metadata. AnonRouter does not intentionally persist prompt or response text, system prompts, uploaded file contents, tool arguments or outputs, raw provider request or response bodies, or API keys, session cookies, and authorization headers. API keys are shown once at creation and kept only as a hash. ## Privacy classifications Separating identity from content protects you at the router. It does not change what the model provider on the other end can do with the prompt while serving it. That is what the per-route privacy label tells you. Every route carries exactly one classification, and automatic routing never silently widens the set you allowed. | Label | `privacy_class` | What it means | | --------- | --------------- | -------------------------------------------------------------------------------------------------------------------------- | | Anonymous | `anonymous` | Your identity is hidden, but the model provider can see the prompt while serving it. Provider retention is not guaranteed. | | Private | `private` | Prompt and response content is not retained after the request completes. | | TEE | `tee` | Inference runs inside a hardware-isolated, attestable enclave. | | E2EE | `e2ee` | Your client encrypts the prompt so that only a verified enclave can decrypt it. | > **Two layers, read both** > > The ticket flow decides whether AnonRouter can link you to a request. The > privacy label decides what the provider serving the request can see. A private > request over an Anonymous route is still unlinkable at the router, but the > provider can read the prompt. See [models and privacy labels](/models) for the > label on each route, the [E2EE client guide](/e2ee) for encrypted request > setup, and [TEE verification and encrypted inference](/tee-verification) for > enclave evidence, verification levels, and signatures. ## Compatibility mode: an explicit trade-off Some clients cannot perform the two-step ticket exchange. [Compatibility mode](/compatibility) lets those clients send a static key straight to the API with no ticket. To do that, a broker must hold your key identity and your plaintext request together in memory long enough to mint a ticket internally and forward the request. That broker logs metadata only and holds no database or provider credentials, but this flow is **not unlinkable** the way the ticket flow is, because your identity and your content briefly meet in one place. OpenAI-compatible access is enabled by default on newly created keys so ordinary tools work immediately. You can turn it off while creating a key when that key will use only the private ticket flow. ## How this is different from a typical router A conventional gateway is a trusted middleman: it authenticates you and forwards your prompt from the same service, so it can always tie your account to your content, and you rely on its policy not to keep that link. In AnonRouter's private ticket flow, the link is not merely unlogged, it is architecturally absent: the component that knows you never sees your prompt, and the component that sees your prompt never knows you. The ticket is the mechanism that lets those two halves serve one request without ever being introduced. And the half that does see your prompt runs inside a confidential VM that will prove what it is running, to anyone, without a credential. So "we do not keep your prompts" is not a policy you have to believe. It is a property you can check, and one we would have to visibly break to violate. > **Two things this does not claim** > > **The provider still sees your prompt** on an ordinary route. Our worker > forwards it upstream, where it is handled under that provider's policy. The > [privacy label on each route](/models) is what tells you which, and an > [E2EE route](/e2ee) is what avoids it. > > **Inside the enclave, our attested build handles your plaintext** in order to > route and meter it. A build changed to exfiltrate it would change the > measurements and stop verifying, so cheating is *detectable* rather than > impossible. E2EE is the mode where our build is not in your trust set at all. > **Try it** > > Walk the full flow yourself in [the quickstart](/quickstart), or read the > per-route guarantees in [models and privacy labels](/models).