Zero Data Retention (ZDR)
Zero Data Retention (ZDR) is a provider policy not to store prompt or completion payload after the request completes. In Fontana, ZDR posture comes from the gateway and BYOK account you configure (for example OpenRouter privacy toggles or direct vendor enterprise terms), not from a Fontana-operated default.
Fontana supports ZDR on every gateway where the upstream provider exposes it, so you can align chat and completion routing with your retention and training requirements. Posture comes from your BYOK contract and, for unified gateways, the provider’s own routing and policy controls. See Gateways for the approved gateway catalogue.
OpenRouter ZDR enforcement
Section titled “OpenRouter ZDR enforcement”When chat routes through OpenRouter, ZDR is governed by OpenRouter’s ZDR policy on your account. OpenRouter tracks per-endpoint data policies (retention and training) and can restrict routing to ZDR-only endpoints at account, guardrail, or request scope. Fontana traffic uses your OpenRouter API key, so account-wide and guardrail ZDR settings apply to all calls through that key.
| Model group (OpenRouter) | Effect when ZDR is enabled for that group |
|---|---|
| Anthropic | Removes first-party Anthropic endpoints (AWS Bedrock and Google Vertex routes remain available) |
| OpenAI | Removes first-party OpenAI endpoints (Azure routes remain available) |
| Removes AI Studio endpoints (Vertex routes remain available) | |
| Non-frontier | Removes all other non-ZDR endpoints |
- Account-level: each model-group toggle in OpenRouter privacy settings restricts all requests on that account to ZDR endpoints for that group.
- Guardrail-level: separate fields per group -
enforce_zdr_anthropic,enforce_zdr_openai,enforce_zdr_google,enforce_zdr_other- so different API keys or org members can carry different ZDR posture. - Per-request:
provider: {"{ zdr: true }"}in the API body ORs with account and guardrail settings (it can only tighten routing, not override ZDR off when account policy requires it). Useful for one-off ZDR-only calls without a global toggle. - Endpoint list: ZDR-capable endpoints are published at
openrouter.ai/api/v1/endpoints/zdrand updated when provider policies change. OpenRouter treats unknown endpoint policies conservatively (assumed retain + train). - Caching: in-memory prompt caching on the provider side is not classified as retention for ZDR routing.
- OpenRouter itself: OpenRouter does not retain your prompts unless you opt in to prompt logging.
Direct gateways and ZDR
Section titled “Direct gateways and ZDR”When you route through a direct gateway (not OpenRouter), ZDR and no-training posture comes from that provider’s API and your enterprise agreement:
- Anthropic, OpenAI, Google, Mistral, AWS Bedrock - direct API calls with your keys; zero-retention and no-training modes depend on the product tier and account settings you hold with that vendor.
- LLM API and other OpenAI-compatible hosts - follow the host’s published data policy for the key you configure.
- Operational control in Fontana - admins approve which gateway and model IDs are reachable in production; combined with BYOK, teams can standardise on direct enterprise endpoints or OpenRouter ZDR-only routing without shadow usage.
Provider vs platform logging
Section titled “Provider vs platform logging”Upstream LLM providers apply ZDR and retention under your BYOK contract and gateway settings above. Separately, Fontana records token usage, latency, and routing metadata for cost and compliance. Optional in-platform AI audit capture (admin audit logs, ai_tool_calls records, and permission-gated LLM debug) can retain prompt and completion excerpts inside your deployment; scope those surfaces to investigators who need them, or rely on metadata-only logging when message bodies must not be stored.