sysnote
News

OpenAI pitches Private Inference for business prompts, but its own white paper limits it to safety review for now

OpenAI launched a privacy package for businesses on October 30 called Private Intelligence. Most of it is a list of controls companies already had: Zero Data Retention (ZDR), data ownership, admin limits on what agents can do, encryption and the usual compliance badges. The new item is Private Inference, marked "API Preview" and described on the product page as "confidential computing, strict verifiable controls". The page's diagram puts it right in the request path, between "Your prompt" and "Your response".

OOpenAI@OpenAI

Privacy should advance as fast as intelligence. OpenAI Private Intelligence gives businesses stronger controls over their data while using our most capable models.

We’re building these protections in close collaboration with some of our largest customers to help businesses apply… pic.twitter.com/RWhIX72c09

October 30, 2026

The page doesn't say which models the preview covers, who can join it, what it costs or when it leaves preview, and OpenAI hasn't published API docs for it. The only technical description of Private Inference that OpenAI has published is in the Private Safety Processing white paper, released four days earlier, and that document scopes it a lot more narrowly than the diagram does.

What the white paper says Private Inference covers

The paper's section on boundaries is blunt:

The standard Private Safety Processing runtime is protected from human access, but its storage-disabled inference path does not provide an inference-wide Zero Operator Access (ZOA) guarantee. Private Inference is an optional protection that extends operator access protections and attestation to eligible safety-inference workloads. It does not automatically cover the initial API request, which keeps its configured data retention protections, or every OpenAI system.

Covering more than that appears only under planned enhancements: OpenAI says it expects "to extend confidential-computing protection beyond the protected safety-inference stack when necessary technology, capacity, and product commitments are met."

So, going by OpenAI's own documentation, the hardware-attested confidential computing currently protects the system that re-reads your prompts later for safety review. The model call that actually answers your request runs under your normal retention settings, with no operator-access guarantee. The product page may describe something broader that hasn't been documented yet. If so, OpenAI hasn't said what.

What Private Safety Processing does

The white paper is mostly about Private Safety Processing (PSP), and it explains why OpenAI needs it. Under "ZDR with PSP", certain API interactions are kept for automated safety review even though OpenAI says it retains no customer content. An interaction is kept for one of two reasons. Either a classifier fires (high-risk cybersecurity or biology, leaked API keys, distillation attacks), or a sampling rule picks it. On sampling, the paper says OpenAI "can sample up to 100% of traffic for asynchronous review", adding that the exact maximum "varies by product offering and can be significantly lower." The developer guide refers to "your sampling policy" but doesn't say who sets it or what rate applies.

Selected records are encrypted and written to a cloud bucket the customer owns, which must keep them for at least 30 days. The inner encryption layer is HPKE (P-256, HKDF-SHA256, AES-256-GCM) with keys that OpenAI manages, rotates daily and destroys after 30 days. Customers can add an outer layer with their own key management, and they can cut OpenAI off by removing its access to the bucket. Per the paper, that "does not undo completed processing or stop a review of records already retrieved." OpenAI itself keeps only a metadata index pointing at the stored objects.

The decryption happens inside a hardware-attested enclave that OpenAI calls the Safety Review Runtime, which receives keys only after attestation. Reviewer prompts need two-party approval, and their hashes go into a tamper-evident transparency log that the runtime checks before using a prompt. In the example schema, only two fields leave the enclave in plaintext: a decision (allow or block) and a short list of signals drawn from bio, cyber and misalignment. Customers can register their own key to decrypt their records, but "customers cannot decrypt the encrypted_cot field". The paper doesn't explain that field, though the name suggests a chain of thought.

The caveats are in OpenAI's own documents

  • No limit across repeated reviews. "PSP currently does not impose a limit on the total information disclosed across repeated reviews of the same content." Each review emits only a few bounded fields, but nothing caps how many times the same record gets reviewed.
  • Images flagged as CSAM are still retained for human review, even under ZDR, Modified Abuse Monitoring or Private Retention with PSP, per the data controls page.
  • The setting applies to a whole project. Once PSP is on, it applies to every API request in that project, "including requests to models that do not otherwise require PSP." The guide also warns that "models that require ZDR with PSP may become unavailable" if the project's policy changes. In other words, some models already require it from ZDR customers. Neither document lists which ones.
  • ZDR can be withdrawn model by model. The data controls page says OpenAI reserves the right to make models ineligible for ZDR for specific customers, with written notice. Content then goes to what is now called Private Retention with PSP (formerly "Eyes Off"): encrypted logs in OpenAI's infrastructure, excluded from human review unless the law requires it.
  • Verification is mostly for auditors. The transparency log records which enclave configurations were approved, and "authorized auditors" can inspect them. Customers get content-lifecycle events through the Compliance API, with reasons such as CYBER, BIO, MISALIGNMENT, PROMPT_INJECTION, SUSPECTED_ABUSE and SAMPLED. Neither document describes a way for an ordinary customer to check attestation for their own requests.
  • Only OpenAI's own platform. Traffic through third-party arrangements, such as Bedrock, is out of the paper's scope.

None of this makes PSP a bad design. Keeping safety-review copies in a customer's own bucket, readable only by an attested machine, is a real improvement over plain encrypted logs that OpenAI holds. But it changes what "zero data retention" means in practice: OpenAI keeps nothing, while an OpenAI system can still decrypt and read a sample of your traffic, potentially all of it, for 30 days. It's also a reminder that safety monitoring and ZDR pull against each other, which came up in OpenAI's misalignment monitoring write-up a day earlier.

What to ask before relying on it

If you're evaluating Private Intelligence, the useful questions aren't on the product page. They are which models and endpoints the Private Inference preview covers, whether the initial API request is now inside the attested boundary or still outside it as the October 26 white paper says, which sampling rate applies to your account, and which models now require PSP. OpenAI says it's building the protections "in close collaboration with some of our largest customers". It hasn't named any of them.

Comments

No comments yet. Be the first.

Write a comment

Comments are published after review.