Platform engineers, security teams, and AI coding leads need more than an announcement before moving sensitive work into Anthropic EFS. This guide turns the announced Claude Code support into an acceptance process covering eligibility, customer-controlled storage, keys, monitoring, permissions, isolation, cost attribution, and rollback.

Anthropic has announced Claude Code support for Enterprise Frontier Safeguards, but the rollout is still staged as of September 3, 2026. Do not move sensitive work into it yet unless the organization has written eligibility, a working configuration path, customer-controlled logging, approved keys, and a tested rollback plan. This week, prepare the architecture and run an isolated pilot; keep production credentials and unattended tasks outside the pilot until every gate passes.

This guide is for:

  • Platform engineers preparing identity, storage, keys, proxy, and audit paths for Claude Code.
  • Security and compliance leads checking how Enterprise Frontier Safeguards fits with zero data retention and internal review.
  • AI coding owners designing an isolated pilot with clear failure and shutdown procedures.

Important: EFS retention and monitoring are not the same control as Claude Code permissions, operating-system isolation, or network egress filtering. Treat them as separate acceptance domains.

The September 3, 2026 rollout status sets the first gate

The official position is narrower than a simple “Claude Code is supported” headline. Anthropic has confirmed that Enterprise Frontier Safeguards will support Claude Code, Claude Enterprise, Claude Platform, and selected cloud-platform entry points. The planned rollout starts in fall 2026 and proceeds in stages. Anthropic has not confirmed a universal opening date, a single configuration interface, or an identical eligibility result for every customer. The current covered-model guidance should therefore be checked alongside the announcement and the customer account status (Anthropic’s covered-model guidance).

That distinction changes the decision:

  • An announcement is evidence of intended product support.
  • A written account-team or cloud-platform confirmation is evidence of organizational eligibility.
  • A visible configuration control is evidence that the feature can be activated.
  • A successful test event is evidence that the selected workflow is actually covered.

Anthropic EFS Claude Code planning should remain in the preparation phase when any one of those items is missing. A temporary zero-data-retention arrangement must not be recorded as formal EFS access. It may limit a retention path, but it does not prove that EFS monitoring, customer-side storage, or the complete control plane is active.

First checkpoint: record the qualification evidence

The pilot owner should create one short qualification record containing:

  1. The organization and account identifier.
  2. The exact products and models covered by the written confirmation.
  3. The expected rollout stage and activation route.
  4. The name of the Anthropic or cloud-platform support contact.
  5. The date on which the information was last confirmed.
  6. The fallback service and approved data policy if activation fails.

The record should link to the current data-retention practices for covered models. If the support response uses future-tense language, the rollout is not complete. If the account team cannot identify the configuration owner, the correct action is to continue architecture preparation rather than migrate sensitive tasks.

Use this eligibility decision before opening a pilot

The following branches turn the announcement into an operational decision. They also prevent a team from treating product names as proof of control coverage.

  • If written eligibility names Claude Code and the intended service path, then select a read-only or low-impact pilot.
  • If eligibility is confirmed but the covered model or entry point is unclear, then pause activation and request model-level clarification.
  • If a temporary zero-data-retention option exists without EFS configuration evidence, then keep it as a separate data-policy option, not as EFS.
  • If there is no named support contact, then select architecture preparation only.
  • If the team cannot identify where activity records will land, then do not submit sensitive repositories.
  • If the pilot cannot be stopped without waiting for a provider response, then do not authorize unattended or high-privilege execution.

The search phrase “Claude Fable 5.1” should not be used as an eligibility shortcut. The official material supplied for this review does not establish that an alleged model name, preview label, or community discussion changes EFS access. Model coverage must come from the current official covered-model record or written account confirmation.

Customer-side storage is an evidence problem, not a storage checkbox

A customer-controlled cloud account can improve ownership and investigation, but it does not mean that no data is retained. The acceptance test must separate at least four questions:

  • What data category is written?
  • Which account and resource own the record?
  • Which key and policy protect it?
  • Who can read, export, delete, or restore it?

The storage design should distinguish activity data, audit events, security signals, prompts, tool inputs, tool outputs, and operational metadata. These categories may have different retention periods and access requirements. The team should not describe all of them as “logs” because that hides the deletion and disclosure obligations for each category.

