On August 19, 2026, OpenAI previewed "Private Safety Processing" for its frontier models. The design is meant to detect abuse patterns across multiple related conversations belonging to customers who have opted into Zero Data Retention (ZDR), without passing that content to OpenAI staff. Until now, ZDR-compliant safety systems evaluated conversations one at a time, leaving open the question of how to handle behavior that only becomes visible when conversation history is linked together. Where safety monitoring and retention policy come into tension, OpenAI has proposed a method that returns limited safety signals instead of raw content.
Private Safety Processing is currently in a preview stage, being tested with early customers. OpenAI plans to begin a phased rollout in September 2026 and will also publish a technical white paper. This is neither a general availability release that all customers can use immediately, nor a finished, independently audited system. With that caveat in place, the announcement could still change how enterprises audit ZDR.
Abuse patterns that single-turn evaluation can't catch
As frontier models take on longer, agentic tasks, harmful requests become harder to judge from a single prompt alone. OpenAI cited examples such as behavior that continues after a stop command, probing split across multiple accounts, and a series of requests disguised as research. In each case, no single conversation taken in isolation is clearly dangerous — the intent of the activity can only emerge from the combination of related history.
Current ZDR-compliant safety systems evaluate each conversation independently. That's because honoring ZDR's requirement to exclude customer content from abuse-monitoring logs made it natural to avoid aggregating conversation history on OpenAI's side. But that design also cuts off the information needed to detect behavior that spans multiple conversations. Private Safety Processing points toward a different approach: evaluating related conversations together while keeping the content on customer-controlled infrastructure.
"Monitoring" here does not mean letting OpenAI staff read users' conversations. According to OpenAI, automated systems process the customer content, but only limited safety signals indicating categories of activity are returned to OpenAI. Whether correlation can be handled without ever exposing raw content is the central question this design has to answer. How much the signals reveal about the underlying content, and how associations across different customers or accounts are determined, have not yet been disclosed.
A pathway that returns alerts, not raw text
According to OpenAI's explanation, in ZDR deployments customer content stays on customer-controlled infrastructure. Even when Private Safety Processing detects a risk, OpenAI staff do not receive that customer content. Instead, customers use information within their own systems to check which alerts were triggered and what enforcement decisions are required. Only when disputing an alert or explaining legitimate use can customers voluntarily share the necessary information.
This pathway is designed to separate information that stays under customer control from information that reaches OpenAI. So the fact that "staff don't receive raw content" does not mean content is never processed at all, or that no metadata exists. Automated systems process the content in order to detect patterns across multiple conversations, and limited safety signals are generated as a result. What enterprises need to verify isn't a simple yes-or-no question about whether processing occurs, but rather which data is processed where, and what information is returned to whom.
OpenAI is separately developing another option: encrypting data stored on its own infrastructure with customer-managed keys, such that OpenAI staff do not hold the keys. This is not part of the current offering. Treating ZDR deployments — where data sits on customer-controlled infrastructure — as equivalent to a customer-managed-key storage scheme on OpenAI's own infrastructure would be a mistake when mapping out the data path during implementation.
For a safety-signal-based operation to work in practice, customers need to be able to investigate the reasoning behind alerts and enforcement decisions on their own end. This may require more verification work from customers than an arrangement where OpenAI staff handle raw content directly, but as of this announcement, the categorization of alerts, their granularity, and the procedure for handling false positives have not been disclosed. How much information customers can access to dispute an alert will also be a practical item to check once the white paper is published.
Reading ZDR as three separate commitments
OpenAI API's standard abuse-monitoring logs can include prompts, responses, and classifier outputs, and are retained for up to 30 days by default. Using ZDR together with Modified Abuse Monitoring requires prior approval and acceptance of additional requirements — it is not available unconditionally to all API customers. It's also configured at the organization or project level, so contract and approval status need to be confirmed.
Under approved ZDR, customer content is excluded from abuse-monitoring logs, and store is always treated as false for the Responses API and Chat Completions API. This is a retention-related setting. Separately, API business data is not used for model training by default, and is only shared if a customer explicitly opts in. Not using data for training and how much data remains in monitoring logs or application state are separate controls that should be read independently.
Furthermore, ZDR is not a label that guarantees no application state is retained across all features. According to current data-management documentation, the Conversations and Assistants-related APIs, as well as Vector Stores and Files, are not ZDR-eligible. These endpoints and features can retain state. Even in a system built around ZDR assumptions, the data path varies depending on which API features are used.
The Responses API has its own individual exceptions as well. Prompt caching can retain encrypted key/value tensors locally on GPUs for up to 24 hours. Application state for audio output may persist for one hour to support multi-turn use, and Background mode may store data to disk for about 10 minutes for polling purposes. Data passed to third-party MCP servers or external services follows that party's own retention policy, not OpenAI's ZDR.
Image and file inputs carry additional exceptions for legal compliance. OpenAI scans them for CSAM detection, and images classified as suspected CSAM are retained for manual review and legal reporting even under ZDR. In enterprise audits, it's best not to lump together "not used for training," "raw content excluded from abuse-monitoring logs," and "OpenAI staff don't receive raw content" as a single commitment. Approval status and the specific endpoints in use need to be checked, along with caching and temporary state. Third-party integrations and legal exceptions should be reviewed as separate items.
Anthropic chose 30-day retention
How to detect attacks that span multiple requests is not a problem unique to OpenAI. Anthropic has stated a policy of retaining all traffic for 30 days for its Covered Models. These include Claude Fable 5 and Mythos 5, and the stated reason is to examine attacks that span multiple requests, such as Best-of-N jailbreaks. Organizations that previously used ZDR must also enable 30-day retention when using Covered Models.
The two companies' official policies place different answers on the same problem. Anthropic chose a 30-day retention window for safety monitoring, while OpenAI, still in preview with Private Safety Processing, is proposing correlation-based monitoring built on limited signals separated from raw content. This is not a comparison indicating which approach is safer. Neither company has demonstrated equivalent detection capability, nor has OpenAI positioned this as a direct response to Anthropic.
Still, enterprise procurement criteria include not just model performance and pricing but also the design of safety monitoring. Models that handle longer tasks need better ways to catch abuse that isn't visible in a single conversation, while retention periods and the scope of human access directly affect how enterprise data is handled. Safety teams, legal, and engineering departments will end up comparing which design fits which use case.
What to watch for as the September rollout and white paper arrive
OpenAI is testing Private Safety Processing with early customers and plans to begin a phased rollout in September 2026. The announcement also previewed a technical white paper, but the conditions under which related conversations get linked together have not been disclosed. If the design is meant to detect probing that spans multiple accounts, the unit of association and the safeguards against mistaken associations will shape how customers assess their own risk.
Another point to verify is the content of the limited safety signals. If customers are expected to investigate alerts and enforcement decisions themselves, the signals need to serve both as a basis for explaining legitimate use and as an entry point for correcting false positives. On the other hand, if the signals are too detailed, it raises the question of how much of the protection intended by withholding raw content can actually be preserved. Where that line gets drawn can't be judged until the implementation details are explained.
A distinction also needs to be drawn between the current ZDR deployment model, where data sits on customer-controlled infrastructure, and the customer-managed-key scheme still under development. Without knowing who manages the keys and who can perform which operations during an outage or investigation, the explanation that "OpenAI doesn't hold the keys" alone is not enough to make an adoption decision. For systems that include external MCP servers or other connected services, the retention policies governing data that leaves OpenAI's own configuration also need to be checked separately.
Once the technical white paper and phased rollout clarify the definition of "related conversations," the granularity of the signals, and the procedure for handling false positives, enterprises will be able to evaluate whether they can satisfy safety monitoring and ZDR at the same time. Key management practices and third-party verification will also be essential. This preview is not an announcement promising that outcome — it is a starting point for testing a design meant to decouple monitoring from the assumption of retention.