Security
Router One is a proxy in the request path. This page documents exactly what we capture, what we never store, and how the data flows — so security review never has to depend on a sales pitch.
Last updated:
What we do NOT store
- Request bodies
- Prompt content and message history are not persisted. They pass through in real time.
- Response bodies
- Model completions are not persisted. Streaming responses are forwarded byte-for-byte.
What we DO log
- Per-request metadata
- Timestamp, project and API key ID, model used (and fallback chain), input / output / cache token counts, latency, status code, computed cost.
- Why
- This is what powers the per-request trace, billing reconciliation, and the routing decisions that make the gateway useful — there is no observability without it.
Transport & key handling
- TLS
- All inbound and outbound traffic is over TLS 1.2+. Plain HTTP is rejected at the edge.
- API keys
- Customer keys are stored hashed at rest. They are never returned by any API endpoint after the create-key call.
- Upstream credentials
- Per-provider keys are platform-owned and rotated regularly. Customers never see upstream credentials.
Upstream behavior
- We pass through
- Once a request leaves Router One, the upstream provider's data policies apply on their end. We do not control their retention.
- Provider selection
- Smart routing may shift traffic between providers for the same model family. The exact provider used is recorded in the per-request trace.
FAQ
- Does Router One train on my prompts or completions?
- No. Request and response bodies are not retained. We have no training data pipeline.
- Can I export the metadata Router One has on my account?
- Yes — the dashboard exposes per-request trace and aggregated metrics. Enterprise contracts can include programmatic export.
- How long is metadata kept?
- 90 days for observability and 13 months for billing reconciliation, then purged. Enterprise contracts can adjust this window.