Anthropic Zero Data Retention: Build a Route-Level Acceptance Record
Anthropic zero data retention applies to a named organization and agreement, then to an endpoint with defined capabilities. Messages and Token Counting can qualify. Batch and Files carry separate retention treatment, as do code execution, MCP connectors, and other stateful tools. This guide builds a route-level acceptance record and a repeatable validation test.
Anthropic zero data retention is a contractual and technical property of a particular organization and endpoint with a defined capability set. The same Claude logo appears on surfaces with different retention treatment. Anthropic's current API documentation marks standard Messages and Token Counting as ZDR-eligible. Batch and Files receive separate treatment. Server-side code execution and MCP connectors also sit outside ZDR, along with other stateful tools. I would reject any vendor assessment that stops at a signed ZDR addendum. The useful artifact is a route-level acceptance record tied to the credential and request you will run in production.
TL;DR
- Confirm ZDR for the exact Anthropic organization and contract. Coverage does not automatically extend to another organization under the same account.
- Record the product, credential route, endpoint, enabled capability, published eligibility, retention exception, evidence, named owners, review date, test result, and change trigger.
- Messages and Token Counting can qualify. Batch and Files need separate retention review, along with code execution, MCP connectors, and stateful tools.
- A gateway can enforce an approved route and preserve independent request evidence. Anthropic still owns enrollment and provider storage plus deletion and trust-and-safety retention.
Start with the agreement and organization
Anthropic's API and data retention documentation says eligible customers receive ZDR through an Anthropic agreement and that the arrangement applies to the organization named in that agreement. Coverage for one organization does not automatically extend to other organizations under the same account.
Put the legal entity, Anthropic organization ID, agreement identifier, effective date, covered product, and procurement owner at the top of the acceptance record. Then identify the production credential and the organization it resolves to. A contract PDF in a procurement folder and an API key in a secret store can point at different organizations. That mismatch is small on screen, perhaps two strings in separate browser tabs, and large during an incident.
Anthropic's commercial product-scope explanation covers certain Claude API and Claude Code Enterprise arrangements. Consumer accounts on Claude Free and Pro plus Max sit on a different surface. Record the product name without shortening it to "Claude."
Build the endpoint and capability inventory
Create one row for every production route. At minimum, capture:
- Anthropic organization and agreement
- Product and credential route
- Endpoint and request mode
- Enabled capability or tool
- Published ZDR eligibility
- Published retention treatment or exception
- Validation request and retained evidence
- Technical owner and procurement owner
- Change trigger and next review date
The capability field carries the route decision. Anthropic currently lists /v1/messages and Token Counting as eligible for ZDR when the request uses approved tools. Fast mode uses the same Messages endpoint and remains eligible. Client-side tools such as a bash tool running in your own environment can retain eligibility because Anthropic processes the model call while the tool executes locally.
Batch processing requires asynchronous storage and has a published 29-day retention period. The Files API retains files until deletion or configured expiration. Server-side code execution and the MCP connector are marked outside ZDR in the eligibility matrix. A request sent to /v1/messages can therefore fall outside coverage because of the tool enabled inside its body.
Keep default retention and ZDR separate
Anthropic's organization data-retention article states that standard API inputs and outputs are automatically deleted from the backend within 30 days, subject to listed exceptions. A ZDR agreement changes that treatment for covered routes. The two states belong in separate acceptance fields.
The record should say "ZDR eligible under agreement X" or "standard API deletion within 30 days," rather than collapsing both into "Anthropic does not retain data." Services with customer-controlled storage, such as Files, have their own lifecycle. Commercial workspaces that save product history also need their own review.
Trust-and-safety and legal exceptions remain part of the record. Anthropic says a chat or session flagged by automated trust-and-safety systems may be retained for up to two years, with classification scores retained for up to seven years. Covered Models can also have limited retention and review requirements for safety work. Preserve the applicable wording and source date beside the route. ZDR is a defined provider treatment with stated exceptions, not proof that no byte can ever persist under any condition.
Run an acceptance test on the production route
A good ZDR test proves configuration and evidence quality without pretending to inspect Anthropic's storage layer. Use a synthetic prompt containing a unique canary string and no sensitive data. Send it through the exact production credential, host, endpoint, request options, and enabled tools. Retain request and response metadata plus the organization identifier, timestamp, model, endpoint, capability flags, and application release.
Then compare that request to the current Anthropic eligibility matrix. The control passes when the organization has the agreement, the route is covered, every enabled tool is eligible, and the evidence identifies the request unambiguously. A test against plain Messages cannot approve Batch or a later request that adds mcp_servers.
I would also run a controlled negative test in a nonproduction organization. Add one known ineligible capability and confirm the acceptance check rejects the route before sensitive data reaches it. A policy that approves every /v1/messages call based only on the path has encoded the wrong decision unit.
Attach the output to the AI vendor security questionnaire rather than answering its retention question with a bare "yes." For a wider vendor comparison, keep the route-specific record separate from the workspace controls discussed in Anthropic versus OpenAI enterprise controls.
Set change triggers before approval
Retention approval expires when a material part of the route changes. Define the triggers in advance:
- A new Anthropic organization or API key
- A change to the endpoint or model family, including a new request mode
- Batch, Files, code execution, MCP, or another stateful tool added
- A contract renewal, amendment, downgrade, or account migration
- A change to Anthropic's eligibility matrix or exception wording
- A new application release that changes request construction
Assign one technical owner to rerun the route test and one procurement or privacy owner to confirm the agreement. Store the evidence beside the deployed route configuration, not only in a yearly questionnaire. The LLM audit log retention decision also needs separate treatment because your own request evidence may have a longer retention requirement than the provider's content.
Draw the enforcement boundary correctly
A customer-controlled gateway can restrict an application to an approved Anthropic host and endpoint plus a defined model and capability set. It can bind the request to a verified caller, classify the data, block an unapproved route, and retain evidence that a particular request matched the approved policy.
The gateway cannot enroll an organization in Anthropic ZDR, change Anthropic's deletion process, inspect provider storage, or override trust-and-safety and legal retention. Batch storage, Files lifecycle, Anthropic-hosted code execution, MCP activity, workspace history, and local Claude Code state remain distinct surfaces. A separate model call enters the gateway boundary only when the application deliberately routes that authenticated HTTP call through it.
DeepInspect
DeepInspect can turn the acceptance record into request policy. For a routed Claude API call, it evaluates caller identity and data class against the approved Anthropic organization, endpoint, and capability profile before forwarding the request. The resulting audit record shows which policy version approved or blocked that call.
That evidence shows whether a production request used the route approved for Anthropic ZDR. Anthropic remains responsible for the provider-side agreement and retention behavior. DeepInspect supplies independent evidence at the customer-controlled HTTP boundary and can fail closed when a request adds an unapproved capability.
Book a demo today.