Zero data retention (ZDR) is a provider commitment that prompts and model outputs are processed in memory to answer a request and are not written to storage afterwards, including the logs a provider would normally keep for abuse monitoring. For most LLM providers ZDR is not the default: it is an approved state attached to a specific customer account, project or endpoint, usually backed by contract terms, and it often excludes features that need to store data. Treat ZDR as something you verify per key and per endpoint, then enforce in how traffic is routed.
What "retention" means at an LLM provider
When an application calls a hosted model, the request can leave copies in several places. It helps to separate them, because each one is governed differently:
- Training use. Whether your data is used to improve the provider's models. Most business API offerings say no by default. This is a separate question from retention.
- Abuse-monitoring logs. Many providers keep prompts and outputs for a limited period so they can investigate misuse. OpenAI's data controls documentation describes this kind of retention for API traffic, with ZDR as an option for eligible customers that removes it (OpenAI, "Your data").
- Application state. Stored conversation threads, uploaded files, vector stores, batch inputs and fine-tuning datasets exist because you asked the provider to keep them. ZDR typically does not cover them, or the provider disables those features for ZDR projects.
- Caches. Prompt caching speeds up repeated prefixes by keeping them for a short time. Whether a cache counts as retention depends on the provider's terms.
- Legal holds. Any provider can be ordered by a court or regulator to preserve data. A retention policy describes normal operation, not every legal obligation the provider may face.
"Not used for training" and "zero data retention" are therefore different promises. Security reviews that treat them as the same thing are a common source of surprises.
How ZDR typically works in practice
Provider terms change often, so check the current documentation and your own contract before you rely on any of this. The pattern across the large providers is consistent, though:
- It is opt-in and approved. You request ZDR, the provider reviews the use case, and, depending on the provider, approval applies to an organisation, a project or a deployment. Check whether new projects inherit it or need their own setting.
- It is scoped to endpoints. Stateless completion-style endpoints are the usual candidates. Endpoints that store state by design are excluded or behave differently.
- Cloud-hosted models have their own terms. Models consumed through a hyperscaler follow that platform's data terms, not the model vendor's. Microsoft, for example, documents how prompts and completions are handled in Azure OpenAI, including abuse monitoring and the process to request modified abuse monitoring for approved customers (Microsoft Learn, data privacy for Azure OpenAI).
- It is a configuration that can drift. A developer who creates a new key in a different project, or switches to an endpoint that stores files, can silently move traffic outside the ZDR scope.
The last point is the operational one. ZDR is only as strong as your control over which key and which endpoint each workload actually uses.
ZDR comparison checklist
Use this table when you compare providers or prepare a contract review. Fill it in from current documentation and your signed terms, not from a blog post, including this one.
| Question | Why it matters | Where to find the answer |
|---|---|---|
| Is ZDR the default, or approval-based? | Approval-based ZDR applies only to approved accounts or projects | Provider data-controls documentation |
| Which endpoints are in scope? | Stateful endpoints often fall outside ZDR | Endpoint-level documentation |
| What happens to abuse-monitoring logs? | This is the retention ZDR usually removes | Data privacy page, DPA |
| Are caches retained, and for how long? | Short-lived caches may still count as storage for your policy | Caching documentation |
| Does it apply to every region you use? | Residency and retention are separate controls | Regional terms, DPA annexes |
| How is ZDR evidenced? | Auditors want a document, not an email | Order form, contract amendment |
| What overrides it? | Legal holds and security incidents can require preservation | Contract, privacy notice |
The contract negotiation guide for LLM providers covers which of these points to put into the agreement itself, so that ZDR does not depend on a web page that can change.
Where ZDR stops protecting you
ZDR solves one problem: the provider keeping a copy of your prompts. It does not solve several others that sit nearby.
It does not stop data from leaving. The prompt still travels to the provider and is processed there. If a prompt contains a customer's card number or a secret, ZDR means the provider should not store it. It does not mean the provider never saw it. Redaction before the call is a separate control.
It does not decide where processing happens. A ZDR-approved project can still route to a region you did not intend. Pair ZDR with the residency controls described in data residency for AI agents.
It does not cover your own systems. Your application logs, tracing pipeline, prompt-debugging tools and agent memory may keep far more than the provider does. A ZDR provider behind a verbose logging stack is not a zero-retention system.
It does not remove your record-keeping duties. If you need to show what an AI system did, for an incident review or a regulator, you need your own record. ZDR removes the provider's copy, so your audit trail becomes the only one.
How to enforce ZDR instead of hoping for it
A ZDR agreement is a precondition. Enforcement is about making non-ZDR paths unreachable for the workloads that need ZDR.
- Inventory every key. List each provider key in use, which organisation and project it belongs to, and whether that project has ZDR approval. Keys created ad hoc in personal or sandbox projects are the usual gap.
- Centralise keys in one registry. When each service holds its own key, you cannot prove which one a request used. A single registry gives you one place to see, rotate and revoke credentials. The BYOK configuration guide explains this pattern.
- Route through one gateway. Send model traffic through a gateway that holds the keys, so applications never call the provider directly. Then the set of reachable keys is the set the gateway holds. The LLM gateway comparison compares the options.
- Separate ZDR and non-ZDR keys. Do not mix them. If some workloads legitimately need stateful features, give them a separate, clearly labelled configuration.
- Block stateful endpoints where ZDR is required. If a workload must stay in ZDR scope, it should not reach file uploads, stored threads or batch endpoints through the same path.
- Redact before the call. Strip personal data and secrets from prompts that do not need them, so that what the provider processes is already minimised.
- Keep your own audit trail. Record which configuration served each request, and the guardrail decisions applied to it, in a log you control.
- Re-check on change. Repeat the inventory when you add a provider, a project or a new endpoint type, and when the provider updates its terms.
Common mistakes
- Treating the "we don't train on API data" statement as a retention guarantee.
- Getting ZDR approved for one project, then creating keys in another.
- Assuming a hyperscaler-hosted model inherits the model vendor's terms.
- Turning on prompt caching, batch or file features without checking their retention behaviour.
- Writing full prompts to your own observability stack after negotiating ZDR with the provider.
How Praesidia helps
Praesidia does not change any provider's retention terms. Those come from your contract. What it gives you is control over the path your traffic takes:
- Discover. See which agents call which models, so keys and workloads outside your intended scope become visible.
- Secure. Register provider keys once in an encrypted BYOK registry. The raw key is never returned after storage, so spend and data terms stay on your own provider account. Route model traffic through the Praesidia gateway, where guardrails can redact, warn or block before the request reaches the provider. Keep only ZDR-approved keys in the configurations that production workloads use.
- Prove. Praesidia writes its decisions to an append-only, hash-chained audit trail, so you keep your own evidence of what was sent where, even when the provider keeps nothing.
To see how the gateway fits with the rest of the control plane, read the AI gateway guide.