A developer adds one line to a request on a Monday morning. mcp_servers, so Claude can pull something from your own system. The response comes back complete. No error, no warning.
The company has a zero data retention arrangement. That request was not covered by it. And from the API's side, nothing went wrong.
This is not a bug in Anthropic's system. It is written down in their own table. I want to spend the next few minutes showing you exactly where, and what you can do about it this week.
Who actually has one of these arrangements?
Start here, because if the answer is no, you can read the rest as background.
An arrangement like this, ZDR in Anthropic's own shorthand, is not a setting you switch on. You ask Anthropic's sales team for it, and they enable it per organisation. If you have two organisations in Console, it covers one of them. It does not follow along when you create a new one.
And here is the part most people have backwards: Claude does not store your conversations by default. Anthropic says so in their own list of commitments. Conversation content is not retained unless a feature requires it.
The exception is the newest models. Claude Fable 5.1 and Mythos 5.1 were designated Covered Models on 31 August. They require 30-day retention and cannot run under ZDR, unless Anthropic has expressly authorised it for your organisation. So the 30 days belongs to the model, not to the absence of an arrangement.
The rule is not new either. Fable 5 and Mythos 5 were designated back on 9 June. What arrived on 5 September was the instructions for living with it.
The platform enforces one arrangement. Your developer enforces the other
Anthropic offers two arrangements on the API. ZDR, and something called HIPAA readiness for companies handling health information. Both have a table of which features are covered.
It is the same table. And the platform does not behave the same way.
When a HIPAA-ready organisation sends a request containing a feature that is not covered, it gets an error back:
"The requested features are not available for HIPAA-regulated organizations without Zero Data Retention: code_execution."
When an organisation with ZDR sends exactly the same request, nothing happens. It goes through. Anthropic's own wording is that using the feature "is a choice to step outside your ZDR arrangement for that specific data".
One clarification so nobody catches you out on it: HIPAA does not block everything either. The table has a details column, and browser use is let through on purpose. But all eight features I am about to walk through are blocked under HIPAA. The comparison holds exactly where it matters.
There is one more place where the platform genuinely does refuse. Set a list of allowed geographies on a workspace, and if somebody sends a request naming a geography that is not on the list, they get an error. Same platform, same workspace, two boundaries you configured yourself. Anthropic enforces one. Whoever wrote your integration enforces the other.
The eight features that are not included
The table has 35 rows. Eight of them are marked as not covered:
Agent skills. Batch processing. Claude Managed Agents. Code execution. The Files API. The MCP connector. MCP tunnels. Programmatic tool calling.
Read them as one connected agent surface rather than as a list. They are precisely the parts a modern Claude integration gets built from.
Two of the eight are the same call, incidentally. Code execution and programmatic tool calling both go through /v1/messages with code_execution. Eight rows, but two of them you find in the same place.
Three of them are the ones a Danish SMB of 40 people realistically touches:
The Files API. Every time you send a PDF or a spreadsheet to Claude as a file rather than pasting the text in, the file is stored with Anthropic under that feature's own documented policy.
The MCP connector. How you wire Claude to your own CRM, your order system or your document archive. It is the one from the example at the top.
Code execution. Every time Claude has to calculate something, draw a chart or process a file, it runs in a persistent container, and the contents are retained under that feature's own documented policy.
Batch processing is the fourth one I want to name, because the number is slightly funny: 29 days of retention. Not 30. It is in the details column.
The arrangement stops at the API
Here is the other half, and it lands wider.
ZDR is an arrangement about the API. It does not cover the places your people actually sit and work.
Claude Console is not covered, including the playground inside it where plenty of people test their prompts. The Claude Teams and Claude Enterprise interfaces are not covered, and Anthropic states that directly. Claude for Excel is not covered.
So a company that negotiated ZDR into place for the development team does not have that protection for the employee who opens Claude in a browser and pastes in a customer letter.
And one thing holds no matter what you sign: if a conversation is flagged by Anthropic's automated safety systems, they may keep it for up to two years. Neither an arrangement nor a checkbox moves that one.
If you want to know what gets stored from what your people do inside the Claude app itself, I wrote about the Compliance API and session transcripts last week.
The European option sits outside the arrangement
This is the part that is sharper for us than for an American reader.
European data residency exists. It is on AWS Bedrock and GCP Vertex, and it is available today. Microsoft Foundry is marked Coming 2026 for Europe in the table, even though the prose on the same page names Foundry alongside the other two. Anthropic states that regional data residency is available across Europe, and that they support GDPR with regional processing within the EU and EEA.
So far so good. The problem is where it sits.
On Bedrock and Vertex, the cloud provider is the data processor, not Anthropic. Anthropic's two arrangements therefore do not apply there at all. Anthropic points you instead to the provider's own documentation for the equivalent controls, and you should read it, because the protection exists, it just lives somewhere else.
At the same time, ZDR is not available on third-party platforms where Covered Models can be accessed.
And on Anthropic's own API, where the arrangement actually lives, you can choose between "us" and "global". That is the whole list. A workspace can only sit in "us", and that cannot be changed after the workspace is created. Choose "us" and tokens cost 1.1 times the standard rate. The setting exists only on Claude 4.6 and later, and so does the price.
Put those two things together. The row in the table covering data residency is marked as included under zero data retention. So it looks green. But it has no European value to choose. The United States is one option. The other is "global", which means anywhere. Europe is not on the list.
Find out which of the eight your integration calls
You can do this today, and you do not need permission from any supplier.
Ask whoever built your integration to search the code for eight things: /v1/files, mcp_servers, code_execution, /v1/messages/batches, skills, /v1/agents, /v1/sessions and /v1/tunnels.
It takes ten minutes. Then you know.
For each hit there are three outcomes, and they are not equally sized:
Stop calling it. The cheapest, if the feature is not necessary. A PDF can often be sent as text rather than as a file.
Move it. Anthropic documents one route out, and it covers Managed Agents: self-hosted sandboxes, where tools and the filesystem run on your own infrastructure. Note the caveat, because it is in their own text: the contents of attached memory stores are still stored by Anthropic and copied into the sandbox for the session. That moves most of it, not all of it.
Accept it, and write it down. For most of the eight this is the answer. Put a line in your record of processing activities and in your data processing agreement saying that this specific data sits outside the arrangement. That is not a defeat. It is the difference between a hole and a documented exception.
Leaving your own arrangement takes no signature
There are two ways to step outside your own arrangement, and neither of them goes past the person who signed the data processing agreement.
The first is the toggle. An administrator opens Console, finds a workspace other than the default one, opens Privacy controls and switches on 30-day retention. A dialog appears asking them to accept Service Specific Terms Section F. Then Fable 5.1 works in that workspace. Without retention switched on you get this error:
"In order to access this model, your organization or workspace must have data retention enabled."
The toggle takes effect immediately, and in rare cases within an hour. It only applies going forward, so what you have already sent does not suddenly get stored. And it can be switched off again, with one exception: if you have customer-managed encryption keys configured, the option disappears. That is stated in Anthropic's help article rather than in their developer documentation, so you have to look in the right place.
The second way is that one line of code from the example at the top. No dialog. No acceptance. No notification to anyone.
For comparison: switch on HIPAA readiness and it is permanent. An administrator cannot switch it off again. Two doors on the same settings page, behaving differently.
Your retention policy lives in a file in your own repository
Open the file where your integration assembles its request to Claude. The one nobody has looked at since it was written.
Your data processing agreement is not in that file. But the eight lines that decide whether it holds are. Your retention policy is in practice whatever that file calls, and it was last decided by a developer on a Monday morning.
That is the kind of review I do under internal AI tools: mapping what your integration actually touches, and who can change it without asking.
FAQ
Frequently asked questions
It is an arrangement where Anthropic does not store your prompts and Claude's outputs after the response is returned. You agree it with Anthropic's sales team and it is enabled per organisation. It covers the API, not Console and not the Claude app.
Two of Anthropic's pages say things that sound different, so here are both. The help article says retained data "may be accessed by Anthropic for safety purposes". The page on retention practices says that "by default, no Anthropic personnel can read your retained conversations". The reconciliation is that the default is no. Anthropic describes access as a controlled pathway that opens when an automated system flags something. They say it is limited to a small set of approved reviewers, and that every access is written to a log those reviewers cannot alter.
No, it is a processing fact rather than a breach in itself. It needs to appear in your record of processing activities and match your data processing agreement. This is not legal advice, and if you have a DPO this is exactly the sort of thing they should see.
Yes, but the opposite way round from what most people assume. A ZDR arrangement does not cover the Claude app or Console at all, so having one does not help you there. On the other hand Claude does not store conversation content by default, unless you are using one of the newest models.
No, not with a ZDR arrangement. Anthropic does not support CORS for those organisations, so the calls have to go through your own server instead, which most people should be doing anyway to protect the API key.
No, not if you have ZDR. Anthropic states that the Compliance API does not capture local sessions where ZDR is in effect, nor any local sessions from HIPAA-ready organisations. Anthropic states a six-year retention period for the Compliance API, and it applies only to what that API does hold.
Most of them. Computer use, browser use, web search, web fetch, the memory tool, the bash and text editor tools, prompt caching, PDFs sent inline in the message, and data residency are all included. 25 of the 35 rows are a plain yes, two are yes with conditions, and eight are these. This is not an article about nothing working.
Anthropic announced it on 1 September and says it is rolling out in phases starting later this autumn. It keeps data in your own cloud under your own keys. There is a form you can send, and it says directly that completing it is no guarantee of access. Until then, organisations eligible for ZDR can get retention-free access to Fable 5 and 5.1, and they can stay on the previous models under their existing agreements.
Sources
Covered Models, the model list and the designation dates →
Data retention practices for Covered Models, on access and review →
Data residency, the geography values and the price of the United States →
Regional compliance, the region availability per platform →
Developing Enterprise Frontier Safeguards with our customers, Anthropic, 1 September 2026 →
