OpenAI just gave its enterprise API customers something they have wanted for two years: the ability to run frontier models on OpenAI infrastructure without the company keeping a copy of their data, while still catching misuse across multiple interactions. On August 19, 2026, OpenAI announced that Zero Data Retention, previously available for a subset of API models, now extends to frontier models, paired with a new system called Private Safety Processing that evaluates patterns across interactions without exposing underlying content to OpenAI staff.
The announcement targets a tension that has grown sharper as AI agents take on multi-step tasks. Safety monitoring needs context across interactions to catch gradual misuse, but ZDR promised not to retain any content. Private Safety Processing is OpenAI's answer to that conflict. A technical white paper and production rollout are planned for September 2026.
What exactly did OpenAI announce on August 19?
Zero Data Retention is straightforward in principle. OpenAI does not retain customer prompts or model responses after a request is processed. Customer content is not available to OpenAI personnel for review. Enterprise customer data is not used to train OpenAI models unless customers explicitly opt in, a commitment that has been in place for the API platform since March 1, 2023, when OpenAI updated its data usage policy to exclude API data from training by default.
What changed on August 19 is twofold. First, ZDR now covers frontier models, not just the smaller models that previously qualified. Second, OpenAI previewed Private Safety Processing, a system designed to detect misuse patterns across related interactions while remaining compatible with the ZDR promise. Without PSP, ZDR-compatible safety systems could only evaluate each interaction in isolation.
The gap matters because the most serious AI safety risks are not always visible in a single request. OpenAI's announcement specifically calls out scenarios where harmful intentions become clear only when multiple interactions are viewed together: bad actors probing safeguards, coordinating across accounts, or disguising threats as routine research. The announcement also flags agentic risks, where a system continues to act after being told to stop.
Glean's Chief Information Security Officer, Sunil Agrawal, offered a supporting perspective in the announcement. "OpenAI's no-training commitment and ZDR give Glean confidence to build with OpenAI," Agrawal said. "As models become more capable, OpenAI shows safety can advance without compromising the privacy and control that sustain enterprise trust."
How does Private Safety Processing detect misuse without seeing your data?
Private Safety Processing works by evaluating customer content wherever it is stored and returning only a narrowly defined safety signal to OpenAI, never the underlying content itself. There are two deployment modes.
In the first mode, customer content stays on infrastructure the customer controls. This is the existing ZDR model. Automated systems run on that customer-controlled infrastructure, identify potential misuse, and return limited safety signals to OpenAI without exposing the prompts or responses.
In the second mode, which is new, customer content is stored on OpenAI infrastructure but encrypted with keys controlled by the customer. OpenAI personnel do not have copies of those keys, so they cannot access the underlying content. Automated systems can still evaluate the encrypted content for misuse patterns and return safety signals.
When a risk is identified, OpenAI receives a signal indicating the type of activity involved, similar to existing safety systems. OpenAI personnel do not get access to the customer content even when it is flagged. Customers can investigate alerts using information in their own systems and choose to share relevant information with OpenAI only if they want to appeal or support an investigation.
The technical claim is ambitious. Brian Levine, executive director at security consultancy FormerGov, told CSO Online that monitoring for abuse without staff reading the underlying content is "a strong technical promise, because watching for misuse and not being able to see the data have historically pulled in opposite directions." Levine also noted that the proof is a white paper that is still weeks away.
Private Safety Processing is currently being tested with early customers. OpenAI has not yet published the technical details that would let independent security researchers verify the claims. The chart below summarizes what each retention mode actually retains and what each can detect.
Under standard API usage, abuse monitoring logs retain customer content for up to 30 days and staff can review flagged content. Under ZDR plus Private Safety Processing, abuse log retention drops to zero, staff content access drops to zero, and cross-interaction safety detection is added. That is the tradeoff in one sentence: you give up human reviewability and gain automated pattern detection that works without content access.
Which endpoints and workloads actually qualify for zero data retention?
Not everything you can call through the OpenAI API qualifies for ZDR. According to OpenAI's API data controls documentation, ZDR eligibility varies by endpoint. The chat completions and responses endpoints, which power most API integrations, are ZDR eligible. The conversations endpoints, which support persistent multi-turn sessions, are not.
| Endpoint | ZDR eligible | Application state retained |
|---|---|---|
| /v1/chat/completions | Yes | No |
| /v1/responses | Yes | No |
| /v1/conversations | No | Yes, until deleted |
| /v1/conversations/items | No | Yes, until deleted |
If you are building a stateful agent that relies on OpenAI's conversation management, ZDR does not apply. The content is retained until you delete it, and OpenAI personnel could access it under existing safety protocols.
There is also a legal carve-out that overrides ZDR entirely. OpenAI is required by law to report apparent child sexual abuse material. Images flagged for potential CSAM will continue to be retained for manual review and reporting purposes, even in Zero Data Retention deployments. This exception is not new, but it is the one place where the ZDR promise has a hard stop.
Under standard usage, abuse monitoring logs retain customer content for up to 30 days, per the same documentation. Both Modified Abuse Monitoring and ZDR exclude these logs. But customers must apply and be approved for either control. It is not a toggle you flip in a dashboard. Once approved, configuration is available in Settings under Organization and Data controls, at both the organization and project level.
What does this change for your enterprise AI architecture?
If you are building on OpenAI's API and have been holding back sensitive workloads because of data retention concerns, this announcement removes a significant blocker. But the practical impact depends on what you are building and which endpoints you depend on.
For teams running chat completions or the responses API with stateless orchestration on their own side, ZDR plus Private Safety Processing means you can tell your security reviewers that OpenAI retains zero customer content after processing. That is a meaningful claim for regulated industries handling financial records, health data, or proprietary research.
For teams building stateful agents on the conversations API, the picture is different. Those endpoints are not ZDR eligible, and customer content is retained until you delete it. If your architecture depends on OpenAI managing conversation state, you do not get the ZDR guarantee.
The compliance stakes are real. OpenAI's announcement notes that some recent frontier-model deployments have required customers to allow their AI provider to retain sensitive content for safety monitoring, a requirement that conflicts with security obligations in many organizations. If you have been on the fence about EU AI Act transparency obligations or evaluating vendors against OpenAI's own critical cyber capability thresholds, the ZDR expansion narrows the gap between what OpenAI offers and what a privacy-first enterprise procurement process demands.
What this means for you:
- If you use /v1/chat/completions or /v1/responses with your own state management, you can now pursue ZDR approval for frontier models and tell regulators that prompts and responses are not retained.
- If you depend on /v1/conversations for persistent sessions, you are not covered. Redesign to manage state externally if ZDR is a procurement requirement.
- If you operate under HIPAA or similar health-data regimes, OpenAI offers a Business Associate Addendum for BAA-eligible endpoints, but ZDR and BAA interact in specific ways. Review the Safety Retention documentation before assuming both apply simultaneously.
- Budget time for the approval process. ZDR and Modified Abuse Monitoring both require prior OpenAI approval and acceptance of additional requirements. This is not self-serve.
What should you watch for in the September rollout?
OpenAI plans to start rolling out Private Safety Processing and share a technical white paper in September 2026. Until that paper lands, the core technical claim, that safety signals can be generated from content OpenAI personnel cannot read, is unverifiable by third parties. Here is what to watch:
- The white paper needs to explain how pattern detection works on content OpenAI staff cannot access. If the system uses homomorphic encryption, secure enclaves, or some form of on-device inference, the architecture matters for your threat model.
- Early customer results will signal whether PSP generates false positives at rates that disrupt production workloads. A safety signal that fires on legitimate research queries or complex agentic workflows could block traffic without giving you visibility into why.
- OpenAI reserves the right to make specific models ineligible for ZDR or Modified Abuse Monitoring for specific customers, with advance written notice, if it deems it necessary to investigate or prevent severe risk. Read the fine print on what "advance notice" means in practice.
- The customer-controlled-key encryption model is still under development. If your architecture requires bring-your-own-key, confirm that the September rollout includes it rather than only the customer-controlled-infrastructure mode.
The broader question is whether other frontier providers follow suit. Anthropic, Google, and Mistral all face the same tension between safety monitoring and data retention as agents take on longer tasks. If OpenAI's approach works technically, it becomes a procurement baseline. If it does not, the industry keeps the awkward status quo where safety and privacy pull in opposite directions.
The signal without the content
Private Safety Processing is a bet that you can have both safety monitoring and zero data retention, if you are willing to trust automated classifiers you cannot inspect. For a lot of enterprises, that bet is worth taking. The alternative is choosing between a model provider that sees everything you send and one that sees nothing but also catches nothing. OpenAI is trying to break that dichotomy, and whether it succeeds depends on a white paper that does not exist yet and early-customer results that are not public. September will tell you whether the promise holds.
