What changed

  • A new opt-in control set. On 1 September 2026, Anthropic announced Enterprise Frontier Safeguards — EFS from here on — a package that combines zero data retention with automated misuse detection. CNBC reported it on the first; Anthropic's own announcement and the follow-up coverage landed on the second.
  • The monitoring data leaves Anthropic's estate. Activity data used for detection is stored in cloud infrastructure controlled by the customer, not by Anthropic: Amazon S3, Azure Blob Storage or Google Cloud Storage, under the customer's own encryption keys and access policies.
  • Nobody at Anthropic reads it. Automated monitoring analyses traffic patterns across sessions and accounts. No human review by Anthropic employees is required. When a pattern needs attention, the signal is sent directly to the customer.
  • It changes nothing about the model. The controls are opt-in and do not alter model behaviour, pricing or rate limits.
  • It is free, and it is not free. Anthropic does not charge for EFS. The cloud providers bill for storage and data transfer on the bucket it writes to.
  • It is not generally available. Rollout is phased, beginning in Anthropic's words "later this fall", with a stated goal of broad availability by autumn 2026. Eligible customers get zero data retention on Fable 5 and Fable 5.1 as a bridge until then.

That is the announcement. The interesting part is what it implies about who does the work afterwards, and The Register put its finger on it: the arrangement creates a dual-custody model. Storage moves to the customer, but Anthropic's automated systems still generate the alerts, and the obligation to review flagged content moves from vendor to customer. Its framing was blunt — Anthropic promises zero data retention, and customers must check it worked. Notably, The Register's piece carried no external expert criticism, and I am not going to invent any. The design is defensible. It is also a transfer, and transfers have recipients.

What Enterprise Frontier Safeguards actually is

To see what is new, you have to be precise about what zero data retention meant before. A ZDR agreement said Anthropic would not persist your inputs and outputs. Earlier in 2026, that promise acquired a carve-out: Anthropic temporarily retained inputs and outputs of covered models even where customers held ZDR agreements, so that it could review safety violations. Thirty days was the standard retention period for commercial API users. The stated purpose was legitimate — you cannot investigate misuse of a frontier model against data you deleted — but it meant that "zero retention" was, for a defined window and a defined class of traffic, not zero.

EFS resolves that tension by moving the storage rather than removing it. The detection logic still runs on Anthropic's side. The data it needs to run on lands in a bucket you own, in a region you chose, encrypted with your keys, governed by your IAM policies. Anthropic's automated systems analyse the traffic patterns across sessions and accounts, and when something looks like it needs attention, a signal comes back to you rather than going to a queue inside Anthropic.

ZDR with safety retention (earlier in 2026) Enterprise Frontier Safeguards
Where monitoring data sits Anthropic-controlled infrastructure Customer's S3, Azure Blob or Google Cloud Storage
Whose encryption keys Anthropic's The customer's own
Retention window 30 days for commercial API users Set by the customer's own lifecycle policy
Who can read flagged content Anthropic reviewers The customer; no Anthropic human review required
Who generates the alert Anthropic Anthropic — unchanged
Who acts on the alert Anthropic The customer
Who pays for storage Anthropic The customer, via their cloud provider

The bottom three rows are the whole story. Rows one to five are a privacy improvement with no obvious downside. Row six is an operating model change that most teams will discover after they have signed for rows one to five.

Why this happened when it did

Anthropic says EFS was developed with more than 100 customers across financial services, healthcare, manufacturing, telecom, law, retail and the public sector. Development partners include the Analysis and Resilience Center for Systemic Risk — whose membership includes the chief information security officers of Goldman Sachs, Morgan Stanley, Citi, Bank of America and Wells Fargo — alongside Comcast, KPMG, Mastercard, Salesforce, Stripe, Visa and Snowflake. The cloud partners are AWS, Google Cloud and Microsoft Azure. That is not a list you assemble to launch a feature. It is a list you assemble to fix a problem those organisations have told you about repeatedly.

The problem was the retention carve-out. Regulated-industry customers, in the reporting, found it difficult to use models with data retention at all. If your data-protection impact assessment says prompts containing client material never leave your control, a thirty-day safety-review window inside a vendor's estate is not a footnote — it is a blocker that goes to a committee. EFS is the answer to that pushback, and the composition of the partner list tells you which committees were doing the blocking.

