Zero data retention with private safety processing does not mean the prompt is gone. @OpenAI posted on October 30 at 15:12 UTC that privacy should advance as fast as intelligence, and that Private Intelligence gives businesses stronger controls while they use the most capable models. When I read it, the post had 398,544 impressions and 2,984 likes. The page offers zero data retention and a private inference preview for eligible workflows. The October 26 whitepaper says referred prompts are encrypted into storage you control, and OpenAI keeps the index. @stretchcloud quoted the post at 23:52 UTC the same day, 229 impressions and one like, and wrote that OpenAI moved the custody problem. That part matches the paper.
What gets written
The developer guide says the system encrypts the record and writes it to your regional cloud storage. OpenAI keeps an index with operational metadata and a storage reference, not a copy of the content. Encryption and storage run asynchronously, and they do not block inference. The whitepaper says OpenAI retains operational metadata and storage references, not plaintext, and not an encrypted copy of its own.
A referral is not every call, and it is not a verdict. The guide says an interaction is selected by a safety classifier or an approved sampling policy, and that a referral does not establish a policy violation. The paper names the classifier cases: high-risk cybersecurity, biological research, a possible API key leak, a distillation attack. Sampling is separate. The paper says OpenAI can sample up to 100% of traffic for asynchronous review, that the maximum varies by product, and that it can be significantly lower. Your sampling policy determines which requests create retained objects. I do not know the rate on an account I do not hold.
The bucket has to be one of four. The setup guide lists AWS S3, Azure Blob, Google Cloud Storage, and Oracle Cloud Infrastructure Object Storage. The region has to match the project’s data residency. If encryption fails, the storage authorization fails, or the region check fails, the write is blocked. The paper says there is no fallback that stores the content on OpenAI’s side. If the regional container is missing, the data is not persisted.
The index is what they still hold. The paper says the fields can include organization or project scope, provider, processing region, the storage location or object reference, a content identifier, a timestamp, an expiration, an optional safety identifier, and routing or policy metadata. It says the index does not contain customer content in any form. A storage reference is not the prompt. It is the field the scheduler uses to fetch the prompt. If you have Compliance API access, and OpenAI has granted it, you can see a reason label for a record. The paper’s labels are CYBER, BIO, MISALIGNMENT, PROMPT_INJECTION, SUSPECTED_ABUSE, and SAMPLED. The label is not the transcript.
The window is 30 days
The guide says the records are written with a TTL of 30 days. The same guide says you have to retain encrypted records for at least 30 days, and that lifecycle rules must not delete them earlier. The AWS example is a rule named psp-retention, prefix openai/, expire current versions after 30 days. Azure, Google Cloud, and Oracle get 30 days in their setup steps too. The guide says that object expiration is separate from OpenAI’s decryption-key expiration.
The paper covers the keys. OpenAI’s ability to decrypt ends after 30 days whether or not you deleted the object. Workload-scoped HPKE keys rotate daily and are destroyed on a 30-day schedule. The runtime still enforces the original expiration if a key was already in memory. The index entry is deleted after 30 days. If your lifecycle is longer than that, the ciphertext can outlive their index. Their key cannot open it after the window, and a recovery key you registered might.
You can read your own records without calling an OpenAI API. Register an RSA-3072 public key and the bundle includes a recovery capsule encrypted to you. The private key stays in your cloud key service. The paper says that even then you cannot decrypt the encrypted_cot field. I am not going to expand that name. A field in your bucket is closed to you.
Revoking access is not deletion. The guide says each stored record is doubly encrypted, then describes an outer enterprise key management layer, then says that layer applies when EKM is enabled, and recommends you turn it on. The paper calls the outer layer optional. I am not collapsing those two pages into one sentence. With EKM on, OpenAI’s inner key is not enough. Pulling your key authorization stops further decryption. The guide says it does not delete the records and does not undo completed processing. Pulling the bucket permission from their storage gateway stops new reads and writes. The paper says that preserves the bucket, and that it does not stop a review of records they already fetched. Disconnecting storage in the console does not delete the cloud bucket or what is in it.
Images flagged as possible CSAM are the exception in the paper’s first footnote. Those are still retained for manual review and reporting, even in a zero data retention deployment. OpenAI says the law requires the report. The government-request section says personnel, with PSP, can access customer content only as ciphertext. The runtime is what still decrypts, for 30 days, in a hardware-attested environment the guide says is designed to disable human access.
The request is a different product
Private inference is the other item on the October 30 page. The page marks it an API preview: confidential computing, with strict verifiable controls, while the model runs. The whitepaper files it under planned enhancements. The paper says the standard safety runtime does not provide an inference-wide zero operator access guarantee. Private inference extends those protections to eligible safety-inference workloads. It does not automatically cover the initial API request. That request keeps the retention you already configured.
There is a second product that is not zero data retention. Private retention with PSP keeps the encrypted records in OpenAI-managed infrastructure. The paper says it is not compatible with zero data retention or with modified abuse monitoring. A customer-managed key, on the variations that support one, does not move that storage boundary.
@stretchcloud also wrote that the copy lands under your own key management, on S3, Azure Blob, or GCS, and that the runtime is the only thing that can decrypt it. The paper marks the outer key optional. The guide adds Oracle, and says the runtime is designed to be the only OpenAI workload that can decrypt. He was right that OpenAI moved the custody problem and did not delete it.
I left a cell blank on October 29. Vercel’s table labeled OpenAI’s row “ZDR with safety retention” and did not say how long. I wrote that I was not going to fill it in. The October 26 paper fills it. Referred prompts sit for 30 days in a bucket you are required to keep, and OpenAI keeps the index that finds them. Not training is still a different promise from not keeping. The paper says retained content cannot be used to train models.
The agents endpoint is still outside this. On September 15 the data controls table said /v1/agents is not zero data retention eligible, and application state is kept until you delete it. I checked the same table this morning. The zero data retention column is still No. Private retention with PSP is No on that row too. The guide says endpoint limits still apply when the new policy is on. I wrote in September that I did not need a theory of private safety processing for that API. The theory is published. The row is still No.
I did not connect a bucket. I read the paper and the guide.
If the work cannot sit for 30 days, this control does not do what the name says. The check is whether you can list an object under the openai/ prefix. The index is how they find it until day 30.