OpenAI has outlined a new approach to safety monitoring for its frontier-model APIs that is designed to preserve its Zero Data Retention (ZDR) commitment. The company calls the preview Private Safety Processing. It is meant to help automated safeguards recognise risk patterns across a series of related interactions without giving OpenAI personnel access to the underlying customer prompts or responses.

The announcement matters because sophisticated misuse and agent failures may only become apparent over time. A single request can look harmless in isolation, while repeated probing, coordinated activity or an agent continuing beyond a user's instruction can reveal a different risk profile. OpenAI says its existing ZDR-compatible systems assess each interaction individually; this proposal would add cross-interaction signals while retaining the privacy posture that eligible API customers rely on.

Keeping the ZDR promise as models take on longer tasks

Under ZDR, OpenAI says it does not keep an eligible customer's prompts or model responses after a request has been processed. Customer content is not available for employee review, and enterprise data is not used for model training unless the customer chooses to opt in. That commitment can be especially important for organisations handling financial records, health information, confidential plans or proprietary research.

OpenAI argues that the pressure point is changing as capable models are used for longer-running and more autonomous work. The company says some serious safety concerns become visible only across multiple interactions, rather than inside one request. It also cites threats such as users testing safety controls repeatedly, co-ordinating across accounts or attempting to disguise harmful work as routine research.

For API teams, the practical tension is familiar: stronger monitoring can imply retaining more information, while strict retention limits can constrain how much context a provider can use. OpenAI's preview is an attempt to avoid treating those goals as mutually exclusive. It is not a general licence for staff to inspect ZDR traffic; the company describes it as an automated process that returns only narrow safety signals.

What Private Safety Processing is designed to do

OpenAI says the system builds on the automated protections already used for ZDR and other deployments. Instead of evaluating each exchange alone, it is intended to analyse patterns across related interactions. The company has not yet published the detailed technical design, thresholds, retention mechanics or independent evaluation results, so customers should treat the announcement as a product preview rather than a fully specified control.

In a ZDR deployment, OpenAI says customer content remains on infrastructure controlled by the customer. It is also developing an option where the information resides on OpenAI infrastructure but is encrypted with keys controlled by the customer. In both arrangements, the company says automated systems could detect possible misuse and issue limited signals without exposing the prompts and outputs themselves to OpenAI staff.

Where an alert is raised, OpenAI says it would receive a narrowly defined indication of the activity type, which could inform an enforcement decision. The customer would retain the underlying material in its own environment and could investigate the alert there. If it wanted to appeal, explain legitimate activity or assist a verified-abuse investigation, it could choose what relevant information to share.

Privacy claims sit alongside important exceptions

The proposal does not remove every form of content handling. OpenAI notes that it is legally required to report apparent child sexual abuse material and says images flagged for possible CSAM will continue to be retained for manual review and reporting, including in ZDR deployments. That existing exception is important for customers assessing what the ZDR promise means in practice.

OpenAI also frames the feature as a response to enterprise predictability. Its announcement includes supportive comments from customers including Glean, and says organisations across industries have helped shape the approach. Those endorsements are not a substitute for contractual terms or a security review, but they show that the company is targeting organisations whose adoption decisions depend on control of sensitive data.

For Australian organisations, the relevant questions will be operational as much as technical. Security and legal teams will want clarity on the exact service scope, regional availability, encryption-key management, incident response, audit evidence and how safety signals interact with their own logging and escalation processes. Teams should also distinguish between the preview's stated design and any commitments that ultimately appear in a data-processing agreement or product documentation.

A September rollout is planned, with details still to come

OpenAI says Private Safety Processing is being tested with early customers and that it plans to begin rolling it out in September, alongside a technical white paper. The company has not announced a full availability timetable, pricing change or eligibility list. It has also not said whether every frontier model, API tier or geographic deployment will receive the same capabilities at launch.

The direction is nevertheless significant. AI providers are being asked to make services more private while also demonstrating that they can manage evolving safety risks. OpenAI's preview suggests a model in which providers receive signals about potentially risky activity, while customers keep possession of the content that generated those signals. Whether the approach delivers on that separation will depend on the technical paper and the controls available when the service moves beyond early testing.