There is a competitive dimension too, and it is worth stating carefully: every serious frontier vendor is being asked the same questions by the same buyers. What Anthropic has done is publish a specific technical answer with named cloud partners attached. That is a strong position in a procurement conversation. It is not evidence that anyone else lacks an equivalent, and I would not let a vendor tell you otherwise.

Watch out

EFS is not generally available. Anthropic describes a phased rollout beginning "later this fall" with broad availability targeted for autumn 2026. If a plan for this quarter depends on EFS being live in your region, on your surface, for your account — confirm it in writing with your account team before it goes into a slide. The interim position for eligible customers is zero data retention on Fable 5 and Fable 5.1, which is a bridge and not the destination.

Three moves in five weeks

EFS does not read as a standalone product decision once you line it up against August. On 5 August 2026, inference hooks entered beta for Claude Enterprise: every governed prompt is routed through the customer's own AI security server for an allow-or-deny verdict before inference runs, with one organisation-level configuration covering claude.ai, Claude Cowork and Claude Code. It is a webhook-based protocol with a documented schema, so security vendors can build integrations against it. On 6 August 2026, self-hosted Claude Code entered public beta for Team and Enterprise plans, so sessions run on infrastructure the organisation controls, keeping repository checkouts, build artefacts, secrets and internal toolchain access inside the network. That direction of travel was already visible in Anthropic's self-hosted sandbox and MCP tunnel work, and in the compliance API with its enterprise integrations.

Date Release What moves out of Anthropic's estate Who now owns it
5 Aug 2026 Inference hooks (beta, Claude Enterprise) The allow-or-deny decision, taken before inference runs Your AI security server, and whoever writes its policy
6 Aug 2026 Self-hosted Claude Code (public beta) The execution environment — checkouts, artefacts, secrets, toolchain Your platform team
1 Sep 2026 Enterprise Frontier Safeguards Custody of monitoring data, and review of what it flags Your bucket, and someone who has to read the alerts

Read down the right-hand column and the strategy is unmistakable. The frontier lab is retreating from the customer's data plane. It keeps the detection logic, the policy protocol and the model; it gives away the custody, the execution and the triage. For anyone who has spent a year explaining to a bank's third-party risk team why prompts transit a vendor boundary, that is a genuine and welcome win. It is also three new pieces of infrastructure that someone on your side now runs.

The alerts land in your cloud. Who reads them?

This is the part that will not be in the vendor deck, and it is the part I would make a team answer before signing anything.

Automated monitoring analyses traffic patterns across sessions and accounts. When it detects a pattern needing attention, signals are sent directly to the customer to review. That sentence describes a queue. Queues need an owner, a service level, an escalation path and a disposition record, and none of those exist by default. Consider the questions in order.

Who owns the queue? Security operations is the obvious answer and often the wrong one, because the content of a flagged Claude session may be legally privileged material, patient data or market-sensitive information that your SOC analysts have no business reading. Platform engineering can route the alert but cannot judge it. Legal can judge it but will not staff a rota. In most organisations this lands, unhappily, on whoever owns AI governance — a role that in many Indian and UK firms is a part-time responsibility bolted onto someone's existing job.

What is the response target? An alert with no time bound is not an alert, it is a log line. Pick a number, write it down, and be honest about whether you can meet it at 02:00 on a Sunday.

What is the escalation path? From triage to security, to legal, to the data protection officer, to the regulator if it comes to that. Draw it before you need it.

What happens to an alert nobody triages? This is the question that matters most, because the honest answer for a great many teams in the first six months will be "nothing". Under the previous arrangement, an unreviewed signal was Anthropic's unreviewed signal. Under EFS it is yours, sitting in your bucket, with your retention policy on it, discoverable by anyone who later asks what you knew and when. Custody cuts both ways.

Pro tip

Treat the EFS signal stream as a new incident class and give it a runbook before you enable it, not after the first alert. Name the owner, define severity tiers, set a triage target, write the escalation path to legal and security, and record every disposition — including "reviewed, no action" — because the record is the evidence your assurance team will ask for. Our guide to LLM incident response runbooks is a reasonable starting template; add a tier for misuse signals specifically, since they are a governance problem rather than an availability one, and pair it with least-privilege credential hygiene on the bucket itself.

