What ZDR Actually Proves After NVIDIA Restricted Frontier Models

This Is Not a Full Ban by NVIDIA on the Two Model Companies

On September 14, The Information reported that companies including NVIDIA, Palantir, and Booz Allen Hamilton are limiting or re-evaluating their use of frontier models from Anthropic and OpenAI due to data and intellectual property risks; Reuters subsequently relayed this news. The Information’s original report is restricted behind a paywall, so the publicly available Reuters relay is better suited for confirming the event’s framework rather than treating every detail as an official corporate announcement. Reuters relay

When the report is broken down, the strength of the evidence varies:

Therefore, the statement “Nvidia restricts Anthropic and OpenAI” needs to be split into at least two layers: the first layer is the corporate risk review described in media reports; the second layer is the product and internal deployment actions that Nvidia has publicly confirmed. Merging the two layers would mistakenly write “reportedly,” “under negotiation,” and “already implemented” as the same fact.

This is not simply an anti-Anthropic campaign. In November 2025, NVIDIA announced a strategic partnership with Anthropic and Microsoft, and NVIDIA also participated in the relevant investment arrangements. The partnership information published by Anthropic shows that business relationships and data boundaries are two different things: a supplier can be a partner while sensitive data still may not be handed over to it for processing.

The Turning Point is Fable’s 30 Days

The timeline of this incident reveals more than a news headline could.

The key date here is June 9. Anthropic’s explanation for Fable 5 and Mythos 5 is that looking at individual requests alone is not sufficient when facing risks such as multi-turn abuse, cross-request correlation, Best-of-N jailbreaks, and data extortion. Therefore, prompts and outputs need to be retained for 30 days to detect and defend against complex new types of attacks. Anthropic’s Explanation of Access Policy for Fable and Mythos

These 30 days are not equivalent to “using it to train models.” Anthropic publicly states that the retention of Covered Models is not for training new Claude models or other non-safety purposes; by default, humans cannot directly read these conversations either—only when a controlled trust and safety process is triggered may they be reviewed, and access will be logged. Anthropic’s Covered Models Data Retention Explanation

But for enterprises, the risk question has shifted: whether raw data will become training corpora is one issue; whether the vendor can retain it, correlate it, and retrieve it in a security incident within the next 30 days is another. What enterprises are demanding with “irrevocable ZDR” targets precisely this latter issue.

First, Separate the Four “Do Not Touch the Data” Scenarios

Vendor privacy pages often bundle multiple commitments into a single enterprise package, and it’s easy for readers to compress them into the phrase “data security.” In reality, there are at least four distinct issues:

OpenAI’s platform documentation states these differences plainly: API data is not used for training by default, but abuse monitoring logs are typically retained for up to 30 days; eligible organizations can apply for ZDR so that customer content does not enter abuse monitoring logs, while different endpoints still have different application statuses and storage rules. /v1/responses and /v1/chat/completions are handled as non-stored under ZDR, but threads, vector stores, files, and other stateful features cannot automatically receive the same treatment. OpenAI Platform Data Controls Documentation

Anthropic’s approach is similar, but the frontier Covered Models make the exceptions more prominent: eligible API organizations can apply for ZDR, and standard APIs typically auto-delete inputs and outputs within 30 days; however, Fable 5/5.1 and Mythos 5/5.1 by default require retention of at least 30 days unless the customer secures a specific arrangement. Anthropic API Data Retention Documentation Anthropic’s ZDR Scope Description

Therefore, ZDR is not a context-free model property, but rather a conditional service contract and technical configuration: whose organization, which API, which model, whether it is stateful, and whether it triggers security or legal exceptions must all be spelled out.

How Various Vendors Previously “Proved” ZDR

Strictly speaking, vendors have not provided a mathematical proof that “not a single byte on the server has ever been written to disk.” What they offer is a verifiable, auditable, and accountable chain of evidence. Enterprises typically perform acceptance review across the following layers.

This has been the basic approach used by various vendors to “prove” ZDR: rather than asking customers to trust a slogan, they are asked to examine the correspondence between contracts, configurations, architectures, logs, and third-party audits. If any layer is missing, the promise may remain nothing more than marketing language.

Anthropic: Organizational-Level Agreements, plus Product Eligibility Table

