OpenAI Tests Cross-Session Safety Checks Without Prompt Access

OpenAI is testing Private Safety Processing, a system designed to spot patterns of API misuse across related interactions while keeping eligible customers’ prompts and responses outside the company’s view. The effort targets a difficult trade-off: abuse detection often needs context that zero-data-retention customers do not want a model provider to keep.

The company plans to begin rolling out the system in September 2026 after testing with early customers, and plans to publish a technical white paper that month. Glean, Databricks, Abridge, and Microsoft are helping shape the approach.

OpenAI already says business data from its API and enterprise products is excluded from model training by default unless a customer opts in. Zero data retention goes further: on eligible services, it limits retention for abuse monitoring and application state. Private Safety Processing is meant to add cross-session safety context without giving up that additional control.

Private Safety Processing is intended to recognize activity that only becomes visible over multiple interactions. OpenAI identifies repeated attempts to probe safeguards, coordination across accounts, and agents continuing to act after being told to stop as examples of the patterns it wants to catch.

That distinction is aimed at work that runs longer than a single exchange. OpenAI says risky behavior can be distributed across prompts, accounts, and sessions; businesses handling medical records, financial information, proprietary code, or internal plans may be unable to place that material in a provider-run review queue. The proposal tries to keep the evidence behind an alert under customer control.

For eligible zero-data-retention deployments, OpenAI says prompts and responses will remain on infrastructure controlled by the customer. The company is also developing an alternative in which content sits on OpenAI infrastructure but is encrypted with keys held by the customer; OpenAI personnel would not have copies of those keys.

The design separates detection from investigation. Customers would retain the records needed to examine an alert. They could choose to share relevant material when contesting an enforcement decision, explaining legitimate activity, or helping investigate verified abuse.

OpenAI is explicitly pitching the approach against deployments that require customers to permit content retention for safety monitoring. Its commercial premise is that a stronger model may not clear an organization’s security review if adoption means surrendering control of sensitive information.

Zero retention has defined edges

The proposal does not turn zero data retention into a universal setting across OpenAI’s products. The control is approval-based, and standard zero-data-retention configuration does not support every feature. Background processing and Code Interpreter are specifically identified as incompatible with that configuration.

The boundary OpenAI still draws

• Potential child sexual abuse material is an exception: images flagged for that risk may be retained for human review and legally required reporting, including in zero-data-retention deployments.
• OpenAI says this retention exception applies even when a deployment otherwise uses zero data retention.

Today’s standard abuse-monitoring logs can contain prompts and responses and are generally retained for up to 30 days. Existing safeguards compatible with zero data retention evaluate interactions individually, leaving a gap for misuse that unfolds across accounts, sessions, or longer agent tasks.

Private Safety Processing is OpenAI’s attempt to close that gap without requiring customers to hand over the text and outputs behind an alert. The central unresolved question is how much information the safety signal itself conveys, how isolated the processing is, and how the system handles false positives. OpenAI’s planned white paper is where those implementation details are expected to appear.