Every article here is written by a Verified Builder. Want your name on the next one?

AI Tech Connect lists AI engineers, founders and researchers across India and the UK — and the people hiring browse it to find them. Adding your profile is free.

Become a Verified Builder →

What "free" actually costs

Anthropic does not charge for Enterprise Frontier Safeguards. That is a real and unambiguous statement, and it is also not the same as the feature being costless. Cloud providers bill for storage and data transfer, and monitoring data that captures traffic patterns across sessions and accounts is not a rounding error at enterprise volume.

Four line items to model before you commit. First, object storage in your chosen class and region, growing monotonically unless you write a lifecycle policy. Second, request costs, which for many small writes can exceed the storage line. Third, egress, which is what you pay every time something outside the bucket's region reads the data — including your own triage tooling if it lives elsewhere. Fourth, whatever you put on top: a SIEM feed, a retention archive, a legal hold, each with its own price and its own retention argument.

None of this is expensive in the way GPU capacity is expensive. It is expensive in the way that unowned line items are expensive, which is to say it grows quietly for two quarters and then appears in a finance review with nobody able to say who approved it. Set the lifecycle policy on day one and name the cost centre in the same change request that enables the feature.

The dual-market read: India and the UK

For teams selling AI into Indian global capability centres, banks and public-sector buyers, customer-held storage removes a specific and recurring objection. Anyone who has taken a Claude-based product through a GCC security review knows the shape of it: the questionnaire asks where prompt data rests, for how long, and under whose keys, and "the vendor's infrastructure, for up to thirty days, under the vendor's keys" is an answer that generates three follow-up meetings. "Your bucket, your keys, your region, your retention policy" ends that thread. Anthropic's Bengaluru office and its treatment of India as a second market make more sense read alongside this: local presence is worth considerably more when the data architecture can survive a procurement review.

In the UK the same argument lands with financial services and health buyers, where the questions come from a different institutional direction but rhyme. Teams working under FCA supervision are asked to evidence control over third-party processing; teams handling patient data are asked much the same by their information governance function; and the ICO expects a defensible position on lawful basis, retention and processor oversight under UK GDPR. A customer-held bucket materially improves the answer to all three. Our earlier reporting on how the Bank of England, FCA and ICO are approaching frontier AI covers the institutional backdrop, and for the harder end of the spectrum — the environments where nothing may transit the internet at all — the trade-offs in our guide to air-gapped LLM deployment for banks and the NHS still apply, because EFS reduces vendor custody rather than eliminating the network path.

The caveat, and I want to be unambiguous about it: a vendor control is not a compliance certificate. EFS changes the facts your assessment is written about. It does not write the assessment, and it does not satisfy any named regulation on its own. For Indian teams specifically, resist the reflex to describe this as solving a localisation requirement — the DPDP Act's section 16 is a negative list, under which the government may restrict transfers to specified countries, not a general bar on transfers, and the Rules are phased with obligations running to May 2027. Storing monitoring data in your own Mumbai region bucket is good architecture and good optics. It is not a legal conclusion, and anyone who tells a buyer otherwise is storing up a problem.

What I would do this month

Ask your Anthropic account team for the concrete rollout position: which surfaces, which regions, which of Claude Code, Claude Enterprise, Claude Platform, Amazon Bedrock, AWS, Google Agent Platform and Microsoft Foundry apply to your contract, and roughly when. Get the answer in writing, because "later this fall" is a plan and not a date.

In parallel, do the unglamorous half. Decide which cloud, which region and which bucket. Write the lifecycle policy. Name the cost centre. Then name the human being who reads the alerts, write their runbook, agree the response target with them rather than at them, and put the escalation path on one page that legal has actually seen. If you cannot name that person, you are not ready to opt in — and that is a finding worth having before the feature arrives rather than after.

The privacy win here is real, and teams in regulated sectors across India and the UK have been asking for exactly this for a year. It arrives attached to a triage queue with no default owner, staffed by people nobody has hired. Both halves are true, and only one of them is in the announcement.