A security system cannot look across sessions if every prompt disappears after the request. OpenAI’s answer is to let an automated detector see the pattern while keeping the underlying conversation away from its personnel.
That is the design behind Private Safety Processing, an August 19 preview for eligible OpenAI zero data retention API deployments. OpenAI says customer prompts and model responses are not retained after processing, are unavailable to its personnel, and are not used for training unless an enterprise customer explicitly opts in.
The new layer is meant to detect harmful patterns across related interactions. When it finds one, OpenAI says it receives a narrowly defined signal describing the activity type, not the prompts or responses. Early customer testing is underway. A rollout and technical white paper are planned for September 2026.
Zero retention is a narrow promise
Zero Data Retention, or ZDR, applies to eligible API customers. The promise concerns prompts and responses after a request is processed. It does not mean the surrounding customer system has no logs, that every integration inherits ZDR, or that no operational metadata exists.
A builder must map the complete path: client application, gateway, observability vendor, agent memory, vector store, tool servers, support exports, and provider endpoint. One retained transcript in an application log can defeat a provider-level retention policy.
OpenAI says the current ZDR design keeps customer content on infrastructure controlled by the customer. It is also developing an OpenAI-hosted option where content is encrypted with customer-controlled keys that OpenAI personnel do not possess. The hosted design is not the same as “available now,” and teams should wait for the technical paper before assuming how key rotation, recovery, indexing, or deletion will work.
Private Safety Processing changes the signal path
Existing ZDR-compatible systems evaluate interactions one at a time. OpenAI argues that some risk becomes visible only across repeated probing, coordinated accounts, or a long agent task. Private Safety Processing adds a cross-interaction detector without giving staff access to the retained customer content.
| Participant | Content access | Safety information |
|---|---|---|
| Customer | Prompts, responses, and its own logs | Information in its systems for investigation or appeal |
| Automated safety system | Uses customer content to detect related patterns | Produces a limited activity-type signal |
| OpenAI personnel | No access to underlying prompts or responses | Receives the limited signal for possible enforcement |
The word “limited” needs a specification. A security team should ask which categories exist, whether a signal contains account or project identifiers, how long it survives, who can query it, what action it can trigger, and how a customer contests a false positive without revealing sensitive content.
The design shifts evidence back to the customer
OpenAI says customers can investigate alerts and enforcement decisions using information available in their own systems. They can choose to share relevant material when appealing or supporting an abuse investigation.
That arrangement protects confidentiality, but it creates an operational requirement. A customer that retains nothing may be unable to reconstruct why a safety signal fired. A customer that records everything can undercut the privacy reason for selecting ZDR. The practical solution is a deliberately minimal audit record: hashed session identifiers, tool actions, policy version, timestamps, signal category, and customer-side evidence under a documented retention schedule.
Our analysis of Claude Inference Hooks reaches the same control-plane question from another direction. A safety service in the critical path needs explicit failure behavior, an appeal route, and enough logging to distinguish a blocked threat from a broken policy server.
There is one explicit retention exception
OpenAI’s footnote states that images flagged as possible child sexual abuse material will continue to be retained for manual review and legal reporting, including in ZDR deployments. This is a material exception and belongs in procurement documents, data-flow diagrams, and user disclosures where image inputs are possible.
The exception also shows why “zero” should never end the review. Legal obligations, abuse reporting, billing, rate limiting, and security telemetry can create separate data paths. Teams should list each path and its governing policy instead of relying on a product label.
A pre-rollout test for security teams
- Confirm eligibility and endpoints. Record which projects, models, modalities, and features actually receive ZDR treatment.
- Trace every copy. Inspect application logs, queues, retries, caches, agent memory, tool servers, support systems, and backups.
- Define the signal contract. Ask for categories, fields, retention, access roles, enforcement actions, and customer notification behavior.
- Exercise a false positive. Confirm the customer can investigate and appeal without handing over a complete confidential transcript.
- Test provider unavailability. Decide whether a safety-service failure blocks, delays, or allows the model request, and record the exception.
- Separate the CSAM path. Document image handling, manual review, reporting, jurisdiction, and user notice with qualified counsel.
This is particularly important for agent systems. Our review of cyber-evaluation incidents showed how consequential behavior can emerge across runs, credentials, and shared infrastructure. Cross-session detection is valuable only when the customer understands what is linked and what action follows.
My verdict: wait for the signal specification
Private Safety Processing is a serious attempt to keep cross-interaction safeguards compatible with strict data control. The architecture is more useful than asking customers to waive retention requirements whenever a model becomes more capable.
The preview is not enough for production approval. Before enabling it, I would require the September white paper, a field-level description of the safety signal, a false-positive exercise, and a signed data-flow map covering the customer stack. Privacy is not proven by denying staff access alone; it is proven by knowing every place the content and its derivatives can go.
Read the primary record
- Read OpenAI’s Private Safety Processing and Zero Data Retention preview.
- Review OpenAI’s enterprise privacy commitments.
- Check the API data-controls documentation for endpoint-specific retention behavior.
Could your team appeal a safety signal without recreating the sensitive transcript you chose ZDR to avoid?
Checked August 24, 2026. Architecture, personnel-access claims, signal behavior, rollout timing, and the CSAM exception come from OpenAI’s August 19 preview. The technical white paper had not yet been published.
