Can OpenAI Scan For Misuse Without Keeping Your Prompts?

August 20, 2026

OpenAI says Private Safety Processing can spot cross-request misuse without exposing enterprise prompts. Here is what is confirmed—and still unproven.

OpenAI says it is testing a system that can look for dangerous patterns across multiple enterprise or API interactions without giving OpenAI the underlying prompts and responses. Axios reports that the preview, called Private Safety Processing, is intended to preserve Zero Data Retention access to frontier models. That is a consequential claim—not yet a completed public proof.

The preview does not apply to consumer ChatGPT Free, Plus, Go, or Pro accounts. OpenAI has not yet published the promised technical white paper, independent evaluation, supported-model list, or full definition of the safety signal it would receive. For now, buyers should treat Private Safety Processing as a reported architecture under early testing, not as a universal privacy guarantee.

What Is Confirmed

Axios reported on August 19, 2026 that OpenAI is testing Private Safety Processing with early enterprise and API customers. According to the report:

• customer data can remain on customer-controlled infrastructure or be stored by OpenAI with encryption keys controlled by the customer;
• the system evaluates activity across related interactions for possible misuse;
• OpenAI receives a narrowly defined safety signal rather than the underlying prompts or responses; and
• OpenAI plans a broader rollout and a technical white paper in September.

The report quotes OpenAI's Head of Product Policy explaining why a single request may be insufficient for safety review. Individually ordinary questions can become more concerning when their sequence suggests a coordinated cyberattack or another harmful campaign.

OpenAI's current API data-controls documentation separately confirms how its existing Zero Data Retention, or ZDR, program works. ZDR is available only to approved organizations, only on eligible endpoints and capabilities, and subject to documented limitations. It excludes customer content from abuse-monitoring logs and forces store=false for Responses and Chat Completions.

The same documentation makes an important distinction: abuse-monitoring retention and application-state retention are different storage paths. Some endpoints and capabilities are not ZDR eligible. Files, conversations, threads, vector stores, batches, fine-tuning jobs, and certain other objects can create application state under their own rules. Background mode and the video API also have storage requirements that make them incompatible with ordinary ZDR treatment.

OpenAI's documentation now also describes Eyes Off and Safety Retention. It says OpenAI can make models ineligible for ZDR or Modified Abuse Monitoring for specific customers after written notice when severe-risk investigation or prevention reasonably requires it. That existing policy matters because a future Private Safety Processing rollout would need to fit into—or explicitly change—these documented exceptions.

Anthropic has chosen a different published approach for its highest-capability models. Its covered-model retention documentation requires prompts and outputs to be retained for 30 days when organizations use Mythos-class models, including through Anthropic and supported third-party cloud platforms. Anthropic says attacks spanning many requests motivate the requirement.

Anthropic says personnel cannot read retained conversations by default. A small approved group can access content through a controlled review path after automated flagging, each access is recorded, and data is normally deleted after 30 days. Flagged records and legally required records can be kept longer. Its Fable 5 and Mythos 5 announcement also says the retained material is for safety work, not training new Claude models or unrelated purposes.

What Is Still Unclear

OpenAI has not yet published enough technical detail to independently determine whether Private Safety Processing delivers every property readers may infer from its name.

The unresolved questions include:

• Which models, API endpoints, tools, file types, and enterprise surfaces will support it?
• Does cross-request analysis happen entirely inside customer-controlled infrastructure, inside an attested confidential environment, or through multiple deployment options?
• What data is transformed into the safety signal?
• Can the signal reveal sensitive intent, entities, vulnerabilities, project names, or behavioral patterns even without verbatim text?
• How long are local working state, encrypted state, derived features, safety signals, and audit records retained?
• Who can inspect a flagged signal, and what happens after one is received?
• Can a customer verify the deployed code, model, policy, and encryption-key path?
• How does the system behave when it fails closed, fails open, loses state, or produces a false positive?
• Will OpenAI's published ZDR endpoint limitations and Safety Retention exceptions change before rollout?
• What independent testing will support the September white paper?

No reviewed source establishes that the system is generally available today. No public document supplies measured detection rates, false-positive rates, cryptographic proofs, red-team results, or an external audit. Axios identifies early testing and a planned rollout; that is stronger than an anonymous rumor but weaker than a released specification and production evidence.

Is Private Safety Processing The Same As Zero Data Retention?

Not exactly. Private Safety Processing is the reported safety-analysis mechanism. Zero Data Retention is a data-handling control with eligibility, endpoint, and contract boundaries.

A buyer should separate at least five layers:

1. Prompt and response content: whether the original customer content enters provider abuse-monitoring logs.
2. Application state: whether an endpoint stores files, conversations, responses, vectors, batches, or other objects to provide the requested feature.
3. Cross-request working state: what the safety mechanism temporarily needs to compare multiple interactions.
4. Derived safety signals: what leaves the protected processing boundary when behavior is flagged.
5. Operational records: configuration, access, billing, security, and audit metadata needed to run the service.

