Security & trust

Verify the binary you are talking to

Releases of this router build reproducibly: the Go toolchain is pinned in go.mod, and release binaries are built with CGO_ENABLED=0, -trimpath and -buildvcs=false, so independent checkouts produce bit-identical artifacts (proven with matching sha256 digests from separate checkouts on darwin and linux/amd64). There is no trusted builder in the verification loop — you rebuild and compare.

• GET /trust/release.json — the release document baked beside the binary at build time: source ref, pinned toolchain, the exact build command, and each artifact's sha256. Served verbatim as published. When no release document is baked (a dev build), it answers 404 with code no_release — a dev build never pretends to be a release.
• GET /attestation (with ?nonce=..., echoed back to bind the answer to your request) — the running binary's sha256, its embedded build info, and the control-plane config fingerprint. Compare the digest against the release document and against your own rebuild from the named source ref.

What the attestation does not claim

The attestation reports "simulated": true — always. This router runs as a plain OS process ("runtime": "os-process") and never claims confidential hardware. Only a real TEE hardware quote, wired end to end, would ever set that flag false; it is never faked. Until then the honest statement is exactly what the endpoint serves: a self-reported binary digest you can cross-check by rebuilding, not a hardware-rooted proof.

What is retained — and what cannot leak because it was never stored

• No transcripts. Prompts and completions are never stored. GET /v1/generation/content answers content_not_stored, always, for every generation.
• Billing metadata only. GET /v1/generation serves per-generation token counts, cost and route from a bounded ring — no content.
• Provider retention is cited, never asserted. Every route's retention tier on GET /v1/models carries the provider policy citation that earned it. GET /v1/endpoints/zdr is the auditable report: only routes with a cited zero-data-retention (or stronger) tier appear, and absence means assume stored.
• Floors are enforced, not advisory. A request's min_privacy floor — or an account-level floor — makes the router refuse the call rather than serve it below the floor.

Credentials at rest

• Tenant API keys are random bearer tokens stored only as salted SHA-256 hashes. Plaintext exists exactly twice: in the one-time mint response and in your hands. Key lifecycle (list, mint, label, cap, disable, delete) lives at GET /v1/keys — auth-gated, listings show masked hints only.
• BYOK provider keys are envelope-encrypted at rest and write-only: GET /v1/byok/providers serves masked hints and route preferences, never key material.
• Browser keys minted for a signed-in session (POST /v1/auth/browser-key) are capped, expiring, rotating and inference-only — a leaked playground key cannot manage the account.
• OAuth apps get a user-scoped, inference-only key through S256 PKCE (POST /v1/oauth/token); authorization codes are single-use and burn on any redemption attempt.
• Spending is bounded before dispatch. Per-key spend caps and fixed UTC day / week / month windows (POST /v1/account/limits) are enforced at admission with distinct refusal codes.

An honest wire

GET /coverage serves the full route map — every caller-facing route marked real or stub. OpenAI-wire routes this router does not serve refuse with the stable code not_supported instead of a bare 404, so a stock SDK pointed here is told the truth. Liveness is GET /health; the status surface splits the router core and its control plane into separate SLO classes — GET /status for people, GET /status.json for machines, GET /status/history for the bounded ring of past monitor cycles.

Procurement answers as data

GET /compliance.json is the machine-readable compliance packet, scoped to what is true for this deployment: the subprocessor list is derived live from the providers actually configured (an operator key plus a served route — never a hand-maintained list, and the in-process built-in provider is excluded because request content never leaves the router on those routes), retention posture with its citations, status and SLO pointers, and the operator contact — or its honest absence. Where the honest answer is "not configured" or "not attested", the packet says exactly that.