Zero retention safety is a custody architecture, not a privacy label

Two providers are separating safety memory from provider custody

OpenAI's August 19 Private Safety Processing preview and Anthropic's September 1 Enterprise Frontier Safeguards announcement point toward the same architectural move: analyze related interactions for severe misuse while keeping the underlying evidence under customer control. The shared direction is important, but the products are not interchangeable.

OpenAI describes content remaining on customer infrastructure or on OpenAI infrastructure encrypted with customer-controlled keys, with limited safety signals returned for enforcement. Anthropic describes covered prompts and outputs remaining in a customer's Amazon S3, Azure Blob Storage, or Google Cloud Storage environment, under the customer's keys, access policy, and audit logs; automated safeguards scan across interactions and route flagged cases to that customer's human reviewers.

The announcement addresses a real conflict. A single prompt may look benign while a sequence reveals credential theft, safeguard probing, coordinated abuse, or an agent continuing after a stop instruction. Cross-interaction detection needs continuity. Sensitive enterprise workloads need confidentiality and narrow retention. The easy solution to one problem makes the other worse.

OpenAI's proposed split is architectural. Customer content either remains on infrastructure the customer controls or is stored on OpenAI infrastructure encrypted with customer-controlled keys. Automated safety processing produces limited signals. Those signals, rather than readable conversation content, can drive a safety response. OpenAI says personnel do not receive access to the underlying prompts or responses in the normal flow.

That is the claim worth testing. It is not permission to label an application private because one vendor setting says ZDR. The model endpoint is only one component. The browser, API gateway, orchestrator, trace collector, vector database, tool server, customer support platform, and developer console may each retain more information than the provider.

As of September 5, OpenAI's promised technical white paper was not linked from the announcement. Teams should distinguish stated behavior from unanswered implementation details. OpenAI has described content location, key control, personnel access, limited safety signals, rollout timing, and a legal exception for apparent child sexual abuse material. It has not yet publicly specified the full isolation boundary, attestation model, signal schema, deletion proof, false-positive appeal process, or customer audit interface.

A ZDR deployment has at least six data planes

These planes have different owners and purposes. ZDR at the provider can remove abuse-monitoring and application-state retention for an eligible request, while the customer's trace collector still records the entire payload. Conversely, a customer may keep only a hash and a run ID while a selected API feature remains ineligible for ZDR because the provider must store state to implement it.

Derived data deserves its own inventory. A risk score can reveal sensitive facts even when it cannot reconstruct the original prompt. A stable sequence identifier can link otherwise separate activity. A human review note can paraphrase private content. A safe design minimizes the signal, defines its retention and access, and proves that investigators do not quietly rebuild the content plane from metadata.

Private Safety Processing needs an auditable narrow waist

A workable privacy-preserving safety system should create a narrow interface between private content processing and provider enforcement. The private side may examine a related sequence. The public side should receive only the minimum signal needed to rate-limit, block a capability, request customer action, or escalate under a defined exception.

customer content + customer-controlled keys
                |
                v
      isolated sequence analysis
                |
                v
  {policy_id, risk_band, confidence,
   action_class, evidence_commitment,
   expires_at}
                |
                v
 provider enforcement + customer notice
                |
                v
     appeal / incident evidence path

The evidence commitment matters. If content cannot be read during ordinary provider operations, the system still needs a way to show that a particular policy, model, and signal generator produced the decision. A signed record could bind the signal to software version, policy version, time, sequence scope, and a cryptographic commitment to customer-held evidence without exposing that evidence.

This is an architectural recommendation, not a description of OpenAI's unpublished implementation. The September paper should answer whether confidential computing, remote attestation, zero-knowledge techniques, customer-side execution, envelope encryption, or another design carries the trust boundary. It should also explain who can change signal policy, how changes are logged, and how customers verify that an authorized binary and policy ran.

False positives are an operational privacy risk. A block can reveal that a workflow was classified as harmful. A support escalation can cause employees to paste sensitive content into a ticket. If the provider cannot inspect content, the customer needs a safe appeal packet: local evidence, stable decision ID, policy version, redacted explanation, and a controlled route for voluntary disclosure when necessary.

Anthropic's earlier covered-model policy provides historical context: it required prompts and outputs for designated models to be retained for 30 days to support safety work. The September 1 EFS announcement offers eligible organizations an opt-in alternative in which the customer holds that evidence. This does not erase the evidence; it relocates custody and review. Neither posture should be reduced to a marketing adjective. Buyers should compare threat coverage, confidentiality, reviewer access, exceptions, evidence, and the operational burden transferred to the customer.

