Zero Data Retention & Abuse Monitoring

What ZDR removes, and what it never touched.

The default on a commercial API is not "we keep nothing". It is typically a short abuse-monitoring window — thirty days is the common figure across major providers — during which inputs and outputs are retained so that automated and human review can catch misuse, after which they are deleted. Training on your commercial API traffic is a separate question and is generally off by default; conflating the two is the most common mistake in these conversations.

A zero-data-retention arrangement removes that abuse-monitoring window for eligible endpoints: the request is processed and nothing is persisted. What it has never covered is everything that is not request content — account metadata, billing records, aggregate usage telemetry, and the record that an enforcement action occurred. It also does not reach backwards: enabling ZDR today does not delete what was retained yesterday.

So the accurate sentence is "content is not persisted on these endpoints, under these conditions, going forward". If your privacy notice says something broader than that, it is wrong, and an erasure request is the moment you will find out.

"Zero" now has carve-outs, and they are growing.

The direction of travel in 2026 is the part most policies have not caught up with. As frontier-model safety programmes have expanded, providers have begun requiring retention that ZDR previously removed. Anthropic's terms, as of mid-2026, require limited retention and review for its covered models — prompts and outputs retained for thirty days to support safety work, on every platform where those models are offered — as a condition of using them, ZDR notwithstanding. Flagged traffic goes further: content associated with a suspected violation may be kept for up to two years, and trust-and-safety classification scores for as long as seven.

Read those numbers as a shape rather than as a quote, because they will move. The shape is what matters: ZDR is converging on "no routine retention", not on "no retention", and the exceptions attach to exactly the traffic most likely to be sensitive. An agent handling an unusual request — an aggressive customer, a security incident, a document about a security incident — is more likely to trip a classifier and therefore more likely to fall into the long-retention branch. That is the opposite of the correlation your data-protection assessment probably assumed.

The boundary is per call, and an agent makes a lot of calls.

A chatbot makes one kind of request. A single agent task can touch six endpoints, and each has its own retention status:

one task, six boundaries

  main reasoning model      ZDR? depends on model class
  embedding endpoint        often a different product, different terms
  reranker / classifier     frequently a third vendor entirely
  moderation / guardrail    may be outside the ZDR agreement by design
  code-execution sandbox    logs stdout somewhere; whose?
  fallback provider         the one that fires only when the first is down

The fallback is the one that gets people. A gateway configured to fail over on a 529 will, during exactly the provider incident when everyone is distracted, route your regulated traffic to a vendor with whom you have no ZDR arrangement and possibly no data-processing agreement. The failover path needs the same review as the primary — see graceful degradation and fallback — and the cheapest enforcement is an allowlist in your gateway that refuses any route not on the approved list, rather than a policy document that assumes nobody added one.

The inventory you need is therefore not "which vendors do we use" but "which endpoints does a task touch, and what is the retention status of each". Generate it from traces rather than from an architecture diagram; the diagram will be missing the reranker somebody added in June.

What you give up: the vendor's copy was also your evidence.

ZDR has a cost that rarely appears in the procurement conversation. If a customer reports that your agent said something harmful, or you are investigating whether an agent was manipulated into exfiltrating data, the provider-side record is one of the few independent accounts of what was actually sent and returned. Under ZDR it does not exist. Your logs are the only story, and they were written by the system under suspicion.

That is survivable, but only if you decide it deliberately. ZDR raises the requirements on your own observability rather than lowering them: you now need traces complete enough to reconstruct a request without the vendor, retained long enough to cover your investigation window, and protected well enough to be credible as evidence. Tracing and observability for agents covers the shape; detecting agent compromise covers what you will be looking for.

There is a second-order effect worth naming. Some providers offer reduced abuse monitoring only to customers who pass a review, and some make the ZDR tier contingent on contractual commitments about acceptable use. That is a reasonable trade, and it means ZDR is not a switch you flip — it is a relationship you maintain, and it can be withdrawn.

Your own retention is the bigger exposure, and ZDR does nothing about it.

Teams buy ZDR and then store, indefinitely, in their own systems: every prompt, every tool result, every retrieved document, every model output, plus whatever the agent wrote into memory. That store contains more of the sensitive material than the provider's thirty-day window ever did, is searched by more people, and is the one a regulator or a litigant will actually reach.

Four things follow, and none of them are the vendor's problem:

• Tool results carry other people's data. A retrieved document, a CRM record, a support ticket — the agent did not create this material and your trace store is now a second copy of it, outside whatever access controls the source system had. Permission-aware retrieval is the read-side control; trace redaction is the write-side one.
• Memory is retention you did not declare. Anything the agent persists about a user across sessions is personal data with no retention schedule unless you gave it one, and deleting it is harder than deleting a log line.
• Erasure and legal hold pull in opposite directions. A deletion request reaches your store; a hold freezes it. Decide the precedence before both arrive — retention and legal hold.
• Redact at write time. Redaction applied when someone opens a trace is not redaction. Do it in the pipeline, sample to check it works, and measure the miss rate, per redacting PII from agent traces.

Make the claim testable.

A retention posture that exists only in a contract is a posture you will discover is wrong during an audit. Three mechanisms turn it into something you can demonstrate.

First, per-model attestation. Ask for, and file, a statement of retention behaviour per model and per endpoint you use, with an effective date, and re-request it at each contract cycle and each model adoption. A single account-level letter is not evidence about the embedding endpoint.

Second, enforcement in the path. Put the approved endpoint list in the gateway and make anything else fail closed. Then write a test that proves it: a request routed at a non-approved model should be refused, and that test should run in CI like any other. A control you have not tried to break is an assumption.

Third, a documented data map at task granularity. For one representative task, list every endpoint touched, what content leaves for each, the retention status, and the legal basis. This is the artefact that answers a data-protection assessment, a customer security questionnaire and an inspector's question with the same page — and producing it is usually how a team discovers the reranker.