OpenAI is previewing Private Safety Processing, a system intended to spot misuse patterns across related API interactions while preserving Zero Data Retention, or ZDR, for eligible customers. The announcement addresses a growing enterprise problem: advanced agents need context over time, but sensitive workloads often cannot allow a provider to retain prompts and outputs.
Under ZDR, OpenAI says eligible API customers’ prompts and model responses are not retained after processing, and are not available to OpenAI personnel for review. Private Safety Processing is designed to let automated systems detect certain patterns across interactions and return a narrowly defined risk signal without exposing the underlying content to staff. It is being tested with early customers, with a rollout and technical white paper planned for September.
Why this matters for enterprise agents
A one-shot assistant can often be evaluated request by request. A multi-step agent that searches internal systems, calls tools, and runs for longer periods creates a different monitoring challenge. Risk may only become visible through repeated probes, coordinated activity, or behavior that persists after a user has changed instructions.
OpenAI’s proposal is an attempt to avoid a forced choice between richer safety monitoring and strict data handling. For teams working with financial records, health information, proprietary code, or internal strategy, that tradeoff can determine whether a frontier-model deployment is viable at all.
ZDR is not a blanket setting for every workflow
Enterprise teams should not read ZDR as a guarantee that every API feature is retention-free. OpenAI’s API documentation says eligibility varies by endpoint and capability. For example, Chat Completions and eligible Responses API usage can support ZDR, but persistent features such as Conversations, Assistants, Threads, Vector Stores, and Files can retain application state. Background mode, Code Interpreter, and extended prompt caching also have constraints that can make a workflow incompatible with ZDR.
That makes architecture the real decision. If a team needs durable provider-hosted memory, uploaded files, or asynchronous execution, it should map each component’s storage behavior rather than assume a project-level privacy control covers the whole stack.
What Private Safety Processing appears to change
In a ZDR deployment, OpenAI says customer content can remain in infrastructure controlled by the customer. It is also developing an option for OpenAI-hosted storage encrypted with keys controlled by the customer. Automated systems would analyze for potential misuse and send OpenAI a limited signal about the risk type, rather than the original prompts or responses.
That is a meaningful design goal, but it remains a preview. Before committing a sensitive production workflow, buyers should wait for the technical paper and ask how signals are generated, what false-positive handling looks like, what customer-side evidence is available for appeals, and which tools remain ZDR-compatible.
A practical decision rule
Start with the data, not the model. Classify the information your agent will touch, identify where state must persist, and make retention requirements explicit for every tool and endpoint. Then decide whether customer-managed storage, a ZDR-compatible stateless pattern, or a different operating model best fits the risk.
The broader signal is clear: privacy controls are becoming a product architecture issue for agentic AI, not a procurement checkbox. Teams that design for data boundaries early will have more deployment options as safety requirements become more sophisticated.