Anthropic EFS makes customer custody the control plane

Anthropic says EFS was developed with more than 100 customers and will roll out in phases during fall 2026 across Claude enterprise surfaces and cloud partners. That is a first-party development claim, not independent evidence of production adoption. The useful part for architecture review is concrete: the customer chooses a supported cloud store, controls encryption keys and access policies, receives storage audit logs, opts into automated review, and assigns its own people to review flagged activity.

That design changes the accountability map. Under provider-side retention, the provider controls the evidence store and reviewer access. Under EFS, the customer owns the storage bill, region, lifecycle rules, key policy, access reviews, investigation process, and eventual deletion. Anthropic says it does not charge for EFS, while the customer pays its own cloud storage, input/output, and egress costs. A zero provider-retention claim can therefore coexist with days or weeks of customer-side evidence retention.

“Customer controlled” is only meaningful if the automation principal and the human reviewer are separately scoped. The scanner should receive read access only to the EFS evidence prefix, not the customer's entire data lake. Reviewers should open a case through an audited interface, not obtain bulk export rights. Key administrators should not automatically become content reviewers. A customer that grants one service principal broad read, copy, and export permission has recreated a high-value surveillance store under a different logo.

The table is a control comparison, not a security ranking. OpenAI's design may minimize what leaves an isolated analysis boundary; Anthropic's design may give a customer clearer control over retained evidence. Either can fail through excess permissions, weak deletion, verbose derived signals, an undocumented exception, or a customer support workflow that copies content into another system.

retention_profile:
  provider_content: zero
  evidence_custodian: customer
  storage: s3://restricted-ai-safety-evidence/
  kms_key: alias/ai-safety-review
  automated_scanner_principal: anthropic-efs-scanner
  human_review_principal: customer-trust-reviewers
  bulk_export: deny
  ttl_days: approved_value
signal:
  fields: [policy_id, risk_band, sequence_id, action]
  destination: customer-siem
release_gate:
  owner: named-security-and-privacy-reviewer
  evidence: [access-test, deletion-test, key-revocation-test]

Treat the configuration as a proposed evidence contract, not vendor syntax. Before enabling EFS, validate the cloud role with a deny-first policy; write a unique canary into a test case; confirm only the scanner and named reviewers can access it; revoke the key and observe failure behavior; expire the object; search backups, event streams, case tools, and support systems; and export an immutable access and disposition record. Repeat after any role, lifecycle, region, model, or product-surface change.

A strong procurement question is therefore not “Do you offer zero retention?” Ask for a data-flow diagram and fill five cells: provider-readable content, customer-retained content, derived signals, human-review location, and legal or safety exceptions. Then require a test for every cell. The distinction made by security analysts covering EFS is precise: customer-custodied retention relocates retained evidence; it does not make retention disappear.

ZDR eligibility is a feature matrix, not an account-level blanket

OpenAI's current data-controls documentation separates abuse-monitoring retention from application-state retention. Qualifying organizations can configure controls at the organization and project levels, but endpoint behavior still matters. A project may inherit, override, or omit the intended policy. Some features require state and are not ZDR compatible.

The Responses API stores application state for at least 30 days by default when state is enabled. With ZDR, store is treated as false. Background mode needs temporary response storage for polling and is not compatible with ZDR. Extended prompt caching stores key/value tensors and is also ineligible. Audio outputs, files, assistants, vector stores, and other stateful features have their own rules. The live documentation, not a copied procurement slide, is the source of truth.

const request = {
  model: "approved-frontier-model",
  input: minimizedPrompt,
  store: false,
  background: false,
  metadata: {
    data_class: "restricted",
    retention_profile: "zdr-v1",
    workflow_id: "claims-review"
  }
};

assert(project.data_control === "zero_data_retention");
assert(endpointMatrix.allows("/v1/responses", request));
assert(!tracePolicy.capturePayloads(request.metadata.data_class));

The assertions should be runtime controls, not comments. Maintain a versioned endpoint matrix. Reject a deployment when a developer enables an incompatible capability. Treat new API features as unapproved until their storage behavior is reviewed. Capture provider documentation date and a digest in the approval record because eligibility can change.

State can also reappear above the endpoint. The current OpenClaw work on continuing stateful OpenAI Responses turns illustrates the engineering demand for continuation. An application may implement its own session-scoped history even if the provider does not retain it. That can be a valid design, but it moves deletion, access, backup, residency, and incident responsibility to the application owner.