The evidence package should include the resource owner, region or account boundary where applicable, encryption-key policy, service identity, write permission, read permission, deletion procedure, and a successful access-denial test. A screenshot of a storage resource is not enough. The stronger record shows a real event entering the intended account and an unauthorized identity receiving a denied response.

Acceptance area What to verify Evidence to retain Failure action
Resource ownership Records enter an enterprise-controlled account or approved destination Resource identifier, account owner, event timestamp, write result Stop sensitive-data testing
Encryption Internal key policy and service role are explicit Key policy, role binding, rotation or revocation procedure Remove the workload from the pilot
Data categories Prompts, tool activity, alerts, and audit records are classified Data-flow diagram and retention matrix Block approval until classification is complete
Access control Readers and operators are limited by role Successful read test and denied-access record Revoke broad roles and repeat testing
Deletion Each category has an approved deletion path Deletion request, completion record, and restoration check Keep the pilot non-sensitive

Anthropic’s official retention guidance should be read before the internal retention matrix is approved (data-retention practices for covered models). The key decision is not whether a product page uses the phrase “customer-controlled.” It is whether the organization can demonstrate control over the actual data path.

Keys, audit events, and monitoring need separate owners

EFS monitoring should not be confused with Claude Code’s local operation history. Three records need to remain distinguishable:

  1. Provider-side or EFS security detection: signals generated by the covered service.
  2. Enterprise review: triage, false-positive decisions, escalation, containment, and closure.
  3. Claude Code execution records: local commands, file changes, tool calls, MCP activity, and proxy events captured by the approved environment.

One record cannot replace the others. A provider alert may show suspicious activity without proving which shell command changed a file. A local operation log may show a command without proving that the provider’s security signal reached the security team. An audit export may prove administrative access without showing whether a developer approved a high-impact action.

The pilot should route a test signal into the existing security workflow. The acceptance record should show:

  • Detection time.
  • Destination and assigned owner.
  • Triage result.
  • False-positive or true-positive decision.
  • Escalation path.
  • Blocking or containment action.
  • Closure reason and retained evidence.

Anthropic provides separate mechanisms for compliance and audit access. Review the Compliance API documentation and audit-log access guidance rather than assuming that a single export covers every event class.

The control comparison prevents EFS overreach

The following table is intentionally about responsibility, not product marketing. It identifies which control must remain in the enterprise design.

Control layer Primary question Does EFS replace it? Minimum pilot proof
EFS retention and monitoring What covered-service data is retained, monitored, and delivered for review? Yes, only for the EFS-defined scope Written scope and test signal
Claude Code approval Can a user or automation approve a tool or file action? No Denied action and human-approval record
Operating system What can the process read, write, execute, or change? No Restricted workspace and failed privilege escalation
MCP and credentials Which tools and secrets are available? No Tool allowlist, secret-denial test, rotation record
Network egress Where can the process connect? No Proxy policy, blocked destination, allowed-service test
Enterprise response Who investigates and closes an alert? No Assigned case with triage and closure evidence

Claude Code’s enterprise migration guidance is relevant when teams move from individual use to managed administration (Claude Code enterprise migration guidance). It should be combined with the organization’s existing identity and endpoint policy, not treated as a substitute for them.

Second checkpoint: keep the execution boundary independent

The safest pilot does not grant more authority merely because EFS is active. Claude Code should retain least-privilege controls for the workspace, shell, MCP servers, credentials, and outbound network.

A platform team should validate the following sequence:

Step 1: Create a non-production identity

Use a dedicated service identity or developer group for the pilot. Do not attach production administration roles by inheritance. Record the identity-to-workspace mapping and make the owner responsible for access removal.

Step 2: Prepare a disposable workspace

Use a repository copy or test repository with no production secrets. Permit only the directories needed for the task. Confirm that the agent cannot read neighboring projects, local credential stores, or unrelated build artifacts.

Step 3: Define tool and shell rules

List every approved shell operation and MCP capability. Test a denied command, a denied file path, and an unapproved tool. Automatic approval should not become broader after EFS activation.

