OpenAI expands Zero Data Retention and previews Private Safety Processing
OpenAI is pairing frontier-model ZDR with private abuse-pattern detection. We analyse scope, the CSAM exception, customer keys and due-diligence questions.
- AUTHOR
- Karol Rapacz / CEO Breachroad · OSCP · PNPT
- PUBLISHED
- 19 August 2026
- READING TIME
- 16 min read
- TOPIC
- AI Security
OpenAI announced on 19 August 2026 that it is extending Zero Data Retention to eligible API customers using frontier models. It also previewed Private Safety Processing, intended to detect patterns of related abuse without exposing customer content to OpenAI personnel. Early deployments are under way, with broader technical information and a white paper planned for September.
This matters to organisations that could not previously send data to the most capable models because of retention and operator-access requirements. It is not a universal promise that “OpenAI sees nothing.” ZDR requires customer eligibility and confirmed scope, Private Safety Processing remains a preview or early programme, and the announcement includes a legal exception for child sexual abuse material.
What OpenAI promises under Zero Data Retention
For an eligible request, the prompt and response are not retained after processing and are not available to OpenAI personnel. The company also reiterates that business customer data is not used to train models unless a customer explicitly opts in.
Retention and training are separate axes. Data may be excluded from training yet remain in security logs for a period. Conversely, content may be deleted after a request while technical metadata follows another policy. A good assessment cannot stop at “training: no.” It must cover content, attachments, caches, logs, identifiers, telemetry, backups and support procedures.
OpenAI describes customer content for ZDR as remaining on customer-controlled infrastructure. It is also developing OpenAI-side storage encrypted using customer-controlled keys, with no key copy available to OpenAI personnel. Availability, region, lifecycle and recovery mechanics must be confirmed in documentation and the agreement for the actual implementation.
What Private Safety Processing is meant to do
A provider’s safety system faces a difficult problem: detecting coordinated misuse while ZDR removes the content a person might later inspect. Private Safety Processing is intended to analyse relationships between interactions and emit narrowly defined safety signals instead of prompt or response content.
OpenAI says its automated systems do not expose customer content to personnel. A signal may indicate a likely pattern, while the customer investigates using its own systems and may choose to provide more information. The customer environment remains the place containing incident context.
Conceptually, this resembles private matching or feature assessment, but the announcement does not yet provide enough information to assert a specific cryptographic design, accuracy level or resistance property. Until the white paper is available, precise terms are “preview,” “stated architecture” and “early deployment,” not “independently verified privacy.”
What can a signal reveal without content?
A safety signal can represent a classification result, a relationship between events, a threshold crossing or a risk category. Its granularity and reidentification potential matter. Even without a full prompt, a combination of time, project identifier, tool type, region and rare pattern can carry privacy significance.
Before deployment, establish:
- exactly which fields leave the customer environment;
- whether signals exist per user, project, organisation or global cluster;
- how long they are kept and which personnel can access them;
- whether safety processing sees attachments, images, tool calls and results;
- which thresholds create an alert and expected false-positive rates;
- whether customers receive a decision log, classifier version and configuration evidence;
- how correction, appeal and deletion work for an incorrectly linked signal.
“No content” is a valuable design property, but it is not automatically complete anonymisation. A DPIA should include metadata and the ability to link it back to a person within the customer system.
The CSAM exception
OpenAI explicitly identifies an exception for images suspected of depicting child sexual abuse. A flag may lead to retention for manual review and legally required reporting, including under ZDR. An organisation therefore needs to understand that the no-retention promise has a legal and safety boundary.
This does not mean ordinary customer data can be kept at will. It means the architecture handles a special category for which the provider has statutory obligations. The agreement and processing register should identify legal basis, party roles, retention, human access, jurisdiction and notice where law permits.
Organisations handling medical, moderation, investigative or synthetic imagery should ask about false positives and a safe appeal route. They must not test the system by transmitting prohibited material. Validation should use approved synthetic datasets and provider documentation.
A customer-controlled key does not solve everything
A customer-managed or customer-controlled key reduces access risk for stored data. There is still a point where a system decrypts content for inference. Security then depends on environment attestation, workload access to the key, caches, process memory, crash logs and administrative capability.
Keys need scope separation by environment or tenant, controlled rotation and an explicit revocation process. Customers should know what happens after key loss, whether the provider can recover data, which copies use the same key material and whether key destruction technically provides crypto-shredding.
The storage key should also be separate from API credentials. Theft of a model-calling token should not grant key administration, and compromise of KMS should not automatically allow requests as a user. KMS and API audit trails need SOC correlation.
Due-diligence questions before signing
Customers need written answers covering eligible models, endpoints and features. Basic text may follow a different path from files, batch, fine-tuning, background jobs, web search, computer use or external tools. If a feature is outside scope, the application must technically block it or classify data before routing.
Operational questions include:
- Is ZDR configured at organisation, project, API key or request level?
- How can a customer prove it was active for a particular request ID?
- Which metadata and safety signals remain, in which region and for how long?
- Can subprocessors or external tools see content?
- How does support diagnose failure without prompt access?
- How do legal hold, government requests and jurisdiction conflicts work?
- How will the customer learn about a scope or safety-model change?
The DPA, technical-measures description, subprocessor list and service terms should match the architecture. A marketing slide cannot substitute for contractual control and configuration evidence.
Designing an application for ZDR
The safest pattern begins with minimisation. The application removes unnecessary identifiers, secrets and personal data before calling a model. A customer-side classifier routes only approved categories to the correct endpoint. RAG retrieves minimal passages, and a tool broker avoids returning a complete record when the model needs only a Boolean result.
Customer logs also need attention. Provider-side ZDR has little value if the customer’s API gateway stores full prompts, APM captures request bodies and support software copies responses into tickets. AI agent observability should separate metrics and traces from content and apply redaction before export.
Incident response must work without a provider content log. Retain request identifiers, model release, policy hash, invoked tools and control outcomes. Keep sensitive content only on the customer side under the organisation’s retention and access policy.
Facts and Breachroad conclusions
The ZDR offer for eligible customers, Private Safety Processing, content-free safety signals, customer-controlled keys, early deployments and CSAM exception are facts from OpenAI’s announcement. Details should be verified in documentation, contracts and the September white paper. KMS, DPIA, out-of-scope feature and configuration-evidence questions are Breachroad analysis.
We do not claim the preview provides formal confidentiality for every use case or removes controller obligations. ZDR can materially reduce surface area, but it works best with minimisation, customer controls and architecture testing.
AI and cybersecurity training helps legal, engineering and data-owner teams use a shared retention model. ZDR scope, log paths, RAG, KMS and tools can then be verified in an AI security assessment.