Turn the privacy claim into a machine-checkable evidence contract

An approval document should bind the vendor promise to one real data flow. Record the organization and project controls, model and endpoint, request flags, enabled features, customer stores, observability settings, safety-signal handling, exceptions, and named owners. Hash the exact configuration and test evidence.

{
  "profile": "zdr-private-safety-v1",
  "provider": "openai",
  "project": "prod-restricted-claims",
  "endpoint": "/v1/responses",
  "forbidden_features": ["background", "extended_prompt_cache"],
  "provider_content_retention": "zero_if_eligible",
  "customer_session_ttl_hours": 8,
  "trace_payloads": false,
  "derived_signal_ttl_days": 30,
  "exceptions": ["apparent_csam_reporting", "customer_authorized_incident"],
  "evidence": {
    "provider_docs_checked": "2026-08-22",
    "deletion_test": "test-7421",
    "access_review": "review-118",
    "config_hash": "sha256:..."
  }
}

Run negative tests. Submit unique canary strings, then search provider-visible interfaces, customer logs, traces, caches, backups, and support systems after the declared TTL. Trigger a controlled policy event to see which signal fields appear and who receives them. Change the project setting and prove that the deployment gate notices. Enable an incompatible feature in staging and confirm the request is blocked.

Keep privacy evidence separate from model-quality evidence. A response can be correct and still violate retention policy. A ZDR configuration can pass deletion tests and still produce unsafe or low-quality answers. Security, privacy, model evaluation, and business acceptance are related gates, not substitutes.

The dangerous failures are usually scope failures

Use a five-stage rollout instead of a privacy checkbox

1. Inventory: map request content, application state, customer state, observability, safety signals, subprocessors, backups, and legal exceptions.
2. Constrain: create a dedicated project, use eligible endpoints, disable incompatible features, minimize content, and apply the shortest customer-side TTL.
3. Verify: inspect effective settings, run canary retention tests, test deletion and restoration, review access, and check that no support path copies payloads.
4. Challenge: test cross-interaction safety events, false positives, appeals, policy updates, feature drift, provider outage, and customer-key revocation.
5. Release and monitor: approve one configuration hash, watch for endpoint-document changes, sample retention controls, and reopen the gate when OpenAI publishes the technical paper or either product behavior changes.

Procurement should ask for the technical paper, independent assurance, system and policy versioning, signal schema, customer audit interface, incident and appeal process, key-control boundaries, subprocessor coverage, and notice before an eligibility change. Security should ask how misuse controls behave when customer infrastructure is unavailable. Privacy should ask whether signals can identify a person or link unrelated workflows.

Engineering should make the failure safe. If the project setting cannot be verified, the endpoint matrix is stale, a feature becomes ineligible, or the trace policy is unknown, stop restricted-data traffic. Route the job to an approved local model, a less sensitive workflow, or a human queue. The model access resilience guide explains how to build that exit path, while the execution receipt guide shows how to bind the final configuration and evidence to each consequential run.

Frequently asked questions

Does OpenAI use ZDR customer data for training?

OpenAI says enterprise customer data is not used to train models unless the customer explicitly opts in. Training use and retention are separate controls; verify both in the applicable agreement and live configuration.

Does ZDR mean OpenAI never retains any content?

No. Eligibility depends on endpoint and feature. OpenAI also states that images flagged as potential child sexual abuse material remain subject to manual review and legal reporting even in ZDR deployments. Read the current documentation and contract for all exceptions.

Is customer-controlled encryption the same as customer-hosted content?

No. OpenAI describes two options under development: content on customer-controlled infrastructure, and content on OpenAI infrastructure encrypted with customer-controlled keys. They have different availability, metadata, key-revocation, backup, and assurance questions.

Can a company claim its whole application is ZDR?

Only after it verifies every component. Provider ZDR does not control customer session stores, browser state, traces, tool logs, vector databases, support systems, or backups.

Should teams wait for the September white paper?

Teams can inventory and constrain current ZDR deployments now. As of September 5, the paper was not linked from OpenAI's announcement, so approval of Private Safety Processing should remain conditional until the paper and contractual details answer the team's threat-model and audit questions.

Does Anthropic EFS mean no one retains prompts and outputs?

No. Anthropic says covered data stays in the customer's cloud environment. The customer must still define and verify the storage lifecycle, access permissions, backup behavior, investigation copies, and deletion. Describe this as zero provider retention with customer-custodied evidence, not universal zero retention.