OpenAI is testing a new way to watch for dangerous patterns in sensitive enterprise AI use without giving its own personnel access to the underlying conversations. The preview, announced August 19, extends the company’s Zero Data Retention program toward longer, multi-step agent activity, where risk may emerge across a sequence rather than in one prompt.
The idea is called Private Safety Processing. OpenAI says eligible customers can keep content on infrastructure they control. A second planned option would store content on OpenAI infrastructure while encrypting it with customer-controlled keys that OpenAI personnel do not possess. Automated systems would process related interactions and return a narrow safety signal when they detect a possible violation, without exposing the prompts or responses to human reviewers at OpenAI.
That is a meaningful architectural claim, but it is still a preview rather than a completed technical specification. The company says early customers are testing it and that a white paper and rollout details are due in September. Until then, the important story is not simply that privacy and safety can coexist. It is that the standard for proving that coexistence is becoming much higher.
Why single-request screening is no longer enough
Existing safeguards that work with Zero Data Retention inspect each interaction separately. That can catch an obviously prohibited request, but an agent may divide a larger operation into harmless-looking steps. OpenAI gives examples including repeated attempts to probe safeguards, activity coordinated across accounts, and an agent that continues acting after a user tells it to stop.
Private Safety Processing is intended to join those fragments without turning them into a human-readable surveillance record for the model provider. When the automated system identifies a risk, OpenAI says it receives the type of activity involved rather than the protected customer content. Customers retain their own records and can voluntarily provide evidence if they need to appeal or explain legitimate work.
The separation matters because enterprise AI increasingly operates inside repositories, research environments, financial systems, and other places where the prompt may contain the very information an organization is obligated to protect. A safety system that requires routine provider access to that content can solve one risk by creating another.
TENS analysis: the proof now matters as much as the promise
The useful comparison is not between safety monitoring and no monitoring. It is between architectures that make different guarantees independently testable. Apple’s Private Cloud Compute documentation describes stateless processing, hardware-backed attestation, publicly logged software measurements, and research access to production software images. Google’s Private AI Compute describes a sealed cloud boundary using encryption and remote attestation so devices can verify the environment handling sensitive requests.
OpenAI’s announcement identifies customer-controlled infrastructure, customer-controlled encryption keys, automated cross-interaction analysis, and limited alerts. It does not yet explain whether customers can attest the exact code performing that analysis, how related interactions are grouped, how long encrypted state exists, or how false positives are measured. Those features may appear in the promised white paper; their absence from the preview is a disclosure gap, not proof that the controls are absent.
This comparison changes the buying question. “Does the provider retain our prompts?” is no longer sufficient. Customers also need to ask where temporary state exists, who can authorize its decryption, what software can inspect it, whether the running environment can be independently verified, and what evidence survives when an alert is generated.
A signal can protect privacy and still require accountability
A narrow safety signal reduces exposure, but compression also removes context. If the provider sees only a category of suspected misuse, enforcement may depend heavily on the quality of an automated classifier. The customer may then hold the only evidence capable of showing whether the activity was harmful, mistaken, or part of authorized security testing.
That makes the appeal path part of the security design rather than an administrative afterthought. A credible system should let customers reconstruct which policy boundary was triggered without forcing them to surrender an entire confidential session. It should also report enough aggregate performance data to show how often alerts are wrong and whether risk detection degrades when activity spans long agent runs.
The strongest version of Private Safety Processing would therefore provide two kinds of assurance: technical evidence that protected content remains inaccessible to provider personnel, and operational evidence that the limited signals are accurate enough to justify action. Encryption can constrain who sees the data. It cannot, by itself, validate the judgment produced from that data.
What to watch in September
OpenAI’s technical paper will need to clarify the threat model, the role of trusted hardware or attestation, state-retention limits, key revocation, customer audit logs, alert accuracy, and the boundary between automated detection and human enforcement. It should also explain whether customers can verify that the deployed safety processor matches the reviewed design.
The preview points toward a future in which advanced agents can be monitored across time without making confidential content broadly visible. That is a worthwhile direction. The decisive test will be whether the system turns a privacy promise into an enforceable, inspectable property rather than asking customers to accept another opaque layer of AI.
Featured image: A visitor beside the Summit supercomputer at Oak Ridge National Laboratory. Photo: Lynn Freeny, U.S. Department of Energy, via Wikimedia Commons. Public domain, United States government work. Center-cropped from 6,000 × 4,000 pixels to 6,000 × 3,375 pixels at 16:9 and resized to 2,400 × 1,350 pixels; no generative or substantive alteration.
