What is ZDR (zero data retention)?
The "not retained" promise, sorted by default versus on-request. Glossary #7 — read alongside this page.
Read it →What Is Zero Operator Access (ZOA)? — "Not Retained" and "Not Viewable" Are Different Promises
Glossary #9. In #7 on ZDR and #8 on the four data requirements, ZOA appeared once as the "not viewable" requirement: the operator's own staff cannot access your content. This page is the deep dive. ZDR is about storage; ZOA is about people. Data that is never stored can still be seen while it is being processed, and data retained for 30 days is unreadable if nobody can decrypt it. They are independent promises, and satisfying one does not satisfy the other. We split the controls into three layers — process, keys, runtime — and quote each vendor's official text on what is default versus what must be requested.
Zero operator access (ZOA) = the people who run the service cannot decrypt or read your data.
1. What ZOA covers — and what it does not
In this page, "operator" (the party running the service) means operations staff, support engineers and platform administrators on the cloud provider's side — for example, AWS staff. It is not attackers, and not other tenants. Your own staff at the company using that cloud (your in-house IT and operations team) are a separate party and are not who ZOA covers: whether they can read the data is a question about your own access design and key management. ZOA aims to make the data unreadable even if the provider's operator were malicious.
| Question | What ZOA answers | Watch out |
|---|---|---|
| Can the cloud provider's employees read my content? | No (by design or by process) | The enforcement mechanism differs — process, keys or runtime — and so does the strength. |
| Can my own operations staff (at the company using the cloud) read it? | Out of scope for ZOA | They are a different party and can read it depending on your own permissions design. ZOA is a promise about the provider side; in-house access is a separate question. |
| Can the third-party model provider read it? | Documented separately by the intermediary | AWS states for Bedrock: “Model providers don't have any access to those accounts. Because the model providers don't have access to those accounts, they don't have access to Amazon Bedrock logs or to customer prompts and completions.” The operator (the cloud provider) and the model provider are different parties. |
| Is my data stored? | Out of scope (that is ZDR) | Retention is covered by ZDR. ZOA can hold at 0 days or 30 days. |
| Is it used for training? | Out of scope (that is a contract term) | Training use is a contractual clause — see "don't learn from it" in #8. |
| Does it survive a legal demand? | Depends on the provider's policy | If the design makes plaintext unavailable, there may be nothing to hand over — but this is only verifiable to the extent the provider publishes it. |
← scroll horizontally →
2. ZDR (not retained) and ZOA (not viewable) are separate
Confusion arises because many vendors describe both in a single sentence. The obligations themselves share almost nothing.
| Dimension | ZDR (not retained) | ZOA (not viewable) |
|---|---|---|
| Subject | Stored data (retention period) | Human access (who can decrypt and read) |
| Where it lives | Storage and logs | Keys, runtime environment, approval process |
| Typical configuration | Retention mode per account, project or request | Customer-managed keys, approval workflows, confidential computing |
| What breaks when it fails | Data remains (for as long as the vendor keeps it) | Remaining data is readable by staff — regardless of retention |
| Common trap | On by default / exception models | Not on by default / emergency exceptions exist |
← scroll horizontally →
“Amazon Bedrock uses a zero operator access (ZOA) data security model. This means no operators of the service can access model input or output. Also, Amazon Bedrock uses a zero data retention (ZDR) data security model. This means that by default, Amazon Bedrock does not store model inputs or outputs.”
— AWS documentation, "Amazon Bedrock abuse detection" (retrieved 2026-09-27)
Note the asymmetry: the ZDR sentence carries a "by default" qualifier and an exception list of models that must be retained, while the ZOA sentence carries no such caveat. That does not mean ZOA rules out human access in every configuration: AWS states that no operator of the service can access model input or output, yet the retention modes include aws_review, which retains inputs and outputs for human review by AWS (verbatim quote in section 3 below). ZOA is a promise about operator access; the retention mode is a separate layer of settings, so the ZOA wording alone does not settle whether a given retention mode allows human review. Check the default state separately for each requirement.
3. The three layers that block access
Read across the vendors and the mechanisms collapse into three layers, each resting on a different kind of evidence.
← scroll horizontally →
4. The three stages of key management — CMK, BYOK, HYOK
"It's encrypted, so the operator can't read it" only holds if you know who holds the key. The terms sound alike; the guarantees do not.
| Item | CMK (customer-managed key) | BYOK (bring your own key) | HYOK (hold your own key) |
|---|---|---|---|
| Key material generated by | The provider's KMS / HSM | You generate it, then import it | You, in your own environment |
| Key material stored | Inside the provider's KMS / HSM | Inside the provider's KMS (after import) | Outside the provider (your HSM or key manager) |
| Cryptographic operations performed by | The provider | The provider | Your key manager (the provider calls out each time) |
| What you control | Principals, permissions, deletion | Expiry, revocation, immediate deletion | You can stop decryption outside the provider entirely |
| Can the provider decrypt in principle? | Yes — it holds the permissions | Yes — the material sits in its KMS | No, by design — the material never leaves you |
| Typical implementation | AWS KMS customer managed keys / Google CMEK / Azure Key Vault | AWS KMS imported key material / BYOK import into Azure Managed HSM | AWS KMS External Key Store (XKS) / Google Cloud EKM / Azure Managed HSM external key management |
← scroll horizontally →
HYOK, verbatim (AWS KMS external key stores)
“Encryption and decryption operations that use a KMS key in an external key store are performed by your external key manager using your cryptographic key material, a feature known as hold your own keys (HYOKs).”
“AWS KMS never interacts directly with your external key manager, and cannot create, view, manage, or delete your keys. … Instead, AWS KMS interacts only with external key store proxy (XKS proxy) software that you provide.”
“Your cryptographic key material never leaves your external key manager.” — AWS KMS Developer Guide, "External key stores" (retrieved 2026-10-01)
“AWS KMS never interacts directly with your external key manager, and cannot create, view, manage, or delete your keys. … Instead, AWS KMS interacts only with external key store proxy (XKS proxy) software that you provide.”
“Your cryptographic key material never leaves your external key manager.” — AWS KMS Developer Guide, "External key stores" (retrieved 2026-10-01)
BYOK, verbatim
“When you create a KMS key, by default, AWS KMS generates the key material for that KMS key. But you can create a KMS key without key material and then import your own key material into that KMS key, a feature often known as ‘bring your own key’ (BYOK).”
“You can set an expiration time on import or call DeleteImportedKeyMaterial to revoke access immediately.” — AWS KMS Developer Guide, "Importing key material" and "Key stores" (verified 2026-10-01)
“You can set an expiration time on import or call DeleteImportedKeyMaterial to revoke access immediately.” — AWS KMS Developer Guide, "Importing key material" and "Key stores" (verified 2026-10-01)
HYOK, verbatim (Microsoft and Google Cloud)
“Keys are generated and stored in a single-tenant, FIPS 140-3 Level 3 HSM that only you control: Microsoft has no access to your key material, and you govern who can use each key.”
“Microsoft can’t decrypt your key material or recover your HSM cluster without it.”
“The security domain is protected by a quorum of RSA key pairs that you hold offline. Recovery requires your quorum, so no single person—and no Microsoft operator—can act alone.”
“The external key never resides in or passes through Microsoft infrastructure; only your hardware uses it.” — Azure blog, "External key management for Azure Managed HSM" (retrieved 2026-10-01)
“Microsoft can’t decrypt your key material or recover your HSM cluster without it.”
“The security domain is protected by a quorum of RSA key pairs that you hold offline. Recovery requires your quorum, so no single person—and no Microsoft operator—can act alone.”
“The external key never resides in or passes through Microsoft infrastructure; only your hardware uses it.” — Azure blog, "External key management for Azure Managed HSM" (retrieved 2026-10-01)
“Data encrypted using a Cloud EKM key can’t be decrypted without both the external key material and the internal key material.”
— Google Cloud documentation, "Cloud External Key Manager" (retrieved 2026-10-01)
⚠️ HYOK is a trade, not a free upgrade. Keeping key material outside means your system must answer every cryptographic request. If your HSM is down, the cloud service cannot decrypt either. Availability, latency and operational responsibility (backups, patching, incident response) move to you — AWS notes the XKS proxy is "software that you provide." Choose it because you have accepted that responsibility, not because it sounds strongest.
5. How "no access without your action" is actually enforced
Keys and runtimes are technical controls, but real operations sometimes require a human on the provider side to touch the system (incident response, abuse investigation — not your own operations team). That is where layer 1 — the approval workflow — does the work.
| Vendor | Mechanism | What the customer holds | Exceptions / caveats |
|---|---|---|---|
| Microsoft (Azure) | Customer Lockbox | Approve or reject each access request | Requests sit in the customer queue for four days, then expire and no access is granted. Emergency "break glass" scenarios do not trigger Lockbox, per the official page. |
| Google Cloud | Access Approval + Access Transparency + Key Access Justifications (KAJ) | Approval of personnel access, plus approve/deny per key-access request | For keys registered for KAJ (customer-managed keys), KAJ issues a justification code with every request to the key — any cryptographic operation, not only decryption; your policy decides. Denying some codes (e.g. GOOGLE_INITIATED_SERVICE) reduces availability and reliability. |
| Anthropic | Controlled access path | — (review is conditionally triggered) | Verbatim, human review can occur only when content is flagged by automated trust and safety systems. |
| OpenAI | ZDR with Private Safety Processing (PSP) / Enterprise Key Management (EKM) | Permissions and key authorisation needed to decrypt | The stated principle is that safety review must not create a new way for OpenAI personnel to read content; decryption happens in a hardware-attested runtime. |
| AWS (Bedrock) | ZOA model plus retention modes (none etc.) | Choice of retention mode per account / project / Region | Retention modes include aws_review, which retains inputs and outputs for human review by AWS. The ZOA description states no exception, but retention modes are a separate layer of settings: choosing aws_review can bring human review inside AWS, so do not read "no human can ever look" out of the ZOA wording alone. |
← scroll horizontally →
The primary sources, verbatim
“In those rare circumstances where Microsoft requires such access, Customer Lockbox for Microsoft Azure provides an interface for your organization to review and approve or reject customer data access requests.”
“The request remains in the customer queue for four days. After this time, the access request automatically expires and no access is granted to Microsoft engineers.”
“Approve: The Microsoft engineer receives access for the duration specified in the request details …”
“Deny: Customer Lockbox rejects the elevated access request by the Microsoft engineer and takes no further action.” — Microsoft Learn, "Customer Lockbox for Microsoft Azure" (retrieved 2026-10-01)
“The request remains in the customer queue for four days. After this time, the access request automatically expires and no access is granted to Microsoft engineers.”
“Approve: The Microsoft engineer receives access for the duration specified in the request details …”
“Deny: Customer Lockbox rejects the elevated access request by the Microsoft engineer and takes no further action.” — Microsoft Learn, "Customer Lockbox for Microsoft Azure" (retrieved 2026-10-01)
“Access Approval lets you authorize requests from Google personnel to access Customer Data, Access Transparency helps you discover information about when Customer Data is accessed, and Key Access Justifications provides key access control for all interactions with at-rest Customer Data that is encrypted by a customer-managed key.”
“Key Access Justifications lets you set a policy on Cloud KMS keys to view, approve, and deny key access requests depending on the provided justification code.”
“Support tickets typically don’t require this access and our frontline support personnel don’t have this access.” — Google Cloud documentation, "Overview of Key Access Justifications" (retrieved 2026-10-01)
“Key Access Justifications lets you set a policy on Cloud KMS keys to view, approve, and deny key access requests depending on the provided justification code.”
“Support tickets typically don’t require this access and our frontline support personnel don’t have this access.” — Google Cloud documentation, "Overview of Key Access Justifications" (retrieved 2026-10-01)
“Safety review must not create a new way for OpenAI personnel to read protected customer content. Encrypted customer content is decrypted in an approved, hardware-attested safety runtime that disables human access.”
“The Safety Review Runtime, a hardware-attested computing environment that disables human access, is designed to be the only workload that can decrypt customer content.” — OpenAI developer docs, "ZDR with Private Safety Processing" (retrieved 2026-10-01)
“The Safety Review Runtime, a hardware-attested computing environment that disables human access, is designed to be the only workload that can decrypt customer content.” — OpenAI developer docs, "ZDR with Private Safety Processing" (retrieved 2026-10-01)
“By default, no Anthropic personnel can read your retained conversations. Human review can occur only through a controlled access path … when content is flagged by our automated trust and safety systems”
— Anthropic support, "Data retention practices for covered models" (retrieved 2026-09-27)
“This mode allows your inputs and outputs to be retained for human review by AWS. Review is carried out by AWS within the AWS boundary — the model provider does not review your content”
— AWS documentation, "Amazon Bedrock data retention" (
aws_review mode; retrieved 2026-09-27)
⚠️ An approval workflow does not mean approval is always required. Microsoft's page lists scenarios where Lockbox does not trigger: “Emergency scenarios that fall outside of standard operating procedures and require urgent action from Microsoft to restore access to online services or to prevent corruption or loss of customer data, or to investigate a security or abuse incident. … These ‘break glass’ events are rare …”. Read ZOA as "no human access in normal operations, with the exception conditions published" — and note that the conditions themselves are documented, which is what makes them auditable.
6. Per-vendor availability: whether, what, and how to enable
Three separate questions: does it exist, which services does it cover, and how do you turn it on. Anything we could not verify is labelled as such.
| Vendor | Available? | Services (verified scope) | How to enable |
|---|---|---|---|
| AWS | ZOA: yes — stated as Amazon Bedrock's data security model HYOK: yes (KMS External Key Store) |
ZOA on Amazon Bedrock; HYOK on AWS KMS external key stores. Whether Bedrock itself supports XKS (HYOK) was not verified in this review. | Set the Bedrock data retention mode (per account / project / Region; inherit is the default for new projects). For HYOK, create an external key store in KMS and run your own XKS proxy. |
| Microsoft (Azure) | Process: yes (Customer Lockbox) Keys: yes (Managed HSM, Cloud HSM) Runtime: yes (confidential computing) |
Customer Lockbox covers Azure services. Managed HSM is a single-tenant, FIPS 140-3 Level 3 HSM. How far Customer Lockbox extends to models served through Microsoft Foundry was not verified. | Enable Customer Lockbox where supported, after which access requests need your approval. Keys: create a Managed HSM and govern it with local RBAC and an offline quorum. Runtime: confidential computing must be enabled and properly configured. |
| Google Cloud | Process: yes (Access Approval / Access Transparency) Keys: yes (Cloud EKM, CMEK) Key access control: yes (KAJ) |
Cloud EKM uses a supported external key management partner. Whether KAJ applies comprehensively to Vertex AI model calls was not verified. | Turn on Access Approval to gate personnel access. For KAJ, attach a policy to customer-managed keys and decide per justification code; with external keys the policy can be enforced on the partner side. |
| OpenAI | Keys: yes (Enterprise Key Management) Safety review: yes (ZDR with PSP) Runtime: preview (Private Inference, expected fall 2026) |
The API platform. EKM encrypts customer content with keys in your external KMS. PSP assumes customer-controlled storage plus customer-managed EKM authorisation. | In our review none of these is on by default; each needs configuration. Organisations already approved for ZDR configure PSP in the API console, registering and validating storage; EKM uses keys in your own external KMS; Private Inference is in preview. |
| Anthropic | Restricted access path: yes (controlled access path) ZDR: yes (on request) Customer-managed keys: not verified |
The first-party Claude API. We could not confirm official documentation of customer-managed keys or HYOK for the first-party API. Via Bedrock or Vertex you inherit the cloud provider's key controls. | ZDR is requested through your Anthropic account representative — but note that models requiring retention (Covered Models) are excluded from ZDR, as covered in #7. |
← scroll horizontally →
💡 Why we label items "not verified" instead of leaving them blank: a blank reads as "not offered," and a guess reads as fact. Both would be misinformation. Separating what is confirmed from what is not is the point of this site.
7. Three common misconceptions
- "We enabled ZDR, so the operator can't see our data either."
- Different promise. ZDR is about not keeping data; ZOA is about no human access. Protecting in-memory plaintext during processing is layer 3's job and does not change when you change retention mode. Verify both separately.
- "It's encrypted, so the operator can't read it."
- Only if you know who holds the key. Even with CMK, the key material sits in the provider's KMS and the provider's infrastructure performs decryption — that is not a guarantee against staff access. Only HYOK reaches "the material never leaves you" (AWS: “Your cryptographic key material never leaves your external key manager.”).
- "HYOK solves everything."
- It comes with trade-offs. External keys make every cryptographic operation depend on your system, moving availability, latency and operational responsibility to you. And HYOK addresses keys, not the runtime — it says nothing about plaintext in memory (layer 3). Different layers.
8. Five checks before you sign
- Identify which layer the vendor's "ZOA" claim refers to — process, keys or runtime. The setting you must configure depends on the answer.
- Verify ZDR and ZOA separately. For ZDR: default retention, request-only options, exception models. For ZOA: what is default, whether an approval workflow exists, what the exception conditions are.
- Decide how far up the key ladder you need to go — CMK or HYOK. If HYOK, design your own availability and operations story before signing.
- Actually enable the approval workflow and check it. Documentation existing is not the same as the control being active in your tenant or project.
- Read the emergency exceptions. Microsoft's "break glass," Google's justification codes and AWS's
aws_revieware all published. Claiming "no human can ever get in" without reading them is how audits break.
9. FAQ
- Which is the stronger protection, ZOA or ZDR?
- They protect different things rather than ranking. ZDR is "we do not keep it"; ZOA is "people cannot read it." Neither alone explains every incident — data can be seen in flight without being stored, and stored data can be unreadable. Check both.
- Does confidential computing guarantee that the operator cannot look in?
- Azure states it conditionally: “When Azure confidential computing is enabled and properly configured, Microsoft can’t access unencrypted customer data.” The qualifier is explicit, so confirmation is required rather than assumed. Azure's Confidential VM FAQ adds: “Azure doesn’t have operating procedures for granting confidential VM access to its employees, even if a customer authorizes the access.”
- Who actually uses the term "zero operator access"?
- In this review the term as a definitive statement was only confirmed at AWS (Amazon Bedrock). Microsoft frames it as "operator-access risk" and documents Customer Lockbox, confidential computing and Managed HSM separately. Google Cloud describes "requests from Google personnel" and splits the answer across Access Approval, Access Transparency and KAJ. The same goal is documented under different vocabulary.
- How should I write this up for an audit?
- Not "we use a ZOA provider," but which control was enabled at which layer: "retention mode is
none; keys are customer-managed; the personnel approval workflow is enabled, with exception conditions documented at [link]." That phrasing survives a change in vendor terms.
- Does any of this cost more?
- We found no documented price change attached to enabling ZOA controls in this review. HYOK does carry separate operational cost for your own HSM or key manager, and providers may offer such controls only on higher tiers. Check the provider's pricing pages directly — we track rates in our pricing comparison.
Note: how to read "◯B (Active ◯B)" model sizes
Model write-ups often show figures like "320B (18B Active)". That is how parameter counts describe a model's size, and B means one billion. The two numbers are not the same thing.
- Total parameters (e.g. 320B) — the sum of all the weights the model holds. It drives the file size and the memory needed to run it.
- Active (e.g. 18B Active) — the parameters actually used in the computation for each generated token. In mixture-of-experts (MoE) models only part of the whole is used each time.
So "320B (18B Active)" means "all 320B are not used on every token". The total tends to drive memory (can you fit it?), while Active drives compute, speed and cost — the same total with a different Active count feels faster or slower (actual speed and cost also depend on the model architecture and how it is served). We only publish figures the model provider itself has released, and we do not infer undisclosed breakdowns.
Related pages
The four data requirements
Retention, operator access, training terms and residency, separated. Includes a five-vendor matrix. Glossary #8.
Read it →Claude Sonnet 5.5
Released 2026-09-28 at $2/$10 with a 1M context — and five platforms whose data terms differ from one another.
Read it →Pricing comparison
Input, output and cache rates for major models, verified against official sources.
See pricing →Sources
- AWS, "Amazon Bedrock abuse detection" — definitions of ZOA and ZDR (docs.aws.amazon.com, retrieved 2026-09-27)
- AWS, "Data protection" and "Data retention" — model providers' lack of access, retention modes (
none,aws_review) (docs.aws.amazon.com) - AWS KMS, "External key stores," "Importing key material," "Key stores" — HYOK and BYOK (docs.aws.amazon.com, retrieved 2026-10-01)
- Microsoft Learn, "Customer Lockbox for Microsoft Azure" — approval, denial, four-day expiry, break-glass exception (learn.microsoft.com, retrieved 2026-10-01)
- Microsoft Learn, "Azure Confidential Computing Overview" and "Confidential VM FAQ" (learn.microsoft.com, retrieved 2026-10-01)
- Azure blog, "External key management for Azure Managed HSM" — key material, quorum, external key paths (azure.microsoft.com, retrieved 2026-10-01)
- Google Cloud, "Overview of Key Access Justifications" — division of labour with Access Approval and Access Transparency (docs.cloud.google.com, retrieved 2026-10-01)
- Google Cloud, "Cloud External Key Manager" (docs.cloud.google.com, retrieved 2026-10-01)
- OpenAI, "ZDR with Private Safety Processing" — no new human access path, hardware-attested runtime (developers.openai.com, retrieved 2026-10-01)
- OpenAI, "Data controls in the OpenAI platform" — Enterprise Key Management (developers.openai.com)
- OpenAI, "Register interest in OpenAI Private Intelligence" — Private Inference is in preview, combining confidential computing with verifiable controls (openai.com, checked 2026-10-01)
- Anthropic, "Data retention practices for covered models" — personnel cannot read retained conversations by default; controlled access path (support.claude.com, retrieved 2026-09-27)
⚠️ Disclaimer
- Content verified against official vendor documentation on 2026-10-01 (some items 2026-09-27). Specifications and terms change without notice — always confirm on the official pages.
- This page is not legal advice. Audit, contract and regulatory decisions belong with your agreements, DPAs and qualified advisers.
- Items marked "not verified" (Bedrock support for XKS, the reach of Customer Lockbox over models in Microsoft Foundry, KAJ coverage for Vertex AI, first-party Anthropic customer-managed keys) will be updated when primary sources allow.
- This site is informational only and is not affiliated with any provider.