Security & Privacy
How API keys, sessions, and upstream credentials are protected, and how your request and usage data is handled.
zrouter is built so that money, credentials, and your data are protected by construction. This page summarizes the controls that matter to you as a customer.
API key security#
Your key has the format zr_<public-id>_<secret> and is stored as a SHA-256 hash only. The plaintext secret is never persisted after creation, which means zrouter staff cannot read your key. Because of this, the secret is shown exactly once (reveal-once) when you create it — if you lose it, the only recovery is to create a new key. Revocation is instant and takes effect everywhere immediately.
Keys are compared with a constant-time comparison to prevent timing attacks, and a blocked account receives the same 401 invalid_api_key as a wrong key, so the response does not disclose account state.
Sign-in and sessions#
Customer sign-in uses verified Google OAuth and issues an httpOnly, SameSite session cookie — the session token itself is never exposed to client-side JavaScript. Upstream provider credentials are encrypted at rest (AES-256-GCM) and are decrypted only once at startup in a fail-closed manner; they never appear in logs, errors, or responses.
Data handling#
Your request prompts and successful response content are forwarded to the upstream model for processing and are never stored or logged by zrouter; only usage metadata — model, input and output token counts, cost, timestamp, and funding source — is recorded, as required for billing and support.
Bounded failed-response diagnostics (privacy contract 2026-10-01). When a request fails, zrouter may retain a secret-redacted, size-bounded (at most 1 MiB) UTF-8 representation of the failed upstream error body or an explicit SSE error event for up to 7 days. This representation may include customer content that the error itself echoed back. Raw request prompts, successful response bodies, complete output streams, and content hashes or fingerprints are never retained, and secrets are redacted before any storage, log, or tool output.
The financial ledger and audit events are retained permanently because they are required for reconciliation. Detailed usage metadata is retained for 90 days, while diagnostic event metadata is retained for 30 days and its payload for up to 7 days. The diagnostics system is best-effort and bounded: loss is possible and measured. Access is limited to the owner and explicitly authorized AI agents through a private, host-local, read-only query tool. Any restored backup is purged of expired diagnostic rows before it is queried, and residual copies may remain inside existing backups until those backups expire under the unchanged backup retention policy — zrouter does not claim hard deletion from backups.
Network and billing integrity#
- CORS exact-origin allowlist. Cross-origin requests are restricted to an explicit allowlist — never a wildcard.
- Integer money. All monetary amounts are integer micro-USD, so billing cannot drift from floating-point rounding.
- Rate-limited sensitive endpoints. Auth, checkout, and other sensitive endpoints are throttled to blunt abuse.
Best practices for your side#
- Never commit a key to source control or public issues — treat it like a password.
- Keep keys out of code by reading them from environment variables or a secret manager.
- Rotate by revoking and re-creating. There is no in-place edit; revocation plus a fresh key is the supported path.
- Use HTTPS everywhere. Never send a key over plain HTTP.