OpenAI Previews Private Safety Processing to Preserve Zero Data Retention
OpenAI is testing cross-interaction safety monitoring that keeps frontier-model customer content inaccessible to its personnel.
OpenAI is testing a safety system designed to detect misuse across related interactions without giving its personnel access to the underlying customer content. Announced on August 19, 2026, Private Safety Processing is intended to let eligible API customers continue using Zero Data Retention, or ZDR, as frontier models take on longer and more autonomous tasks.
The preview addresses a specific limitation in OpenAI’s existing ZDR-compatible safeguards. Those systems evaluate interactions individually. Private Safety Processing instead looks for patterns across related interactions, where malicious intent, repeated attempts to bypass safeguards, or an agent’s departure from its assigned authority may become visible only over time.
OpenAI is testing the system with early customers. It plans to begin a rollout and publish a technical white paper in September. The company has not yet disclosed pricing, a complete list of supported models, independent evaluation results, false-positive rates, or the detailed computing architecture behind the privacy claim.
1. What OpenAI Is Changing
Zero Data Retention excludes eligible customers’ prompts and model responses from OpenAI’s abuse-monitoring logs after a request has been processed. Customer content covered by ZDR is not available to OpenAI personnel for routine review, and API data is not used to train OpenAI models unless the customer explicitly opts in.
That privacy control creates a safety constraint. Under OpenAI’s previous ZDR-compatible approach, automated systems could inspect each interaction as it occurred, but they could not rely on retained customer content to connect activity across multiple conversations or stages of an agentic workflow.
OpenAI says some risks cannot be identified reliably from one prompt-and-response pair. A user might repeatedly probe safeguards, distribute related requests across accounts, or present individual steps of a harmful operation as legitimate research. Each request may appear acceptable in isolation even when the combined sequence indicates misuse.
Long-running agents introduce another category of risk. OpenAI’s announcement gives the example of an agent continuing to act after being instructed to stop. Detecting that behavior requires a view of the task’s history and the authority the user originally granted, not merely an assessment of the agent’s latest action.
Aleah Houze, OpenAI’s head of product policy, offered a cybersecurity example during a media briefing reported by Axios: one conversation might concern weaknesses in a company’s software, while a later interaction asks about remote access or the security tools capable of detecting it. The sequence can carry a different risk profile from either request considered alone.
Private Safety Processing is intended to add that broader context while retaining the central ZDR restriction: OpenAI personnel should not receive the prompts, responses, or other underlying customer content.
2. How Private Safety Processing Is Supposed to Work
OpenAI has described two possible storage arrangements.
In an existing ZDR deployment, customer content remains on infrastructure controlled by the customer. Private Safety Processing uses that content for automated analysis without transferring the underlying prompts or responses to OpenAI personnel.
OpenAI is also developing a second option in which content is stored on OpenAI infrastructure but encrypted with keys controlled by the customer. OpenAI says its personnel will not possess copies of those keys and therefore will not be able to access the content.
Under either arrangement, automated systems analyze related interactions for patterns of potential misuse. If the system identifies a risk, OpenAI receives what it calls a narrowly defined safety signal indicating the type of activity involved. That signal may be used to decide whether enforcement is necessary, but it does not include the customer content that produced the alert.
Flagging content does not automatically make it available to OpenAI personnel. Customers instead investigate alerts or enforcement decisions using records available in their own systems. They may voluntarily share relevant information with OpenAI if they want to appeal a decision, demonstrate that an activity was legitimate, or assist an investigation into confirmed abuse.
This is an architectural description, not yet a fully documented security protocol. OpenAI has not publicly specified how its automated systems gain access to customer-controlled content, how related interactions are associated, what metadata accompanies a safety signal, or how the system prevents those signals from revealing sensitive information indirectly. The promised September white paper will therefore be necessary to evaluate the implementation rather than only its stated properties.
3. How This Differs From Existing API Data Controls
Under OpenAI’s standard API configuration, abuse-monitoring logs may contain prompts, responses, and derived metadata such as classifier outputs. The company’s documentation says those logs are retained for up to 30 days by default, although longer retention may occur when legally required or reasonably necessary to prevent harm.
ZDR is not the default for every customer. Organizations must receive OpenAI approval, accept additional requirements, and configure the control at the organization or project level. Approved customers remain responsible for ensuring that their own users comply with OpenAI’s usage policies and applicable reporting or moderation obligations.
ZDR also changes API behavior. For the Responses and Chat Completions APIs, the store parameter is treated as false even if a request attempts to enable storage. However, ZDR does not make every OpenAI feature retention-free. Some endpoints are ineligible because their functions require application state, and data sent to third-party services such as remote MCP servers remains subject to those services’ policies.
Private Safety Processing does not replace these endpoint-level rules. Its purpose is narrower: to extend automated safeguards from isolated interactions to related activity without converting eligible deployments back to conventional content retention and human review.
The preview also does not change consumer ChatGPT data controls. Axios reports that the system is intended for eligible enterprise and API customers, not subscribers using ChatGPT Free, Plus, Go, or Pro. OpenAI’s announcement itself frames ZDR as a control for eligible API customers.
4. The Privacy Promise Has Defined Limits
OpenAI’s announcement should not be read as a claim that no data associated with an API request is ever processed or stored. Its documentation distinguishes customer content from system data such as account information, billing records, analytics, usage statistics, and support requests.
The documentation also reserves the right to make particular models ineligible for ZDR for specific customers under defined conditions and with written advance notice. Its “Safety Retention” provision permits retention and human review of content flagged by classifiers when OpenAI considers that reasonably necessary to investigate or prevent severe-risk activity.
A separate exception applies to apparent child sexual abuse material. OpenAI says images flagged as potential CSAM will continue to be retained for manual review and legally required reporting even in ZDR deployments.
Application features can impose additional storage requirements. OpenAI’s current documentation says the Responses API normally retains application state for at least 30 days when storage is enabled, while background processing writes response data to disk temporarily so clients can poll for results. Files, persistent conversation objects, hosted tools, prompt caching, and third-party connections each have their own retention characteristics.
Companies assessing Private Safety Processing will therefore need to examine the exact endpoint, model, tool, and contract configuration involved. The product announcement establishes the intended treatment of content within the new safety system; it does not supersede every exception and compatibility rule in OpenAI’s broader data-control documentation.
5. What the Preview Means for Enterprise AI Deployments
The immediate impact is predictability for organizations that cannot place sensitive prompts or outputs in provider-accessible logs. OpenAI specifically identifies financial records, health information, confidential business plans, and proprietary research as categories handled by customers participating in the system’s development.
For those customers, requiring retained content as the price of accessing a more capable model can create conflicts with internal security policies, contractual confidentiality duties, or regulatory obligations. Private Safety Processing is OpenAI’s attempt to separate two functions that have traditionally been coupled: correlating activity over time and allowing provider personnel to inspect the underlying records.
The system could also change how enforcement disputes are handled. Because OpenAI personnel would not receive the flagged content, the customer becomes the primary holder of the evidence needed to explain legitimate activity or investigate abuse. That preserves customer control but may make appeals and incident response more dependent on the customer’s own logging and governance systems.
The preview does not yet establish that Private Safety Processing detects multi-interaction misuse as accurately as retention-based monitoring. OpenAI has published no benchmark, audit, threat model, or independent assessment supporting that comparison. Early customers must also evaluate whether the safety signals expose enough information to support enforcement without becoming a side channel for sensitive content.
The September rollout and technical paper are consequently part of the product change, not incidental follow-ups. They will determine which frontier models and API configurations qualify, what customers must deploy, how encryption keys are managed, and what evidence is available to validate OpenAI’s claim that cross-interaction monitoring can operate without personnel access to customer content.
Frequently Asked Questions
What is Private Safety Processing?
It is an OpenAI safety system designed to detect risky patterns across related interactions while preventing OpenAI personnel from accessing the underlying customer content.
Is Private Safety Processing generally available?
No. OpenAI is testing it with early customers and plans to begin rolling it out in September 2026.
Does Zero Data Retention apply automatically to every API customer?
No. ZDR requires approval from OpenAI, acceptance of additional requirements, and compatible API endpoints and features.
Does the announcement change ChatGPT consumer data controls?
No. The preview concerns eligible enterprise and API customers. Existing controls for consumer ChatGPT plans remain unchanged.
Has OpenAI published technical proof of the privacy design?
Not yet. OpenAI says it will release a technical white paper in September, and it has not published independent validation or detailed performance measurements.
Sources
Share