Anthropic’s most easily understood ZDR (Zero Data Retention) policy has historically applied to approved commercial API organizations: inputs and outputs are not retained in static storage after the response is returned, and results from safety classifiers, along with exceptions related to legal, abuse, and harm matters, are handled separately. Customers can confirm the data retention period in their organization settings, but this does not mean that all products automatically inherit ZDR.

Fable 5 publicly tore open this boundary: the 30-day retention requirement for Covered Models takes precedence over ordinary ZDR expectations, and Anthropic explicitly attributes this to the safety defense needs of frontier models. The subsequently introduced Enterprise Frontier Safeguards attempt to hand over safety signals to the customer’s own S3, Azure Blob, or Google Cloud storage, giving customers control over keys, access policies, and audit logs. Enterprise Frontier Safeguards Announcement

The direction of this new program is valuable, but it cannot be written up in advance as a universally fulfilled ZDR: the official statement is a phased rollout for eligible customers; until the program is ready, some customers temporarily receive ZDR arrangements from Fable, and Anthropic reserves the right to adjust or withdraw arrangements due to abuse risk. The media’s claim of “irrevocable” hits exactly this governance gap.

OpenAI: No Training by Default, 30-Day Abuse Logs, and Endpoint-Level Exceptions

OpenAI’s enterprise messaging around its APIs has long centered on three things: commercial API data is not used for training by default; abuse monitoring logs are typically retained for at most 30 days; and eligible customers can apply for Zero Data Retention (ZDR) or Modified Abuse Monitoring. Enterprises can also cross-check the vendor’s security controls and audit mechanisms through materials such as the DPA, data processing terms, SOC 2 Type II, and ISO certifications. OpenAI Security and Privacy OpenAI Data Processing Addendum

The place where things truly tend to go wrong is at the endpoints. Just because the chat completion and response interfaces can be handled under ZDR doesn’t mean that conversations, threads, vector stores, files, and Agent state aren’t stored. OpenAI’s recently announced ZDR scheme for frontier models has also introduced Private Safety Processing: the goal is to extract safety signals across interactions within infrastructure controlled by the customer, or in storage where the keys will be controlled by the customer in the future, while trying to prevent OpenAI team members from seeing the raw content. OpenAI’s notes on ZDR for frontier models

However, as of the time of writing, Private Safety Processing remains a preview direction, with the technical white paper scheduled for release in September 2026. It illustrates the contradiction OpenAI is trying to address, but it cannot yet help enterprises complete their acceptance checks. What enterprises still need to see are the final endpoint lists, data flows, exception rules, and operational evidence that can be independently reviewed.

Cloud Platform: Turning “Proof” into an Executable Pattern

AWS Bedrock’s approach is closer to engineering acceptance. It categorizes data retention modes as none, default, aws_review, and provider_data_share; among them, none means AWS does not persistently store requests and responses, nor shares them with model providers. More importantly, store=false itself does not automatically guarantee zero retention—the model will also determine availability based on the allowed retention mode; current Fable 5/5.1 requires a specific review mode and may be directly unavailable under strict none or default settings. AWS Bedrock Data Retention Modes

Google’s documentation also requires customers to handle exceptions themselves, such as logs, Search grounding, Maps data, and conversation caching. Microsoft, on the other hand, provides Modified Abuse Monitoring, which reduces human review in highly sensitive scenarios, but acknowledges that this reduces the ability to detect abuse. Google Agent Platform ZDR Documentation Microsoft Foundry Abuse Monitoring Documentation

These examples together illustrate one thing: a trustworthy ZDR is not “there’s a green toggle on a webpage,” but rather a system that can refuse to invoke, narrow its capabilities, or explicitly surface exceptions when the conditions are not met. Whether the model can be kept out of strict retention mode is often closer to real proof than a vendor claiming “not used for training by default.”

Why Frontier Models Are Cornering Old Answers

The security assumption behind traditional APIs is simple: a client sends a request, the model returns a result, the platform performs abuse detection within a short window, and then deletes the content. This assumption still holds for single-turn Q&A, but frontier models are increasingly behaving like agents that continuously read files, invoke tools, execute code, and maintain context. Attackers are no longer just sending a single jailbreak prompt; instead, they stitch together many seemingly ordinary requests, gradually gaining privileges, probing boundaries, and then combining the results.

