Anthropic Relaxes 30-Day Data Retention Policy

Anthropic is revising an enterprise data policy that it tightened just two months ago.

According to an August 20 local-time report by Bloomberg, Anthropic plans to allow enterprise customers to store traffic data generated by frontier models—including prompts and outputs—in their own cloud infrastructure rather than requiring it to be stored in Anthropic’s facilities. The related security system is expected to launch later in 2026.

One thing must be made clear upfront: this does not restore Zero Data Retention (ZDR).

For frontier models designated by Anthropic, enterprise customers will still be required to retain data for up to 30 days. What is changing is that the data will no longer have to leave the customer-controlled cloud environment. In other words, Anthropic has not abandoned its security approach of retaining logs to investigate attacks; it is simply returning control over storage location, access boundaries, and some governance rights to customers.

This may look like a mere change in deployment, but it directly affects one of the most sensitive issues in enterprise adoption of large language models: who truly controls prompts and model outputs.

From Mandatory Retention to Enterprise-Managed Storage

In June, Anthropic began enforcing a stricter data retention policy for Claude Mythos 5, Claude Fable 5, and subsequent frontier models deemed to have similar capabilities. Even if an enterprise had previously secured a ZDR arrangement, prompts and outputs associated with these models had to be retained for 30 days for trust and safety analysis.

Anthropic’s rationale was not unreasonable.

More capable models are not merely “better at chatting.” They are also better at writing exploit code, breaking down attack chains, finding weak configurations, and decomposing a complex task into dozens or even hundreds of seemingly harmless requests. Many high-risk behaviors cannot be identified from a single API call; context must be connected across requests.

For example, a request asking a model to modify a PowerShell script may simply be part of routine IT operations. But dozens of consecutive requests involving credential extraction, lateral movement, log cleanup, and data exfiltration tell a very different story. Another example is Best-of-N jailbreaking, in which attackers generate prompts with only subtle differences in bulk and repeatedly probe safety boundaries. If records are deleted immediately after each request, the platform will struggle to identify such low-frequency, distributed, but persistent behavior.

The core value of 30-day retention, therefore, is not the ability to review a specific sentence, but to establish security visibility across interactions.

The problem is that while this logic makes sense to security teams, it may not be acceptable to enterprise legal, compliance, and procurement departments.

Content sent to a model by an enterprise may include:

• Unreleased source code, vulnerability reports, and infrastructure configurations;
• Customer information, transaction records, medical records, or legal documents;
• Internal meeting minutes, M&A materials, and product roadmaps;
• Database query results, tool outputs, and access tokens generated during agent execution;
• Excerpts from private knowledge bases retrieved by retrieval-augmented generation systems.

Anthropic promises not to use this enterprise data to train its models, but “not used for training” and “not stored” are two different things. For regulated industries, the risks do not come solely from training-related leakage. They also include cross-border transfers, internal access, government requests, misconfigurations, data breaches, and the allocation of liability after a vendor security incident.

This is why the new policy introduced in June prompted pushback from some enterprise customers. It changed more than a technical default: it could also force customers to redo data protection impact assessments, update processing agreements, and even modify the architecture of systems already in production.

What Exactly Does the New Approach Change?

Based on the information disclosed so far, Anthropic’s new approach can broadly be understood as “customer-hosted data retention.”

Under the previous data flow, an enterprise application might call a model, Anthropic would retain specified traffic in its own facilities, and its security systems would then perform correlation analysis on those records. The new approach allows enterprises to keep the 30 days of data in their own cloud accounts or controlled environments, with risk detection conducted through a security mechanism jointly operated by both parties.

Both approaches retain logs, but their trust boundaries are entirely different.

If the system is implemented as enterprises expect, customers could gain at least the following benefits:

