Zero data retention (ZDR) is an arrangement in which an AI provider processes a request and does not store the prompt or the response afterward. For eligible API customers, OpenAI describes ZDR as not retaining prompts or responses after processing, with no personnel review of content, apart from flagged potential CSAM images retained for manual review and reporting. The term is precise but narrow: it applies to specific endpoints, usually requires approval, and says nothing about what your own application, gateway, or tools keep. This guide explains what ZDR covers, what it leaves out, how to request it, and what to verify across an agent stack.
TL;DR
- ZDR means a provider does not store prompts or outputs after processing a request; it is a retention control, separate from the choice not to train on your data.
- It is generally not on by default: OpenAI requires prior approval and additional requirements, and Claude Code ZDR is available to qualified accounts on Claude for Enterprise.
- Stateful features, ineligible endpoints, and third-party tools fall outside ZDR and follow their own retention rules.
- In an agent workflow, retention happens at every hop: model provider, harness, gateway, tools, tracing, and your own logs. Verify each one.
What zero data retention means
The plain definition is short: inputs and outputs are used to produce a response and then discarded. Providers phrase it with different boundaries, so the exact wording in each provider's documentation matters.
Mistral defines ZDR as a control under which inputs and outputs of supported stateless API calls are not stored or logged longer than needed to generate the output. OpenAI's version, covered above, adds the dimension of human review: content is not retained and personnel cannot read it.
Two points follow from these definitions.
- ZDR is scoped to a class of calls. Stateless calls, where the request carries everything the model needs and nothing has to persist between turns, are the natural fit.
- ZDR concerns what happens after processing. It is not a statement about transport security, access control, or what your own systems store.
ZDR is not the same as a training opt-out
Mistral explicitly separates the two: ZDR controls retention after processing, while a training opt-out controls whether data is used to improve models. A provider can decline to train on your data and still keep logs for a period, and a short log retention window does not by itself mean training is off. Compliance reviews that treat these as one setting tend to produce wrong answers in both directions. For a broader view of how storage limits and training preferences relate to data minimization in AI systems, keep the two controls on separate lines of your review checklist.
How the major providers implement it
Implementation differs by vendor. The pattern is consistent, though: a documented scope, an eligibility process, and a list of exceptions.
| Aspect | OpenAI API | Claude Code (Anthropic) | Mistral API |
|---|---|---|---|
| What ZDR means | Customer content excluded from abuse monitoring logs; store treated as false on /v1/responses and /v1/chat/completions | Prompts and responses processed in real time and not stored after the response is returned | Inputs and outputs of supported stateless calls not stored or logged beyond generation |
| Availability | Requires prior approval and additional requirements | Qualified accounts on Claude for Enterprise | Applies to supported stateless API calls |
| Stated exceptions | Ineligible endpoints may store application state; flagged potential CSAM images may be retained for manual review | Retention where required by law or to combat misuse | Not applied to stateful products such as Agents, Batch, or Chat |
Sources for the table: OpenAI data controls, Claude Code ZDR documentation, and Mistral's ZDR documentation.
OpenAI: abuse monitoring and the store parameter
OpenAI's data controls guide states that ZDR excludes customer content from abuse monitoring logs, the same effect as Modified Abuse Monitoring, and that the store parameter is treated as false for /v1/responses and /v1/chat/completions. In practice, that means features that depend on server-side storage of a response, such as chaining to a previous response by ID, cannot rely on that storage under ZDR. Your application must resend the context it needs.
OpenAI: Private Safety Processing
As models run longer, more complex tasks, risk can emerge across multiple interactions rather than in a single prompt. OpenAI's answer is ZDR with Private Safety Processing, in which content is stored in customer-controlled storage and encrypted, and an automated safety runtime checks records without giving human personnel access. OpenAI frames this in its announcement on ZDR for frontier models as a way to identify patterns without exposing raw content to people. For a security team, the practical reading is that safety monitoring and content privacy do not have to be mutually exclusive, but you should read which party holds the storage and the keys.
Claude Code: real-time processing
Anthropic states that with ZDR enabled for Claude Code, prompts and responses are processed in real time and not stored after the response is returned, except where law requires retention or to combat misuse. The documentation also lists features that are disabled under ZDR and notes that some models may require data retention by default, so the model you select affects whether the ZDR guarantee applies at all.
What zero data retention does not cover
This is where most misunderstandings arise. A reasonable reading of "zero" suggests that nothing anywhere is kept. The documentation says otherwise.
- Ineligible endpoints and capabilities. OpenAI notes that endpoints or capabilities marked ineligible may still store application state.
- Stateful products. Mistral clarifies that ZDR does not apply to stateful APIs or products such as Agents, Batch, and Chat, because they need storage for history and application state.
- Third-party services. Per OpenAI, data sent to third-party services over network connections or to remote MCP servers is subject to those parties' own retention policies.
- Safety and legal exceptions. Flagged potential CSAM image inputs may be retained for manual review, and Anthropic carves out retention required by law or needed to combat misuse.
- Your own systems. Application logs, error trackers, analytics, vector stores, and databases sit entirely outside any provider's ZDR.
The last two items matter most for teams building products, because they are the ones the provider cannot fix for you.
How to request or enable ZDR
The process is administrative before it is technical.
- Confirm the plan and the account type. Claude Code ZDR is for qualified accounts on Claude for Enterprise. OpenAI requires prior approval and acceptance of additional requirements. Consumer and self-serve tiers are not the default path.
- Identify the endpoints you use. Map each call your product makes to an endpoint, then check each against the provider's list of eligible and ineligible endpoints.
- Apply the configuration at the right level. Once approved, OpenAI customers can configure ZDR at the organization or project level, which lets you separate a ZDR-covered production project from experimental ones.
- Review disabled features. Under ZDR, some features are turned off. Test the workflow in a staging project and confirm that nothing your product depends on silently stops working.
- Record the evidence. Save the approval, the project settings, and the documentation version you relied on, so an auditor can see what was true when you shipped.
Provider terms change, so treat the linked documentation as the current authority and confirm the details with the provider's account team before making contractual commitments.
ZDR in an agent workflow: what to verify
A single API call has one retention boundary. An agent run has many. A coding agent or support agent typically reads files, calls tools, writes intermediate state, resumes sessions, and emits traces. Each of these can persist data even when the model provider retains nothing.
Use this checklist when you review an agent stack.
| Layer | Question to answer | Where the answer lives |
|---|---|---|
| Model provider | Is ZDR approved and applied to this project, and are the endpoints you call eligible? | Provider documentation and your approval record |
| Model selection | Does the chosen model require retention by default? | Provider documentation for that model |
| Agent harness | Does the harness persist session history, memory, or files, and where? | Harness and platform documentation |
| Gateway or router | Does it log request bodies, cache responses, or forward to providers with different policies? | Gateway settings and retention policy |
| Tools and MCP servers | Where does the data go when a tool is called, and what does that party retain? | Each third party's terms |
| Tracing and telemetry | Do traces contain prompts, tool arguments, or file contents? | Your observability configuration |
| Your own logs | Do application and error logs capture payloads? | Your logging pipeline |
Three habits make this review reliable.
Trace one request end to end. Send a request containing a unique marker string, then search every store you operate or rent for that string: logs, caches, queues, object storage, trace backends. Anything that returns a match is retention you now need to justify or remove.
Treat tool calls as separate data flows. An agent that calls a remote MCP server sends data to a party outside your provider agreement. Decide per tool whether the data it receives is acceptable, and prefer tools you can run inside your own boundary for sensitive workloads. Our overview of agent protocols such as MCP and UHP explains how those connections are structured.
Separate stateful from stateless paths. If a feature needs stored history, decide explicitly where that history lives. Keeping it in storage you control is easier to audit than relying on a provider's stateful product that falls outside ZDR.
Sandboxes, sessions, and file handling
Agents that execute code need an environment, and environments hold files. Where that environment runs, how long it lives, and what happens to its disk when a session ends are retention questions. The tradeoffs of building or bundling this layer are covered in our piece on AI agent sandboxing, and the wider list of components, including session storage, is in what a complete agent backend includes. When you document your retention posture, list the sandbox lifecycle and session storage next to the model provider.
Perspective
From our work on agent infrastructure, the most common retention mistake is not a missing provider agreement. It is the assumption that the provider agreement describes the whole system. A product built on an agent harness has a model provider, a harness runtime, session storage, files, tools, and telemetry, and each of them has its own answer to the question of what is kept and for how long.
This is why we built HarnessRouter as a unified interface over many agent harnesses, available as an open-source edition you can self-host and as a managed cloud. With one Agent API in front of Codex, Claude Code, Hermes, and other supported harnesses, a team has a single place to look at session handling, file handling, and environment lifecycle, instead of reconciling several separate agent backends. Self-hosting lets teams that need strict control keep that layer inside their own boundary, and our stated position is that model provider costs are passed through without markup.
Portability also helps with retention reviews. When harnesses and models can be swapped and benchmarked behind one interface, a team can restrict a sensitive workload to the combination that satisfies its provider terms, and still compare quality and price against the alternatives. We recommend writing the retention posture per workload, verifying it with a marker-string test, and re-running that test whenever a harness, model, or tool changes.
Choosing a setup that fits a ZDR requirement
A workable approach starts from the data, not the vendor.
- Classify the workload. Source code, customer records, and regulated content call for different postures than public documentation summaries.
- Decide which workloads require ZDR. Not every task needs it, and applying it everywhere can disable features you want elsewhere.
- Route by policy. Send ZDR-required workloads only to model and harness combinations whose provider terms cover them, and keep a written mapping.
- Prefer stateless calls for sensitive paths. Resend context from storage you control rather than depending on provider-held state.
- Retest after every change. A new model, a new tool, or a new tracing integration can reopen a path you closed.
If you are comparing how managed agent offerings handle these layers, our comparison of managed agents across providers and multi-harness setups lays out the structural differences, and the article on AI agent portability covers how to avoid being locked into a single retention model.
Running agent harnesses behind one API
HarnessRouter gives product teams one Agent API for integrating Codex, Claude Code, Hermes, and other supported harnesses, with session management, file handling, plugin support, environment provisioning, and benchmarking in one place. The open-source Community Edition can be self-hosted for teams that want the runtime inside their own infrastructure. Managed plans on the pricing page start with a Free tier at $0 per month, followed by Developer at $20 per month, Production at $200 per month, and Scale at $1000 per month, with Enterprise available without a published price. Optional add-ons listed there include Tracing at $50 per month. When you bring your own model API keys, routing is fee-free up to $25,000 per month of model usage at listed prices, with a 5% routing fee above that volume.
Before you commit a sensitive workload, check which plan and configuration match your retention requirements, and see how teams structure real products in the agent product examples.
FAQ
What does zero data retention mean?
It means a provider processes your request and does not store the prompt or the response afterward. For eligible OpenAI API customers, that also means personnel cannot review the content, with the exception of flagged potential CSAM images. Exact boundaries differ by provider and by endpoint.
Is zero data retention enabled by default?
Generally not. OpenAI requires prior approval and acceptance of additional requirements before ZDR can be configured, and Claude Code ZDR is offered to qualified accounts on Claude for Enterprise. Review the provider's current documentation and confirm your account's status before assuming coverage.
Does ZDR mean my data is never used for training?
They are separate controls. ZDR governs retention after processing, while a training opt-out governs whether data is used to improve models, as Mistral's documentation explains. Check both settings, and record each one on its own line in your review.
What is not covered by ZDR in an agent workflow?
Ineligible endpoints, stateful products, and third-party services such as remote MCP servers fall outside it, and each follows its own retention policy. Your own logs, traces, caches, and databases are also outside any provider's ZDR, so they need their own review.
How can I test whether my stack really retains nothing?
Send a request containing a unique marker string, then search every store you operate or rent, including logs, caches, queues, and trace backends. Any match is retention you need to justify or remove. Repeat the test whenever you change a model, harness, or tool.