On this page
OpenAI Developers (@OpenAIDevs) posted about Private Safety Processing (PSP) at 00:54:19 Asia/Shanghai on November 6, 2026 (16:54:19 UTC on November 5; https://x.com/OpenAIDevs/status/2118386439675420743). The post says PSP lets OpenAI review related API requests for safety without retaining customer prompts or responses. Records stay in the customer environment, where an automated safety agent reviews them without OpenAI personnel being able to access that content.
OpenAI developer documentation names the same capability Zero Data Retention with Private Safety Processing (ZDR with PSP): offline, automated safety review without OpenAI retaining customer prompts or responses (https://developers.openai.com/api/docs/guides/private-safety-processing). The same day's GPT-6 Cyber blog lists PSP among companion safeguards for that release. DigIntoAI has not applied for Zero Data Retention and has not connected customer-controlled storage; we haven't tested Private Safety Processing. Facts below follow those materials as self-reported.
Related reading: GPT-6 Cyber blog, OpenAI Daybreak Red Brings GPT-5.6 Cyber to AWS GovCloud US-East, OpenAI Will Require Approval for Routers and AI Gateways Starting Nov 20, and Cat Wu Joins OpenAI to Lead Core Products Product Management.
What Private Safety Processing does
The developer documentation builds ZDR with PSP around three principles. Customers control their content in customer-controlled storage, including permissions and customer-managed Enterprise Key Management (EKM) authorization. No human review: safety review must not become a new path for OpenAI personnel to read protected customer content. Encrypted content is decrypted in an approved, hardware-attested Safety Review Runtime that disables human access. Only bounded safety signals and operational metadata leave the PSP protected review in plaintext. Content retention for safety only: those records serve approved safety purposes and cannot be used to train models or be shared with other groups inside OpenAI or its partners.
API Request and Retention protects eligible API content and writes it to customer-controlled storage. The Asynchronous Safety Pipeline retrieves records only for approved automated review and releases bounded safety decisions. An interaction—the prompt plus the model response—is selected by a safety classifier referral or an approved sampling policy. A referral does not establish a policy violation. OpenAI keeps an index with operational metadata and a storage reference, not a copy of the content. Encryption and storage run asynchronously, without blocking inference. The Safety Review Runtime is described as the only OpenAI workload designed to decrypt customer content; detailed results are encrypted again before they leave that runtime.
The boundary: personnel cannot read prompts; automated review still runs
The OpenAI Developers post says personnel cannot access the content. The developer documentation is more precise: personnel cannot read protected prompts and responses, but automated review still runs. What leaves in plaintext is only bounded safety signals and operational metadata. OpenAI still keeps an operational index and storage reference. That is not the same as saying OpenAI has no safety-side visibility at all.
Stored records can also be doubly encrypted: an inner OpenAI-managed HPKE layer limited to the authorized Safety Review Runtime, plus an outer customer-managed EKM layer. When EKM is enabled, the inner OpenAI key is not enough—customer key authorization is required as well. Revoking that authorization can block further decryption, but does not delete the records or undo completed processing. The documentation recommends enabling EKM.
Four clouds, a 30-day TTL, and per-project enablement
Supported customer storage is an AWS S3 bucket, an Azure Blob container, a Google Cloud Storage bucket, or an Oracle Cloud Infrastructure (OCI) Object Storage bucket. ZDR with PSP writes encrypted records to regional cloud storage with a TTL of 30 days. Customers are also expected to set lifecycle rules that keep records for at least 30 days and do not delete them sooner.
ZDR with PSP is enabled per project. Once it is on, the policy applies to all API traffic in that project, including requests to models that do not themselves require PSP. To use ZDR without PSP for eligible models, those requests need a separate project configured for ZDR without PSP. Both setups are documented as two different configurations.
Organizations already approved for Zero Data Retention can configure ZDR with PSP in the API console; others need to meet eligibility and approval requirements. The console path is Organization settings > Data controls > Data retention, then Connect storage. Customers are also expected to respond to notices about safety concerns.
How the GPT-6 Cyber blog frames PSP
The GPT-6 Cyber blog (https://openai.com/index/introducing-gpt-6-cyber/) lists Private Safety Processing (PSP) among safeguards paired with that release. It says OpenAI uses automated checks to review related interactions for misuse. Standard retention remains the default. API customers using Zero Data Retention generally must use PSP, which reviews encrypted records retained in customer storage for 30 days without exposing prompts and responses to OpenAI personnel.
That generally must line is from the GPT-6 Cyber blog, not a standalone sentence in the PSP documentation, and does not mean every ZDR customer on every model can use only PSP. The documentation still describes ZDR without PSP for eligible models, via a separate project. Both statements appear in the public materials.
PSP was not invented with this OpenAI Developers post. OpenAI previewed it on August 19, 2026 in *Offering Zero Data Retention for frontier models* (https://openai.com/index/offering-zero-data-retention-for-frontier-models/), and an update on September 22, 2026 said PSP was rolling out to API customers, with access expanding in phases—not a first launch dated today.
The subject is ZDR with PSP, where records stay in customer-controlled cloud storage. That differs from Private Retention with Private Safety Processing (previously described as Eyes Off), which keeps content in OpenAI-managed encrypted abuse-monitoring logs.
Quick facts
- Who. OpenAI Developers (@OpenAIDevs), the developer documentation, and the GPT-6 Cyber blog.
- When. 00:54:19 Asia/Shanghai, November 6, 2026 (16:54:19 UTC on November 5). Previewed August 19, 2026; phased rollout September 22, 2026.
- What. PSP / ZDR with PSP: automated offline review of related API requests, without OpenAI retaining prompts or responses.
- Where. Customer-controlled AWS S3, Azure Blob, Google Cloud Storage, or OCI Object Storage.
- Who reviews. An automated safety agent in a hardware-attested Safety Review Runtime; personnel cannot read protected prompts and responses.
- Plaintext leaving. Bounded safety signals and operational metadata—not an absence of all safety-side signals.
- TTL. 30 days.
- Enablement. Per project, for all API traffic there. ZDR without PSP remains documented via a separate project.
- Default (Cyber blog). Standard retention remains the default; ZDR API customers generally must use PSP.
- Hands-on. We haven't tested PSP; DigIntoAI has not enabled ZDR or connected customer storage.
In short
At 00:54 Asia/Shanghai on November 6, 2026, OpenAI Developers described Private Safety Processing: related API requests can be reviewed for safety without OpenAI retaining customer prompts or responses. Records stay in the customer environment; an automated safety agent reviews them so personnel cannot read that content. Documentation calls this ZDR with PSP, writes encrypted records to AWS S3, Azure Blob, Google Cloud Storage, or OCI Object Storage with a 30-day TTL, and says only bounded safety signals and operational metadata leave in plaintext. Enablement is per project; ZDR without PSP still exists via a separate project. The GPT-6 Cyber blog keeps standard retention as the default and says ZDR API customers generally must use PSP. We haven't tested it.