A system can exclude prompts from conventional provider logs while still retaining application state for a feature. It can avoid disclosing verbatim content while still emitting a derived signal. It can delete working state while keeping an audit record that a safety event occurred.

Those outcomes may be reasonable and privacy-preserving, but they are not interchangeable. “No prompt text in the provider's abuse log” is narrower than “nothing was stored anywhere,” and “provider employees cannot read the content” is narrower than “the provider learns nothing about the activity.”

How Could Cross-Request Safety Work Without Exposing Prompts?

The reported design describes a familiar privacy architecture at a high level: process sensitive material inside a boundary, release only a constrained result, and keep decryption authority with the customer where possible.

One possible deployment could keep the multi-request state on infrastructure controlled by the customer. Another could encrypt the state so that the customer controls the keys. A local or protected component could then classify sequences and send OpenAI only a limited event indicating a category of suspected misuse.

That design can reduce exposure, but the details determine the real guarantee. A safety signal that says “possible coordinated cyberattack” reveals less than a transcript. A signal containing target names, exploit classes, user identifiers, extracted snippets, or detailed behavioral features could reveal much more.

The update path matters too. If OpenAI can remotely change the classifier, signal schema, or collection policy, customers need evidence about which version ran. If the system depends on customer-managed keys, buyers need to know which components can request decryption and under what policy. If processing occurs in a confidential-computing environment, attestation needs to cover the relevant code and configuration—not merely the hardware type.

The promised white paper may answer some of these questions. Until then, the phrase “narrowly defined safety signal” is a useful design goal, not a complete threat model.

Why Anthropic Chose 30-Day Retention Instead

Anthropic's public argument is operationally straightforward: some attacks appear only after many requests, so investigators need a temporary sequence of prompts and outputs to detect and understand them.

Its policy trades a stronger customer-retention boundary for more provider-visible evidence. The company attempts to reduce the resulting privacy risk through a 30-day default deletion period, restricted human review, access logging, customer-managed encryption options, and cloud-specific custody paths.

That does not make Anthropic's choice automatically unsafe, and it does not make OpenAI's preview automatically superior. The approaches optimize different trust assumptions:

• Anthropic retains richer evidence for a defined period and constrains access to it.
• OpenAI says it is testing a way to derive a limited safety result while preserving ZDR for the content.

The strongest architecture depends on the failure being considered. Richer retained data can help investigate sophisticated abuse, but it creates a larger confidentiality and legal-discovery surface. Minimal signals can reduce content exposure, but they may omit evidence, misclassify sequences, or make incident reconstruction harder.

A serious comparison should evaluate detection quality and privacy leakage together. A system that leaks almost nothing but misses coordinated attacks is incomplete. A system that catches more abuse by retaining every sensitive prompt may be unacceptable for some regulated or confidential workloads.

What The Preview Does Not Prove

Private Safety Processing does not establish that OpenAI never processes customer content. Inference and safety analysis still require active computation somewhere.

It does not establish that every OpenAI API feature becomes ZDR eligible. OpenAI's current endpoint table documents multiple features with application-state requirements or ZDR exclusions.

It does not change consumer ChatGPT retention settings. Axios explicitly reports that the preview is for eligible enterprise and API customers, not Free, Plus, Go, or Pro users.

It does not mean safety systems learn nothing. The reported design intentionally produces a safety signal. The unanswered question is how much that signal communicates and how it is retained and used.

It does not prove immunity from compromise, insider abuse, key misuse, malicious updates, inference from metadata, or compelled legal access. Those risks depend on architecture, contracts, deployment, jurisdiction, and operational controls.

Finally, it does not make “zero data retention” synonymous with “fully offline,” “anonymous,” or “no logs.” ZDR is a specific control over defined customer content and storage paths.

Use The SIGNAL Test Before Accepting The Claim

The SIGNAL test turns the preview into six questions an enterprise buyer can send to a provider.

S — Scope

List the exact models, endpoints, tools, modalities, cloud routes, and account types covered. Ask what becomes ineligible when files, background jobs, web search, connectors, video, fine-tuning, or persistent conversations are used.

I — Inputs

Identify every representation the safety system examines: prompt text, output text, file content, tool calls, network destinations, embeddings, classifier features, user identifiers, and timestamps. “Content” should not be left undefined.

G — Generated Signal

Request the safety-signal schema. Ask which fields leave the protected boundary, whether any snippets or entity names can appear, and how easily multiple signals can be linked back to one person or project.

N — Node And Key Custody

Determine where processing occurs and who can decrypt state. If customer-managed infrastructure or keys are offered, ask which service identities can use them, whether code and policy are attestable, and how updates are authorized.

A — Access And Action

Document who can view a signal, what automated action it can trigger, when a human can gain access to underlying content, how the customer is notified, and how an incorrect flag can be challenged.

L — Lifecycle