Anthropic’s explanation of Fable’s 30-day retention essentially says this: if no cross-request signals are retained at all, it becomes very difficult to identify this kind of pattern. OpenAI’s Private Safety Processing represents a different answer: the safety system can recognize that “a risk has occurred,” while trying not to touch the customer’s original content. Both approaches acknowledge the same fact—safety monitoring of frontier models requires more context, while enterprise privacy requirements do not allow that context to flow back to the model provider without limits.

Nvidia’s move of sensitive supply chain data onto Nemotron isn’t about “Nemotron being smarter than Claude or GPT,” but about the trust boundary being different. The solutions published by Nvidia and Palantir emphasize that proprietary data, model weights, and inference services can live in the same governed environment; Nvidia’s own technical notes also state that supply chain decisions and outcomes are used for Nemotron’s post-training. Nvidia and Palantir’s supply chain announcement Nvidia’s technical note on Nemotron supply chain deployment

The costs have also been transferred: enterprises no longer just need to review vendors—they are now responsible for model updates, red team testing, permission layering, log retention, fault recovery, and security incident response. The so-called “in-house AI is safer” is more accurately stated as “raw data does not need to leave your own governance boundary”; security does not automatically increase just because the model name contains the word “in-house.”

The Six Questions Enterprises Are Actually Asking Now

If you treat ZDR as a procurement requirement, the following six questions are far more useful than “Do you support ZDR?”:

• Which specific path does it cover? Clarify the organization, project, region, cloud platform, model version, API endpoint, and whether it includes Agents, files, threads, vector stores, and conversation memory.
• What exactly is retained? List prompts, outputs, request metadata, classifier results, caches, backups, error logs, and billing records separately — do not accept the blanket term “data.”
• Who can access it? Distinguish between the model provider, cloud middle layer, subcontractors, automated security systems, and human reviewers; require disclosure of access approvals, minimum retention periods, and exportable audit records.
• What are the security and legal exceptions? When abuse, illegal content, child safety, legal holds, or service failures occur, ask whether ZDR is suspended, who decides, and when the customer will be informed.
• Can the policy be changed unilaterally? Focus on whether model upgrades, risk level changes, and new security policies will automatically alter retention; “irrevocable” must be locked into the contract and notice period, not verbal sales promises.
• What happens when conditions are not met? The ideal system does not silently fall back to default retention — it rejects the call like Bedrock’s strict mode, or clearly tells the customer that the current model does not comply with ZDR.

Looking back at this news from NVIDIA, the real contradiction is not “why doesn’t a company that buys chips use the strongest model,” but rather “when a model provider needs data for safety purposes, who still retains the power to refuse and audit.” NVIDIA publicly introduced its solution using GPT-5.5 Codex in April: approved cloud virtual machines, dedicated environments, read-only production permissions, complete auditing, and the company’s claimed ZDR policy. The value of this case lies not in proving a slogan, but in placing external models within an observable invocation architecture.

In the past, ZDR primarily addressed the question: will customer data be used for training. Now enterprises need to answer more difficult and more specific questions: can the vendor see it, how long can it retain it, can the security team retrieve it, will the rules change after a model upgrade, and can customers provide independent evidence in the event of a dispute.

Therefore, ZDR has never been an out-of-scope, absolute “no traces left behind” proof, but rather a control plane composed jointly of contracts, configuration, architecture, audits, and exception management. The more powerful frontier models become, the less this chain of evidence can rely solely on a vendor’s word.

References

• Reuters: Palantir, Nvidia, and Booz Allen restrict model use over data concerns
• The Information: Anthropic data policy changes prompt enterprises to restrict model use
• Anthropic: Fable, Mythos access and data retention policies
• Anthropic: Covered Models data retention practices
• Anthropic: API and data retention
• Anthropic: Enterprise Frontier Safeguards
• OpenAI: Platform data controls
• OpenAI: Offering Zero Data Retention for frontier models
• OpenAI: Safety and privacy
• Nvidia: GPT-5.5 Codex deployed inside enterprises
• Nvidia and Palantir: Sovereign intelligence for critical supply chains
• AWS Bedrock: Data retention modes