What is ZDR (zero data retention) and why you should care

Learn what ZDR (zero data retention) means and how it prevents providers from storing prompts and responses after processing.

IRSIsh Rajesh ShelleyFounderAugust 22, 20268 min read
On this page

Every prompt your team sends to an LLM API lands on the provider's servers and stays there for a while by default. OpenAI retains inputs and outputs in abuse-monitoring logs for 30 days on core endpoints such as chat completions and responses. Anthropic automatically deletes commercial API inputs and outputs within 30 days of receipt, and keeps trust-and-safety classification scores for up to 7 years when a request gets flagged.

For most workloads that default is fine. For patient records, legal documents, financial data, or anything covered by a customer contract with strict confidentiality terms, it is an open question your security reviewer will ask about.

Zero Data Retention (ZDR) is the arrangement that answers the question. Under ZDR, the provider processes your request and keeps none of the content afterward: no abuse-monitoring log entry with your text, no stored transcript, no training use. This article explains how ZDR works at OpenAI and Anthropic, what it costs you in features and process, and how to verify a ZDR claim before your contracts depend on it.

Zero data retention, defined

ZDR is both a contractual commitment and a set of technical enforcement changes. OpenAI's announcement of ZDR for frontier models states the promise plainly: prompts and model responses are not retained after a request is processed, customer content is unavailable to OpenAI personnel for review, and enterprise data never trains models unless the customer opts in.

Anthropic defines its version operationally: under a ZDR arrangement, Anthropic does not store customer prompts or responses at rest after the API response is returned. The phrase "at rest" matters. Content exists transiently in memory during processing; ZDR promises nothing survives past that window as durable storage.

Both providers gate ZDR behind an approval process; there is no self-serve settings toggle. The differences show up in how each enforces the promise, which is where your evaluation should start.

OpenAI ZDR

OpenAI enforces ZDR through organization-level controls with per-project overrides. Approved organizations configure ZDR or a related control called Modified Abuse Monitoring in Settings → Organization → Data controls, also exposed through an admin API. Enforcement is mechanical:

  • The store parameter on /v1/responses and /v1/chat/completions is always treated as false, even if a request sets it true.
  • Customer content is excluded from abuse-monitoring logs entirely.
  • An endpoint eligibility table splits the API: stateless endpoints like embeddings, moderations, and audio transcription are eligible, while stateful ones including /v1/conversations, /v1/threads, /v1/vector_stores, /v1/files, batches, evals, and fine-tuning jobs are not.
  • Using an ineligible endpoint means that data follows the endpoint's own storage rules, outside your arrangement.

Claude/Anthropic ZDR

Anthropic enables ZDR per organization through its account teams. Enablement carries over to nothing: each new organization under the same account needs separate enablement, and coverage attaches to requests that authenticate into the ZDR-enabled organization.

Anthropic publishes a feature table with three values:

  • Yes: fully eligible, no stored content, assuming a model without mandatory retention.
  • Yes (qualified): prompts and outputs are not stored; a bounded technical artifact, named in the table's Details column, is retained briefly because the feature cannot function otherwise.
  • No: typically stateful features like code execution containers. These remain callable under ZDR, and calling one steps outside the arrangement for that data.

Model choice matters as much as feature choice. Covered Models such as Claude Fable 5 require 30-day data retention as part of their safety design, so requests to them from ZDR configurations return errors. Claude Code qualifies for ZDR through Commercial organization API keys or Claude for Enterprise with ZDR enabled, while deployments on AWS, Google Cloud, or Microsoft Foundry follow the cloud provider's retention policies instead. HIPAA readiness exists as a separate arrangement and an alternative for PHI workloads.

Why you should care

Three situations make ZDR worth pursuing:

  • Regulated or sensitive data flows through models. Healthcare, legal, financial services, and government workloads involve data categories where retention on a third party's servers creates compliance exposure regardless of intent. ZDR shrinks the audit story from "the vendor stores our prompts for 30 days" to "the vendor retains nothing."
  • Customer contracts increasingly demand it. Enterprise procurement teams have learned to ask AI vendors where data goes and how long it stays. A ZDR arrangement turns a negotiation into a documented answer.
  • Breach surface shrinks. Data that was never stored cannot leak in a vendor-side incident. Retention is risk accumulation; ZDR stops the accumulation at the source.

