Anthropic's new Enterprise Frontier Safeguards pitch sounds like a contradiction: keep the safety monitoring, keep the privacy, and somehow do both without handing Anthropic your logs. The announcement is real. The slogan needs translation.

Private Safety Processing and customer-controlled storage diagram

Enterprise Frontier Safeguards, or EFS, is Anthropic's answer to the backlash around its 30-day retention rule for Covered Models such as Claude Fable 5 and Fable 5.1. Anthropic says the retention exists because serious misuse is often invisible in one request. A stolen credential, a long-running agent, or a cyber workflow can look harmless until several sessions and accounts are connected.

That argument makes sense. It also created a compliance problem. Banks, hospitals, law firms, and public agencies may be willing to let automated systems detect abuse, but they often cannot put the underlying records in another vendor's environment or allow that vendor's staff to review them. EFS moves the storage boundary. It does not remove the monitoring relationship.

The decision matrix

The first distinction is between where the data lives and who can act on it. Under EFS, activity data used for monitoring can live in 1 of 3 customer cloud options: Amazon S3, Azure Blob Storage, or Google Cloud Storage. The customer controls the encryption keys, access policies, and audit logs. Anthropic operates the detection systems. When those systems flag a pattern, the signal goes to the customer's team, and Anthropic says its employees do not need to review the underlying content.

That is a useful split, but it is not the same as making the data disappear. Anthropic's own API documentation says Covered Models require 30-day retention outside ordinary ZDR arrangements. It also says flagged content and legal holds can be retained longer. EFS changes custody and review. It does not turn retention into zero bytes everywhere.

Deployment choice Where retained data sits Who runs detection Who handles human review Best fit
Ordinary Covered Model path Provider-controlled environment Anthropic or cloud provider Subject to the service arrangement Teams that can accept the default policy
EFS when available Customer cloud account Anthropic automated systems Customer security or compliance team Regulated teams that can staff the alert loop
OpenAI Private Safety Processing Customer-controlled storage, or OpenAI storage encrypted with customer keys OpenAI automated systems Customer investigates and may share evidence Teams already standardized on OpenAI
Wait and keep current ZDR path No provider-side prompt and response retention where eligible Per-provider ZDR controls Limited by the product and model Teams that cannot accept a retained monitoring record

The practical recommendation is simple. Choose EFS if your blocker is custody, data residency, or provider-side human review, and your security team is ready to own the alerts. Do not choose it merely because the words "zero data retention" appear in the product description. If your policy requires that the model provider cannot access sensitive content under any circumstance, you need a contract and technical design that answers that question directly.

OpenAI's Private Safety Processing preview makes the comparison sharper. OpenAI says automated systems can inspect patterns across related interactions while OpenAI personnel receive only a narrow safety signal, not the prompts or responses. Anthropic's EFS announcement says customers control storage and review, but it gives fewer technical details about what the detector can read, how access is brokered, and how long the rolling window lasts. That missing detail matters more than the headline.

What the customer inherits

Customer-owned storage sounds like a privacy win until the first alert arrives. Then somebody has to decide whether the alert is a real incident, preserve the right evidence, investigate the identity behind it, and document why a legitimate workflow was allowed to continue. Anthropic says EFS carries a 0 dollar Anthropic charge. The cloud provider still bills storage, reads, writes, and egress. The larger cost is operational.

A regulated team should treat EFS like a new security data pipeline, not a checkbox in an AI procurement form. Create a dedicated bucket or storage account. Put it behind a customer-managed key. Restrict the service role to the minimum actions required for ingestion and detection. Send every access event to the existing SIEM. Decide whether the logs fall under legal hold, data-subject requests, incident retention, or sector-specific deletion rules. Test key rotation and key revocation before production traffic arrives.

The alert path needs the same treatment. Write a runbook for a suspected stolen credential, a false positive caused by red-team work, and a legitimate high-risk research workflow. Define who can see raw records, who can see only a signal, and who can approve disclosure to Anthropic. If nobody owns that queue, the privacy architecture has simply moved the unattended problem into your account.

This is also where platform choice matters. Anthropic lists Claude Code, Claude Enterprise, the Claude Platform, Amazon Bedrock, Claude Platform on AWS, Google's Agent Platform, and Microsoft Foundry as planned or supported surfaces. Their data-processor roles are not interchangeable. Anthropic's documentation says that on the Claude API and Claude in Microsoft Foundry, Anthropic is the processor, while on Amazon Bedrock and Google's platform the cloud provider is the processor. Read the provider contract for the exact path you plan to use. Do not generalize a Bedrock guarantee to the direct API deployment.

Our browser-agent isolation guide makes the same point from another angle: a vendor control does not replace the controls around the system that calls it. EFS can narrow the provider's custody of monitoring data, but identity, network access, local transcripts, tool logs, and downstream systems remain your responsibility.

What to verify before rollout

Ask Anthropic and your cloud provider for written answers to five questions before sending sensitive traffic.

First, what exact records are copied into customer storage? "Activity data" is too broad for a data inventory. Does it include prompts, outputs, tool arguments, file names, account identifiers, timestamps, or only derived monitoring features?

Second, what can Anthropic's detector read, and through which identity? Customer-managed keys are meaningful only if the key policy, cross-account role, service account, and support path are documented. Key ownership does not automatically mean provider blindness.

Third, what is the real retention schedule? The announcement mentions a rolling monitoring window and the existing Covered Model policy says 30 days, but teams still need deletion behavior for flagged content, legal holds, backups, replicas, and failed deletion jobs.

Fourth, who sees an alert? EFS says no Anthropic human review is required, which is useful for regulated workloads. It also means the customer's team must be trained to review the signal and retrieve the relevant evidence without turning every alert into a new data leak.

Fifth, what happens during the transition? EFS is rolling out in phases later this fall. Anthropic says eligible customers receive ZDR on Fable 5 and Fable 5.1 until EFS is ready. Get the eligibility condition, end date, supported region, and fallback behavior in writing. A temporary promise is not a migration plan.

EFS is a sensible response to a real deployment conflict. It gives enterprises a way to keep monitoring without putting every monitoring record in the provider's warehouse. But the term "zero retention" still invites the wrong mental model. The meaningful questions are custody, access, retention exceptions, review authority, and who answers the pager at 2 a.m. Until Anthropic publishes the detector's technical boundaries and customers test the deletion and alert paths, EFS is a promising control plane, not a finished privacy guarantee.

Sources