How privacy works

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.

NONCE=$(openssl rand -hex 32)
curl -s "https://api.anonrouter.ai/v1/gateway/attestation?nonce=$NONCE"

See verify AnonRouter itself for what that document proves and how to check it without writing a verifier.

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 and the 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 the provider attempt. Before any provider call, the attempt is fenced with a one-time authorization, so the same ticket can never fan out into extra provider work.
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.

Security properties

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.

Compatibility mode: an explicit trade-off

Some clients cannot perform the two-step ticket exchange. Compatibility mode 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.