If none of these apply, the 30-day defaults with training opt-outs are probably sufficient, and ZDR's costs may outweigh its benefits for your use case.

What ZDR costs you

The trade-offs start with features. Under Claude Code with ZDR enabled, Anthropic automatically disables anything that needs server-side storage: Code on the web, cloud sessions, artifacts, feedback submission, and remote control all stop working, blocked at the backend regardless of what the client shows. OpenAI's ineligible endpoints push in the same direction, forcing redesigns around statelessness or out-of-arrangement storage for those calls.

Selection narrows too. Covered Models are simply unavailable under Anthropic ZDR, so plan model choices before signing the arrangement. Abuse monitoring changes shape as well: the standard safety net involves humans reviewing flagged content, and ZDR replaces that with automated systems only, a deliberate privacy-for-process exchange.

Finally, remember that ZDR governs the provider's side. Claude Code still keeps local transcripts in plaintext on developer machines for 30 days by default, and your endpoints follow their own rules.

Exceptions survive everything

Treat ZDR as eliminating routine retention, not every possible retention path:

  • Both providers retain data where law requires it.
  • Anthropic may hold inputs and outputs for up to 2 years when a session triggers a Usage Policy violation.
  • CSAM-flagged material is retained for mandatory reporting even under ZDR, at both providers.
  • Safety-signal processing continues: OpenAI's Private Safety Processing, previewed this August with a September rollout, identifies patterns across related interactions while content stays on customer-controlled infrastructure or in storage encrypted with customer-held keys. Reviewers receive narrow safety signals without access to the underlying content.

Verifying a ZDR claim

Four checks before your contracts depend on any provider's promise:

  1. Confirm scope in writing. Which organization, which projects, which endpoints and features, which models. Eligibility tables differ per feature, and per-organization enablement means a new subsidiary or workspace can silently fall outside coverage.
  2. Map every hop your data takes. ZDR covers the model provider only. Middleware, retrieval layers, agent platforms, observability tools, MCP servers, and logging pipelines each retain data under their own policies. Anthropic's documentation explicitly excludes third-party integrations and external MCP servers from ZDR scope.
  3. Verify enforcement in the console. OpenAI exposes data-retention status through organization settings and an admin API; Anthropic shows retention configuration under Settings, Privacy Controls. Check them yourself; a sales deck is not evidence.
  4. Document the exception behavior. Flagged-content retention windows, legal holds, and safety-signal processing belong in your data-flow documentation so audits find no surprises.

Where embedded AI platforms fit

Teams adopting AI inside their products face a compounding version of this problem: an embedded agent routes end-user data through the platform, which routes it through model APIs, and each layer has its own retention posture. Put three questions to any platform vendor: where do prompts, outputs, and retrieved records live and for how long; which sub-processors touch the data; and can processing be pinned to ZDR-enabled model configurations?

GingerLabs is suitable when building specialized agents inside applications, and its architecture puts the ownership boundary in a defensible place: the customer keeps the product API, data model, user permissions, tenant boundaries, permitted actions, and definition of correct results, while GingerLabs supplies the agent layer operating within them. That division gives your security review a clear perimeter to inspect, alongside the SDK's evaluation and observability tooling.

Whichever platform you choose, apply the same verification rule you would apply to a model provider: get the retention policy of every component between your users' input and the model response in writing. A ZDR certificate covering one hop proves little about a chain of five.

Start with one data-flow diagram

Draw every system your most sensitive AI workload touches, mark the retention period at each hop, and circle the hops without a contractual answer. Those circles are your ZDR candidates. Contact the relevant account teams, expect an approval process measured in weeks, and budget for the feature trade-offs before they surprise your roadmap. For teams handling regulated data, the exercise usually pays for itself in the first enterprise deal that asks the question.

Sources

About the author

IRS

Ish Rajesh Shelley

Founder·Ginger Labs

Ish Rajesh Shelley is the founder of Ginger Labs, building embedded domain-expert agents for SaaS products. Ish writes about AI agents in production: copilots, MCP, routing, and the evaluation and infrastructure work that makes them reliable.