Step 4: Put credentials behind a controlled path

Use short-lived or task-specific credentials where the existing platform supports them. Record which process can request them, where access is logged, and how revocation works. A successful code task is not acceptance evidence if the same identity can still read unrelated secrets.

Step 5: Restrict network egress

Route permitted traffic through the approved enterprise proxy or equivalent control. Claude Code’s corporate proxy documentation should be checked against the organization’s actual DNS, certificate, authentication, and logging setup. Test both an allowed endpoint and a blocked destination.

Step 6: Test human takeover

Create a task that requires approval before a write, network request, or credential action. Confirm that the operator can reject it, inspect the event, and prevent continuation. Record who made the decision and whether the process stopped.

Step 7: Destroy the environment

After the test, revoke credentials, delete the disposable workspace, remove temporary access, and verify that the execution host cannot resume the task. Environment destruction must be observable, not just an instruction in a runbook.

High-privilege or unattended jobs should use a separate remote Mac or one-time execution environment. That environment should not share the developer’s daily account, production credentials, or delivery pipeline. Teams that need to review available operating models can start with RunMini’s Mac environment overview, then validate the selected boundary against their own identity, logging, and destruction requirements.

Storage cost and runtime impact require separate accounting

The announcement does not provide a safe basis for a fixed operating-cost estimate. Teams should measure rather than infer. Create separate billing and ownership lines for:

  • EFS-related cloud storage.
  • Storage reads and writes.
  • Data transfer.
  • Log export and indexing.
  • Internal security review time.
  • Claude Code execution environments.
  • Proxy, monitoring, and incident-response overhead.
Cost or impact line Measurement source Acceptance question
Storage Cloud billing and usage records Does retention growth match the approved policy?
Reads and writes Cloud usage metrics Are investigations creating unexpected access volume?
Data transfer Cloud billing and network telemetry Does export or cross-boundary movement add exposure?
Review labor Security case records and time tracking Can the team handle the alert volume?
Execution environment Environment usage records Does isolation remain available during peak demand?
Runtime effect Job timings, queue records, and failure logs Does logging delay coding or reduce audit completeness?

A logging failure must have an explicit response. The organization should decide whether the coding task stops, switches to a non-sensitive mode, or continues with a documented compensating control. If the event stream is delayed, the team should not claim real-time response. If storage is unavailable, the job should not silently continue under a different unapproved retention policy.

Third checkpoint: rehearse failure before expanding access

A limited pilot becomes an approved service only after failure modes have been exercised. Test at least these cases:

  • EFS access is unavailable for the organization.
  • The log destination rejects a write.
  • The encryption key is revoked or the service role loses access.
  • Alert volume rises and false positives overwhelm the review queue.
  • The proxy blocks a required service.
  • A Claude Code action requests a permission outside the allowlist.
  • The disposable environment fails to shut down.

For each case, record the trigger, automatic behavior, human decision, fallback service, data policy, and restoration condition. The fallback should return to an already approved model and data path. It must not be an improvised account with unknown retention.

The team should compare three rollout levels:

  • Read-only pilot: repository inspection and analysis without production writes.
  • Restricted write pilot: changes only in disposable branches or test workspaces.
  • Unattended execution: scheduled or autonomous actions with limited human presence.

If read-only work passes but restricted writes fail, select the first level and continue remediation. If restricted writes pass but unattended shutdown or credential revocation fails, do not expand to autonomous tasks. The decision should follow evidence, not the existence of an EFS entitlement.

The final acceptance decision belongs on a dated milestone

A useful 2026 milestone record contains four dates:

  1. Qualification date: written eligibility and covered-model scope confirmed.
  2. Architecture date: storage, key, identity, proxy, and alert ownership approved.
  3. Pilot date: reversible tests completed with retained evidence.
  4. Expansion date: risk owner approves the selected task class.

The project should choose one of three outcomes:

  • Continue preparing: eligibility or configuration remains uncertain.
  • Run a grouped pilot: access is confirmed, but only read-only or restricted-write tasks pass.
  • Proceed with controlled integration: storage, monitoring, isolation, response, and rollback all pass for the approved scope.