1. Data residency becomes easier to explain. Financial institutions, healthcare organizations, government agencies, and multinational enterprises can keep data within designated regions, cloud accounts, or compliance boundaries.
2. Access control returns to the enterprise IAM system. Decisions about who can read or export data and who can approve security investigations can be integrated into the enterprise’s existing identity and access management framework.
3. The audit trail becomes more complete. Data access can potentially be recorded in the customer’s own logs, SIEM, and compliance auditing systems rather than relying solely on reports supplied by the vendor.
4. Deletion policies become more verifiable. Whether data is deleted after 30 days can be enforced through the enterprise’s own lifecycle policies and key-management mechanisms.
5. Vendor concentration risk is reduced. Large volumes of high-value prompts no longer accumulate exclusively on the model vendor’s side, reducing the likelihood of creating a data “honeypot.”

However, this adjustment does not fully resolve the issue.

The most important unanswered question is: How will Anthropic obtain sufficient cross-request security signals without holding the data itself?

Possible approaches include deploying security classifiers in the customer’s cloud, converting raw content into risk labels before uploading them, using isolated computing environments, or allowing controlled review only after a high-risk threshold is triggered. These approaches differ significantly in their implications for privacy, performance, cost, and verifiability.

If the change merely places the storage bucket in the customer’s account while giving Anthropic long-term access to the raw content, it would be more like “moving to a different data center” than providing meaningful customer control. The value would be far greater if security analysis were performed primarily within the customer environment, with only minimal risk signals returned to Anthropic.

Enterprises should therefore look beyond the marketing claim that “the data is in your cloud” and examine the following four permissions:

• Whether Anthropic can directly read raw prompts and outputs;
• What conditions trigger human review;
• Whether customers can refuse, suspend, or audit access;
• Who ultimately controls the encryption keys.

In cloud security, the physical location of data is not the whole story. As long as the vendor retains decryption capabilities and read permissions, control may still effectively remain with the vendor.

This Is Not ZDR, but It Is More Acceptable Than Mandatory Log Handover

Anthropic’s adjustment is essentially a pragmatic compromise between security and sales.

Mandatory 30-day data retention helps investigate jailbreaks, espionage, ransomware, and other cross-request attacks. But requiring all records to enter Anthropic’s own infrastructure directly undermines Claude’s competitiveness among large enterprises. For customers that have already completed compliance approval based on ZDR, a sudden policy change means reassessing the vendor.

Meanwhile, OpenAI is advancing an approach that enables security detection without centrally retaining customer data. The differences between the two companies’ strategies are becoming increasingly clear: Anthropic favors exchanging 30 days of context for more comprehensive investigative capabilities, while OpenAI is attempting to move security analysis earlier in the process and identify cross-interaction risks while persisting less raw data.

From an enterprise procurement perspective, the latter is easier to explain. From a security research perspective, the former may preserve more investigative evidence. It is not yet possible to determine which system is more effective based on policy descriptions alone. The real deciding factors are detection recall, false-positive rates, the cost of evasion for attackers, and whether the full chain of events can be reconstructed after a serious incident.

By allowing customers to self-host retained data, Anthropic is effectively bringing the two approaches one step closer together: raw records still exist, but they do not all have to be entrusted to the model vendor.

Our assessment is that this change is useful and necessary for Anthropic, but it is more of a correction to the commercial friction caused by the June policy than a breakthrough in privacy technology.

It addresses data sovereignty and centralized storage concerns, but it does not eliminate the compliance burden created by 30-day retention itself. For organizations that genuinely require raw content to be deleted immediately after a request is completed, the new approach still does not constitute ZDR and may not pass internal review.

Why the Agent Era Makes Logging More Difficult

If an enterprise only occasionally asks employees to polish emails, 30-day retention may seem to have limited impact. In agent-based applications, however, a single task may trigger dozens of tool calls, with model inputs and outputs containing a mixture of business data, database results, web content, code repository excerpts, and identity credentials.

At that point, “model traffic” is no longer just a chat history; it becomes a mirror of the enterprise’s business processes.

Suppose a customer service agent needs to issue a refund. It might sequentially read the user’s identity, order history, payment information, and risk-control labels before calling an internal API to update the status. If the entire trace is retained, the logs may contain far more information than the final response. Redacting only the final reply will not cover the intermediate steps.

