OpenAI’s Private Safety Processing: How It Detects AI Misuse Without Retaining Customer Content

OpenAI is previewing Private Safety Processing, a safety architecture designed for eligible API customers using Zero Data Retention (ZDR). Its central promise is straightforward: detect misuse patterns that only become visible across multiple related interactions without giving OpenAI personnel default access to the underlying customer content.

That matters because increasingly capable models can be used through longer, more distributed workflows. A harmful objective may be split across accounts, sessions, or requests so that no single interaction clearly reveals the full pattern. Private Safety Processing is intended to add that broader context while preserving ZDR protections.

How Private Safety Processing works

Existing ZDR safeguards evaluate requests and responses individually. OpenAI’s preview expands that approach by using automated systems to assess relationships among multiple interactions. The goal is to identify patterns associated with potential misuse, including coordinated attempts to evade guardrails or divide malware-development tasks across separate requests.

The important distinction is between analysis and retention. Private Safety Processing is designed to analyze related activity for safety purposes, but OpenAI says the underlying prompts and model responses are not exposed to its personnel through the system.

OpenAI describes two possible data-control arrangements for ZDR deployments:

• Customer content can remain on infrastructure controlled by the customer.
• In an OpenAI-hosted-storage arrangement, the content can be encrypted with keys controlled by the customer rather than by OpenAI personnel.

In either case, automated systems can identify potential misuse and return a limited safety signal without exposing the underlying prompts or responses.

What does OpenAI receive when it detects a threat?

According to the description of the preview, OpenAI receives a narrowly scoped alert about the type of activity involved. OpenAI’s system diagram characterizes the output as an alert category and severity, rather than the conversation itself.

That signal can support safety or enforcement decisions, but it is not equivalent to sending OpenAI the full session history. The practical model is:

1. Automated systems examine related interactions for a potentially harmful pattern.
2. If the pattern crosses a risk threshold, the system generates a limited safety classification.
3. OpenAI receives that classification rather than the prompts, outputs, or conversation transcript.
4. The customer retains the ability to investigate the underlying activity in its own environment.

This is still a preview, so the precise implementation, thresholds, and error-handling procedures will matter to enterprise buyers. OpenAI said it planned a broader rollout and a technical white paper in September 2026.

Why OpenAI personnel ordinarily cannot read a flagged conversation

A safety flag does not automatically give OpenAI staff access to the conversation because, under the described ZDR arrangements, OpenAI says it does not retain the customer content or possess the customer-controlled decryption keys in the OpenAI-hosted-storage design.

Customers can choose to share relevant material if they want to appeal an enforcement action, explain legitimate use, or help investigate confirmed abuse. Without that voluntary disclosure, the flag itself is limited to the machine-generated safety information sent to OpenAI.

This creates a separation between customer-controlled evidence and provider-level risk signals. It may reduce the amount of sensitive material a provider must handle, while still giving the provider a way to identify patterns that an isolated request-by-request filter could miss.

Which customers are testing the preview?

OpenAI has identified Glean, Databricks, Abridge, and Microsoft among the customers helping shape or test the preview. Other reporting also identifies Microsoft and Databricks as early customers involved in testing.

The feature is not presented as a general consumer setting. It is aimed at eligible API deployments where organizations want access to advanced models while maintaining strict control over prompts and outputs.

OpenAI versus Anthropic: two different safety trade-offs

OpenAI’s approach prioritizes detecting misuse while minimizing provider access to customer content. Anthropic’s covered-model policy makes the opposite trade-off: prompts and outputs submitted to covered models are retained for 30 days to support safety work, including controlled review.

Anthropic’s documentation says the 30-day requirement applies to covered models, including Mythos-class models, and that those models are not available under ZDR. It also says retained data is not used for model training without the customer’s express permission.

The operational difference is therefore substantial:

• OpenAI Private Safety Processing: automated analysis across related interactions; OpenAI receives a limited safety signal rather than the underlying content, according to the preview description.
• Anthropic covered-model policy: prompts and outputs are retained for 30 days so they can support safety work and controlled review.

Neither model eliminates the need for customer governance. Buyers still need to verify the exact eligibility rules, deployment architecture, access controls, retention terms, regional requirements, appeal process, and contractual commitments before using either approach for sensitive workloads.

Why the distinction matters to regulated enterprises

Organizations in finance, healthcare, and law often handle information that is subject to contractual confidentiality, privacy controls, professional duties, or sector-specific requirements. A provider’s ability to retain and potentially review prompts can therefore affect a customer’s data-minimization analysis, internal approvals, audit design, and vendor-risk assessment.

That does not mean a 30-day retention policy is automatically prohibited, nor that ZDR alone makes a deployment compliant. It means the two designs produce different questions for security and legal teams. Anthropic’s covered-model terms require organizations to account for provider retention and review, while OpenAI is positioning ZDR and Private Safety Processing around limiting provider access to the content itself.

For an enterprise buyer, the key questions are practical:

• Is the model and deployment eligible for ZDR?
• Where is content processed and, if stored, who controls the encryption keys?
• What exact fields appear in a safety alert?
• Can a customer audit or challenge a flag without disclosing the full conversation?
• What happens when a provider suspects serious abuse?
• Are the provider’s retention and review terms consistent with the organization’s contractual and regulatory obligations?

The broader product implication

Private Safety Processing turns privacy into part of the AI safety product itself. The challenge is no longer only whether a model can block an unsafe request; it is whether a provider can detect coordinated misuse across longer workflows without requiring access to every customer conversation.

OpenAI’s preview offers one answer: keep the underlying content under customer control or protected by customer-held keys, use automated systems to identify cross-interaction patterns, and send the provider a narrow risk classification.

Anthropic’s covered-model policy offers another: retain the relevant prompts and outputs for a limited period so safety teams can investigate them, with controlled review and a stated limit on model-training use.

The choice between these models will depend on the customer’s risk tolerance, the sensitivity of its workloads, and how much investigative visibility it believes a frontier-model provider needs. OpenAI’s promised technical white paper and broader rollout should provide the detail needed to assess whether the privacy claims hold up in real deployments.