Re-acceptance is required when Anthropic changes the covered-model list, opens a new configuration route, changes retention terms, expands availability, changes the customer-side storage design, or when the organization changes its identity, proxy, key, or execution environment. The supplied official sources should be rechecked at each such trigger, not only during the initial launch.

FAQ

Is Anthropic EFS available for Claude Code now?

Anthropic has announced support, but the rollout remains staged as of September 3, 2026. Every organization should confirm written eligibility, the real configuration route, covered models, and a named support contact. Until those details are verified, teams should prepare the architecture and keep sensitive repositories, production credentials, and unattended jobs outside the pilot.

How does Enterprise Frontier Safeguards differ from zero data retention?

Enterprise Frontier Safeguards covers a broader control arrangement involving retention, monitoring, access, and customer responsibilities. Zero data retention describes a narrower retention condition. It does not replace operating-system permissions, MCP restrictions, network controls, human approval, or internal audit. A zero-retention setting therefore cannot be used as proof that formal EFS access is active.

Where do Claude Code logs go after EFS activation?

The destination depends on the service path and record type. The acceptance test must identify whether activity and audit data reach a customer-controlled cloud account, which key protects them, how long each category remains, and who can read or delete it. The evidence should include a successful write, a deletion test, and a denied read from an unauthorized identity.

Can EFS replace Claude Code sandboxing and permission approval?

It cannot. EFS retention and monitoring operate alongside Claude Code approval, operating-system permissions, MCP allowlists, credential controls, and network egress rules. High-risk work still needs a separate environment, least privilege, reversible tests, human takeover, and reliable destruction. Enabling EFS is not a reason to widen automatic approval.

Current setup versus a separated Mac pilot

Keeping high-privilege Claude Code work inside a developer’s daily machine or a shared build host creates several concrete weaknesses: credentials and repositories may share one trust boundary, local logs may not reach the central review path, and a failed task can remain active after the operator assumes it has stopped. A generic shared environment also makes it harder to prove which identity performed an action or whether the workspace was actually destroyed.

After the EFS qualification and data-flow checks pass, renting a separate Mac environment from RunMini can provide a cleaner trial boundary for real repositories. The useful test is not a benchmark claim. It is whether the team can demonstrate permission blocking, log delivery, human intervention, credential revocation, and environment destruction without touching the developer’s normal account or production delivery path. Teams can review the RunMini help resources before defining the handoff, access, and shutdown procedure. That evidence gives the security owner a defensible basis for expanding from a read-only pilot to restricted writes, or for waiting when the controls still fail.

Further Reading

FAQ

Is Anthropic EFS available for Claude Code right now?

Anthropic has announced support for Claude Code, but the rollout remains staged as of September 3, 2026. Do not assume that every organization has access. Confirm written eligibility, the actual configuration path, covered models, and a named support contact. Until those items are verified, prepare the architecture without moving sensitive repositories or granting broader execution rights.

How does Enterprise Frontier Safeguards differ from zero data retention?

Enterprise Frontier Safeguards is an access, retention, monitoring, and customer-control arrangement that must be validated across the covered service path. Zero data retention is a narrower retention condition, not a replacement for identity controls, customer-side logging, operating-system permissions, network restrictions, or human review. A zero-retention statement alone does not prove that EFS is active.

Where are Claude Code logs stored after EFS is enabled?

The answer depends on the configured service path and the data category being recorded. Validate whether activity data and audit events enter a cloud account controlled by the customer, which encryption key protects them, how long each category remains, and who can read it. Preserve a successful write test, a deletion test, and an unauthorized-access rejection as evidence.

Can Anthropic EFS replace Claude Code sandboxing and permission approval?

No. EFS addresses retention and monitoring architecture; it does not replace the operating system boundary, shell restrictions, MCP controls, credential isolation, network egress policy, or approval workflow. Claude Code should still run with least privilege. High-risk or unattended work needs a separate execution environment, reversible tests, human takeover, and a proven shutdown path.

Run Claude Code on a Dedicated Remote Mac

Deploy a dedicated Mac mini with RunMini for a stable environment for Claude Code workflows. Keep your development tools, files, and project workspace available through remote Mac access.

Purchase Pricing Help Center