OpenAI’s ZDR safety preview makes the request path the real control

OpenAI has previewed Private Safety Processing, a design intended to detect risky patterns across related API interactions while keeping the underlying prompts and responses unavailable to OpenAI personnel. The company says the approach will remain compatible with Zero Data Retention (ZDR), which eligible API customers use when sensitive content cannot sit in a provider’s abuse-monitoring logs.

That is a meaningful attempt to reconcile privacy with safety monitoring, but it does not turn ZDR into a blanket property of an application. For business and software teams, the useful decision is narrower: verify whether the exact endpoint, features, storage, third parties, and exceptions in a production request preserve the boundary you approved. This article explains the announced mechanism, what remains unproven, and how to test that request path.

What did OpenAI actually preview?

In its August 19 announcement, OpenAI reaffirmed that ZDR gives eligible API customers a specific promise: prompts and model responses are not retained by OpenAI after a request is processed, and that content is not available to OpenAI personnel for review. It also says enterprise customer data is not used to train its models unless the customer explicitly opts in.

The safety problem changes as models handle longer tasks. OpenAI says its existing ZDR-compatible systems evaluate interactions individually, while some serious risks may only become visible as a pattern across related interactions. Private Safety Processing is the proposed bridge: automated systems would evaluate those related interactions and return a narrowly defined signal about the type of activity involved, without giving OpenAI personnel the underlying content.

OpenAI describes two possible storage arrangements. In a ZDR deployment, customer content remains on infrastructure the customer controls. The company is also developing an OpenAI-hosted option where content would be encrypted with keys controlled by the customer; OpenAI says its personnel would not hold copies of those keys. If a safety signal leads to an enforcement question, the customer investigates using information in its own systems and may choose to share relevant evidence.

Those are vendor-described design properties, not an independently audited architecture. Private Safety Processing is being tested with early customers. OpenAI says it plans to begin rollout and publish a technical white paper in September, so availability, cryptographic details, signal scope, and operating procedures should be treated as preview information until those materials arrive.

Why is “ZDR enabled” not enough?

OpenAI’s API data documentation separates two kinds of stored data: abuse-monitoring logs and application state. By default, abuse-monitoring logs may contain prompts, responses, and derived metadata and can be retained for up to 30 days, subject to legal and safety exceptions. ZDR and Modified Abuse Monitoring require prior approval, eligibility, and additional customer requirements.

ZDR changes behavior for supported request paths. For the Responses and Chat Completions APIs, the documentation says store is always treated as false when ZDR is enabled, even if a request tries to set it to true. But the same documentation warns that ZDR-ineligible endpoints or capabilities may still store application state. A setting at the organization or project level cannot make an incompatible feature compatible.

Feature boundaries matter too. Data sent to a remote MCP server is governed by that third party’s retention policy. Hosted containers can hold temporary application state while they are active. Images and files receive separate handling, including retention of images flagged as potential child sexual abuse material for legally required manual review and reporting. These are not footnotes to hide; they are reasons to approve a concrete data path rather than a product name.

What should the request-path review contain?

Begin with the endpoint and model actually called in production. Record the organization and project where the retention control is configured, then confirm the intended endpoint and every enabled capability are currently eligible. Capture the effective setting from the platform rather than relying only on procurement language or an old architecture document.

Next, follow the content beyond the model call. Identify files, images, prompt caches, background work, hosted containers, web access, MCP servers, observability exports, application logs, queues, and databases that can receive the input or output. For each location, name the retention period, deletion method, encryption owner, and person or team that can access the content. The boundary is only as strong as the least examined branch.

Then preserve the customer-side evidence needed for an investigation. OpenAI’s preview assumes that customers can examine activity in systems they control without the provider opening the underlying content. That makes local records part of the safety design. Keep enough identifiers, timestamps, policy decisions, tool activity, and outcome evidence to reconstruct a concern, while avoiding a second uncontrolled copy of every sensitive prompt.

Finally, record the exceptions. Include legal retention, content classifiers, features that are not ZDR eligible, and any written notice that changes model eligibility for the customer. An exception register is more useful than the sentence “we use ZDR” because it shows operators where the normal promise stops.

How can a team verify the control before launch?

Use synthetic sensitive data first. Send a uniquely identifiable test value through the same endpoint, model, tools, files, background modes, and integrations planned for production. Confirm that store behaves as documented, that no retrievable provider-side object appears where none should exist, and that your own logs do not copy the test value into an unapproved destination.

Run the deletion path for every component that does create state. Verify the result from a second interface or query rather than accepting a successful command as proof of deletion. Repeat the test for each materially different path—text-only and file input, for example—because one passing request cannot establish the behavior of another endpoint or feature.

Test the investigation path separately. Give an operator only the customer-side records the production design will retain and ask them to reconstruct the test request, its tool activity, policy outcome, and final disposition. If they cannot explain what happened without exposing every prompt to a broad internal audience, the evidence design needs work before Private Safety Processing or any other safety signal can help.

BaristaLabs recommendation: make this request-path test a release gate whenever the model, endpoint, tool set, storage mode, key arrangement, or third-party integration changes. OpenAI’s public sources describe platform behavior and a forthcoming safety design; they do not certify any customer implementation.

What changes when the white paper arrives?

The September white paper should let teams replace several open questions with technical evidence. Look for the cryptographic boundary around customer-controlled keys, how related interactions are associated, exactly what a “narrowly defined signal” contains, which people and systems can receive it, and how false positives, appeals, and verified abuse are handled without silently expanding content access.

Also compare the rollout documentation with the request paths already approved. If eligibility differs by model, endpoint, content type, region, or storage option, update the test matrix rather than assuming the preview applies everywhere. A policy should follow deployed behavior, not the broadest reading of an announcement.

The privacy control lives in the whole path

Private Safety Processing is notable because OpenAI is proposing cross-interaction safeguards without making provider access to retained content the default answer. If the design works as described, organizations handling confidential financial, health, legal, business, code, or research data could gain a stronger safety signal without surrendering the content boundary they negotiated.

The operational work remains concrete: approve one endpoint and feature set, trace every branch, keep a proportionate customer-side investigation record, and test the path again when it changes. Teams preparing a sensitive workflow can use BaristaLabs’ data security approach or review one exact request path before confidential data enters production.

Sources

• OpenAI, “Offering Zero Data Retention for frontier models”, published August 19, 2026.
• OpenAI API documentation, “Your data”, accessed August 21, 2026.
• OpenAI, news RSS feed, item published August 19, 2026.