The problem is not that ZDR is weak. The problem is treating one strong retention control as if it closes the whole AI threat model.

A private prompt passes through three security windows. ZDR governs only the last one. That leaves a gap exactly when the prompt is most valuable: while remote infrastructure is actively processing it.

A prompt crosses three threat windows.

01 · In transitTLS protects the network hop.

The provider terminates TLS and receives the application payload. TLS does not protect the prompt from the receiving service.

02 · In useZDR does not remove runtime plaintext.

A conventional model service must process usable content. FHE changes this window for supported inference by computing over ciphertext.

03 · After useZDR minimizes the residue.

Contracts and configuration govern logs, storage, secondary use, and deletion, subject to feature and safety exceptions.

ZDR answers “Will you keep it?” It does not answer “Could your inference service see it?”

The uncovered threats

RUNTIME COMPROMISEThe prompt exists inside the inference service.

ZDR does not by itself protect plaintext from a compromised runtime, memory disclosure, or a defect in the processing path.

PRIVILEGED ACCESSRetention and operator access are different controls.

Some vendors add zero-operator-access or controlled-review guarantees. Those protections come from separate controls, not from the words “zero retention.”

AGENT FAN-OUTThe model call is only one boundary.

Memory, files, safety systems, caches, grounding, and external tools can create their own copies and retention rules.

PROOF GAPA response cannot prove deletion.

The customer relies on contracts, configuration, audit, and vendor controls. Those are useful assurances, but not cryptographic proof of what remote compute received.

This is a coverage problem, not a vendor-trust slogan.

Modern ZDR programs can be contractually binding, technically enforced, and independently audited. The missing property is narrower and precise: ZDR does not turn plaintext inference into encrypted computation.

What provider policies actually show

Across OpenAI, Anthropic, Google, AWS, and Microsoft, the strongest controls reduce training use, durable storage, abuse-log content, or operator access. Their scope still varies by model, endpoint, safety path, cache, agent state, and external tool.

OpenAI is also previewing Private Safety Processing to preserve ZDR for frontier models while detecting patterns across related interactions. For ZDR deployments, content remains on infrastructure controlled by the customer. OpenAI is developing another option that stores content on its infrastructure encrypted with customer-controlled keys. Automated systems return narrow safety signals without giving OpenAI personnel the underlying content. The preview is being tested with early customers, with rollout and a technical white paper planned for September 2026.

Its API documentation makes the separate feature-level scope explicit. ZDR forces store=false for supported Responses and Chat Completions requests, while background polling can use roughly 10 minutes of disk state. Prompt caching can keep encrypted KV tensors in GPU-local state for up to 24 hours, and hosted tools can keep ephemeral container files until the container expires or is deleted.

Anthropic's current documentation adds a model-level exception. Eligible APIs and specified Claude Code surfaces can operate under an approved, organization-scoped ZDR arrangement, while designated Covered Models require 30-day prompt and output retention. Customers must select a retention-enabled workspace or separate cloud scope to use those models.

AWS makes the temporal boundary especially clear: its strict retention mode describes prompts and responses being processed without being written to durable storage. That is a meaningful guarantee. It is also an explicit example of processing first and discarding afterward.

The interactive flow and source matrix maps those boundaries provider by provider. The recurring result is not “ZDR fails.” It is “ZDR covers only part of the lifecycle.”

FHE protects data during supported computation

NIST describes Fully Homomorphic Encryption as computation over encrypted data without knowledge of the secret key. In Mirror's supported inference path, the customer endpoint encrypts before sending, remote infrastructure evaluates ciphertext, and the final result is released at the customer boundary.

Threat windowPrimary controlWhat it protects
In transitTLSNetwork interception between endpoints
In useEncrypted inference with FHERemote access to prompt and result plaintext for supported compute
After useZero Data RetentionDurable logs, storage, secondary use, and residual copies within its scope
Across continuationsContext bindingUnauthorized reuse across users, sessions, models, and turns
Use FHE for supported data in use, ZDR for residual data, and context binding for state that continues.

Encrypted inference is not “full security” either

FHE closes a specific and important gap. It does not secure a compromised customer endpoint, hide every traffic pattern, prove model correctness, authorize tool actions, or automatically protect data once an agent deliberately sends it to an external system.

ZDR alone leaves the data-in-use threat open. Encrypted inference covers that boundary for supported models and operations. The surrounding agent still needs identity, policy, isolation, encrypted memory, tool controls, audit, and retention minimization.

Inspect the data-in-use boundary.

Compare provider retention controls, inspect the lifecycle flow, and run the eight-stage proof.

Open the live comparison

Primary sources