More importantly, enterprises often cannot determine the applicable data policy solely from the model name. Anthropic’s rules apply to models it classifies as having frontier capabilities. Future model upgrades or routing changes could alter retention requirements. A workload that originally met ZDR requirements could immediately become subject to 30-day retention after switching to a more capable model.

Development teams can therefore no longer treat data retention as a footnote in procurement contracts. It should be incorporated into model gateway and agent architecture design:

• Select models based on data sensitivity rather than routing every request to the most capable model;
• Apply field-level redaction before calls to avoid sending full identity information, keys, and original documents to the model;
• Separate prompt logs, tool-call logs, and business audit logs, and assign different retention periods to each;
• Create dedicated workspaces, cloud accounts, and access policies for frontier models;
• Apply compliance checks to model version upgrades to prevent retention rules from changing silently with routing;
• Do not misrepresent “the vendor does not use the data for training” as “the data will not be stored.”

For enterprises using Claude, GPT, Gemini, and other models simultaneously, a unified gateway offers another practical benefit: it creates an enterprise-controlled policy layer between applications and model vendors. Different workloads can be routed dynamically based on retention requirements, region, cost, and capability, without tying data governance to the default settings of any single vendor.

The Ten Questions Enterprises Should Ask Now

The new system has not yet officially launched, and Anthropic has not disclosed complete technical or contractual details. At a minimum, enterprise customers evaluating it should demand clear answers to the following questions:

1. Which models, API features, and cloud channels are subject to mandatory 30-day data retention?
2. Does the retained data include system prompts, tool parameters, files, caches, and model outputs?
3. Does the data always remain in the region and cloud account designated by the customer?
4. What cross-account permissions does Anthropic require, and can it access raw content?
5. Are customer-managed keys supported, and can customers revoke decryption permissions at any time?
6. Does risk detection run in the customer’s cloud, Anthropic’s cloud, or a trusted isolated environment?
7. Which security events trigger human review, and what are the approval and auditing processes?
8. After 30 days, how can customers verify that raw data, indexes, backups, and derived features have all been deleted?
9. Can legal holds or security investigations override the 30-day limit, and what is the maximum retention period?
10. How is data migrated and destroyed when a customer leaves the service, switches models, or experiences a failure?

Ambiguity in any of these areas could reduce “storage in your own cloud” to little more than a marketing claim.

Anthropic Holds Its Ground on Security While Acknowledging That Enterprises Will Not Yield Unconditionally

From mandatory retention in June to the current development of a customer-hosted approach, Anthropic has not withdrawn its assessment of frontier-model risks: the more powerful a model becomes, the more likely it is to be used in sophisticated cyberattacks, and cross-request detection requires a certain time window.

What it has changed is the allocation of responsibility.

The previous logic was that Anthropic needed centralized control of data to secure the platform. Under the new logic, enterprises can retain the raw data themselves while cooperating with the security system to perform detection. This change acknowledges one reality: in the enterprise AI market, security cannot be defined unilaterally by model vendors; customer data sovereignty is itself part of the product’s capabilities.

Anthropic has reportedly coordinated the development of this system with more than 100 customers, including Salesforce. This type of co-design matters to large enterprises because they do not need a simple privacy toggle; they need infrastructure that integrates with their existing cloud security, identity management, auditing, and incident response processes.

The key issue to watch is not whether Anthropic launches the system on schedule, but how much implementation detail it discloses. If it offers only policy commitments without an auditable permissions model, deployment architecture, and proof of deletion, large customers will remain cautious. If it can genuinely move security detection into customer clouds, however, it could establish a new delivery standard for frontier models.

The 30-day retention requirement will not disappear, but at least enterprises will no longer have to hand over all 30 days of their most sensitive data.

References

• ITHome: Anthropic Reportedly Plans to Revise Data Retention Policy, Allowing Customers to Store Data in Their Own Infrastructure—An overview of Anthropic’s proposed enterprise self-hosted cloud retention approach, the 30-day retention requirement, and the background to the policy change.