Set deletion times for raw content, temporary working state, derived features, safety signals, access logs, and incident records. Require evidence that deletion occurred and list legal or severe-risk exceptions separately.

The SIGNAL test is useful even if OpenAI's September paper validates the preview. Product names change; data representations, access paths, and retention lifecycles are what buyers actually need to govern.

What Should Existing OpenAI ZDR Customers Do Now?

Do not assume the preview has changed a production contract or organization setting. Check the controls that apply to the exact organization and project today.

1. Confirm that ZDR is approved and enabled for the intended API organization or project.
2. Compare every used endpoint and capability against OpenAI's current eligibility table.
3. Separate abuse-monitoring retention from application-state storage in the architecture diagram.
4. Ask the account team whether Private Safety Processing is available, experimental, required, or optional for the models you plan to use.
5. Request the signal schema, deployment location, key-custody model, retention schedule, audit evidence, and failure behavior.
6. Preserve a written snapshot of the contract, data-control settings, endpoint matrix, and model eligibility at launch.
7. Re-evaluate the design when OpenAI publishes the planned technical white paper or changes the relevant documentation.

If a workload cannot tolerate provider retention, configure the application to reject an ineligible model or endpoint rather than silently falling back. A policy that exists only in a procurement document is not enough if runtime routing can select a different path.

Where OpenVeil Fits—and Where It Does Not

OpenVeil serves a different audience and should not be described as an enterprise ZDR substitute. It is a hosted, privacy-focused AI workspace for adults who want chat, search, files, voice, images, video, and custom personas without maintaining local infrastructure.

For normal private chat sessions, OpenVeil keeps chat history in the user's browser and does not maintain a server-side chat-history record. OpenVeil does not use prompts, uploaded files, images, audio, selected local-history context, or outputs to train foundation models. Active requests still have to be processed by OpenVeil and necessary AI, search, upload, hosting, routing, security, billing, and infrastructure providers. Limited operational, billing, security, and abuse records can still exist.

That boundary is narrower than “nothing leaves the device.” OpenVeil is not fully offline, anonymous, zero-log, HIPAA compliant, or free of provider processing. It does not currently claim customer-managed infrastructure, customer-managed encryption keys, OpenAI enterprise ZDR, or Private Safety Processing.

Readers comparing these trust models may find these OpenVeil guides useful:

• Does No Chat History Mean An AI App Keeps No Logs?
• Does Turning Off AI Training Mean Your Chats Are Not Retained?
• Can Confidential Computing Keep An AI Provider From Reading Prompts?
• What To Check Before Trusting Any AI Privacy Claim

If browser-local normal chat history and a hosted workspace fit your needs, you can review OpenVeil's privacy policy and try the bounded preview. If contractual ZDR, customer-controlled infrastructure, or formal enterprise processing terms are mandatory, evaluate a product that explicitly documents and contracts for those requirements.

Frequently Asked Questions

Is OpenAI Private Safety Processing available now?

Axios reports that OpenAI is testing it with early customers and plans broader availability plus a technical white paper in September. OpenAI has not yet published a general-availability page, supported-model matrix, or complete technical specification.

Does it apply to ChatGPT Plus or Pro?

No. The report says the preview is designed for eligible enterprise and API customers. It does not change the settings for ChatGPT Free, Plus, Go, or Pro users.

Does OpenAI ZDR mean no data is stored anywhere?

No. OpenAI defines ZDR around customer content in abuse-monitoring logs and eligible endpoint behavior. Its documentation separately identifies application state, ineligible features, safety exceptions, and operational records. Buyers must check the exact endpoint and configuration.

Does Anthropic use its 30-day retained data to train Claude?

Anthropic says prompts and outputs retained under the covered-model policy are used for safety work, not to train new Claude models or for unrelated purposes. It documents restricted review and exceptions for flagged or legally required records.

Is a derived safety signal still data?

Yes. Even without verbatim prompts, a signal can communicate that a user, organization, session, or sequence matched a risk category. Its fields, linkability, retention, access, and downstream actions are part of the privacy analysis.

Which approach is more private?

The previewed OpenAI approach appears designed to reduce provider access to prompt and response content. Anthropic's published approach retains richer content for 30 days under access controls. A defensible comparison still requires OpenAI's technical details and evidence about both privacy leakage and detection performance.

Bottom Line

OpenAI's reported Private Safety Processing preview asks an important question: can a frontier-model provider detect dangerous multi-request behavior without keeping the customer's prompts and responses? The proposed answer is a protected cross-request analysis that sends OpenAI only a limited safety signal while preserving ZDR for eligible enterprise and API customers.

That would be meaningful if the implementation matches the claim. Today, the public evidence is an attributed preview, current OpenAI ZDR documentation, and a promised September white paper—not a complete technical proof. Buyers should compare exact content paths, application state, derived signals, key custody, human access, exceptions, and deletion evidence before treating “private safety” or “zero retention” as a blanket guarantee.