At DevDay on September 29, OpenAI announced Private Intelligence. The headline version is easy to repeat: frontier models, confidential computing underneath, and your data stays private, even during inference.

The documents tell a more careful story. Private Intelligence is two things, and they are at very different stages:

  1. Zero Data Retention with Private Safety Processing (PSP). This is rolling out to eligible API customers, and OpenAI published a 36-page technical white paper describing it.
  2. Private Inference. This is a preview “coming this fall.” OpenAI hasn’t published the hardware, the trust boundary, or how a customer would verify it.

I’ve spent most of my career on attestation and key release, first in payments and then in confidential computing. The first item is the more interesting piece of engineering, and very few people are writing about it. The second is the bigger bet. This post is my reading of both, based only on what OpenAI and others have published as of early October 2026.

The problem PSP is solving

Enterprises want zero data retention. Frontier labs need to catch misuse, and some misuse only shows up across many interactions: someone probing safeguards, doing reconnaissance, or running an agent that keeps going after it was told to stop. Each request can look fine while the sequence is not.

The usual fix is to keep the content so someone can review it later. That doesn’t work for health records, legal files, source code, or anything a regulator cares about.

PSP tries to keep safety review possible without giving anyone at OpenAI the content. Records can be retained and reviewed, decryption happens only in an attested runtime, and only fixed, predefined safety decisions leave it in plaintext. One caveat matters from the start: in the standard setup, the model-inference path the reviewer relies on isn’t covered by the full no-operator-access guarantee. More on that in Flow B.

That changes what you’re being asked to trust. Instead of “our employees aren’t allowed to look,” the claim becomes “the key is only released to a measured workload, and that workload can say very little.”

The architecture in two flows

Flow A: capture and retain

A request and its response get selected, either by a safety-classifier referral or by a sampling policy. A referral doesn’t mean anyone did something wrong. Then:

  1. OpenAI wraps the record in an inner HPKE envelope (DHKEM P-256, HKDF-SHA-256, AES-256-GCM).
  2. A customer-managed key wraps the data-encryption key in an outer layer.
  3. A Customer Storage Gateway writes the ciphertext to the customer’s own bucket, in their region. OpenAI’s docs list AWS S3, Azure Blob, and Google Cloud Storage as the options.
  4. OpenAI keeps approved metadata and a pointer to the object. It doesn’t keep the payload.

If encryption, authorization, or the region check fails, the record isn’t written. OpenAI says there’s no fallback that stores the content on its side.

Flow B: asynchronous review

  1. A Safety Review Scheduler picks a record from the metadata index.
  2. The gateway fetches the ciphertext and checks integrity, expiry, region, and the customer’s key authorization.
  3. The Safety Review Runtime (SRR), running in a hardware TEE, presents attestation evidence to get the inner key through what OpenAI calls Secure Key Release.
  4. Inside the TEE, SRR decrypts the record and coordinates review using an approved, versioned prompt and a fixed output schema.
  5. The full result is re-encrypted and written back to customer storage.
  6. Only bounded safety decisions and approved operational metadata go back to OpenAI in plaintext.

The scheduler and the gateway never hold the private key or see plaintext.

The boundary caveat. “Inside the TEE” needs a qualifier. The white paper says the standard 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 the optional add-on that extends operator-access protection and attestation to those safety-inference workloads. So in the base product, the key release and decryption are attested, but not every component that handles plaintext during review sits inside the no-operator boundary.

What the customer signs up for. The customer runs the storage. Its bucket has to keep the encrypted records for at least 30 days, and OpenAI checks that lifecycle rule when the bucket is registered. The customer also has to keep OpenAI’s storage and key access working for reviews to happen. Revoking key access is a real control, but it’s also a choice to stop future review of those records.

measure workload → log approved policy hash → attest running environment
   → release key only if policy matches → decrypt inside TEE
   → emit only fixed-shape decisions → re-encrypt everything else

Private Safety Processing: capture flow writes ciphertext to customer storage; review flow decrypts only inside an attested TEE and emits only a bounded decision

Walking through an example

Here’s a hypothetical case to make the flows concrete. The company and the scenario are made up. The mechanics follow OpenAI’s public documentation.

A regional bank uses the API, with ZDR and PSP turned on, to power an internal coding assistant. The bank has set up a bucket in its own cloud account, in its own region, with a 30-day lifecycle rule. It also wraps keys with its own KMS.

Over an afternoon, one developer account sends a run of requests. One asks how a particular authentication library handles session tokens. Another asks for a script to enumerate hosts on an internal subnet. A third asks how to keep a process running after a monitoring tool tries to stop it. Taken one at a time, each could have a legitimate development or security-testing purpose.

Capture. A safety classifier refers one of these interactions. OpenAI’s encryption client puts the prompt and response in an HPKE envelope. The bank’s KMS wraps the data key. The gateway writes the ciphertext to the bank’s bucket. OpenAI’s index now holds metadata and an object reference, not the conversation. In the bank’s Compliance API feed, a RETENTION_CREATED event shows up with a stable content ID and a reason category such as CYBER.

Review. Later, the scheduler queues the record. The gateway pulls the ciphertext. Review only proceeds once the record’s integrity, expiry, region and the bank’s key authorization check out. The pipeline uses the bank’s KMS to recover the data key; the white paper is explicit that this step is separate from attestation-based key release. SRR then asks for the inner key. The key service checks two things: that this workload identity is allowed to request it, and that the attestation evidence matches an approved policy hash already recorded in the transparency log. Both pass, so the key goes into protected memory.

SRR decrypts the actual exchange inside the TEE and coordinates the review. OpenAI frames PSP around patterns across interactions: the scheduler watches the metadata index for signals like an uptick in cyber-classified content, and earlier encrypted reviewer results are reused as context for later reviews.

Output. OpenAI receives a small, fixed-shape result, something like a category and a decision. It doesn’t get the code, the subnet, or an explanation. The detailed reasoning is encrypted and written back to the bank’s bucket. A CONTENT_ACCESSED event appears in the bank’s feed.

What the bank can check. Its own storage and KMS audit logs show the object being read and the key being used, depending on how its cloud provider’s logging is configured. Its Compliance API feed shows that the record was retained, why, and when it was accessed.

What isn’t exposed to the bank. The public documentation doesn’t describe giving the bank the attestation evidence for that review, or a proof that the policy hash was in the transparency log. Its own KMS approves the unwrap based on the access it granted OpenAI at setup, not on what’s running. Only OpenAI’s inner key is tied to attestation. If the bank revokes KMS access tomorrow, future reviews of that record fail, but this review has already happened.

Where it could still leak. Suppose the same record is reviewed ten times with slightly different reviewer prompts. Each answer is bounded, but together they say more than any single one. The white paper says plainly that PSP “currently does not impose a limit on the total information disclosed across repeated reviews,” and lists a fix as planned work. The bank can see repeated CONTENT_ACCESSED events, but nothing in the documented design stops them yet.

The bank example as a five-step timeline: what happens, what the bank can see, and what it can’t see

The example shows the core trade. The bank never hands its content to OpenAI staff, and OpenAI can still notice a pattern that no single request would reveal.

Two conditions for key release

The key is released only when two independent checks pass:

  • Workload authorization: this workload identity is allowed to ask for the key.
  • Environment verification: attestation from a trusted authority satisfies the release policy, including a match on an approved Confidential Computing Enforcement (CCE) policy hash. In OpenAI’s description, that policy pins the allowed container contents and execution configuration.

People from payments will recognize this pattern. It’s close to binding a token to a device’s attested state before provisioning credentials to it. Key release depends on both who is asking and what is running.

Customer key management adds a second gate on top. Revoking it blocks future decryption. It doesn’t delete ciphertext or undo reviews that already ran. This is dual control, not multi-party computation, because plaintext still exists inside SRR.

One design choice deserves attention. According to the white paper, the inner HPKE keys are shared across customers within a workload scope, rotated daily, and destroyed on a 30-day schedule. OpenAI’s stated reason is that key selection inside the runtime can’t be used to target a particular customer. The cost is that per-customer cryptographic separation depends on the outer, customer-managed layer. If a customer doesn’t enable its own keys, that separation is weaker.

Bounded outputs matter as much as the TEE

A TEE stops the host from reading memory. It does nothing to stop the workload from leaking what it knows. A buggy reviewer, or one hit by prompt injection from the content it’s reviewing (the bank’s developer could have pasted anything), could write customer data into a log line, a network call, or its own output.

PSP addresses this directly. SRR can emit only three things:

  1. Bounded plaintext decisions in discrete, fixed-shape fields. Free text, explanations, and excerpts are rejected.
  2. Encrypted detailed results, which go back to customer storage.
  3. Approved operational metadata.

There’s also allowlisted structured logging, network egress restricted to approved destinations, and a rule that reviewed content can’t grant tool access or change where traffic goes.

Most confidential AI designs I’ve seen are weakest here. Encrypting memory is the easier half; deciding what may leave, and enforcing it, is the harder one.

What “verifiable” means today

On the deployment side, OpenAI records source revisions, image hashes, CCE policy hashes, and changes to key-release policy. An SRR deployment can’t go ahead until its policy hash is in a tamper-evident transparency log. Changing a reviewer prompt needs a second approver, and SRR won’t run a prompt whose hash isn’t logged.

Customers see the lifecycle side of this through Compliance API events and their own storage and KMS logs. But the public documentation doesn’t describe customer access to:

  • raw attestation evidence per review,
  • a chain they can verify themselves from the hardware root to the measured workload,
  • inclusion or consistency proofs from the transparency log,
  • reproducible builds tying public source to deployed measurements.

So as documented today, “verifiable” mostly means verifiable by OpenAI’s own control systems and by authorized auditors. That’s already a big step past “trust us,” and it leaves room to grow toward the customer-side verification Apple showed with Private Cloud Compute.

The same goes for the white paper’s statement that the scheduler and gateway never receive the key or plaintext. It’s a careful design, but a reader can’t independently confirm that boundary today.

Where information can still leave, by OpenAI’s own account

Everything in this list comes from the white paper itself, not from my guesses. Repeated reviews, covered in the bank example, belong here too.

  • The reviewer’s inference path. Covered in Flow B: without Private Inference, it lacks an inference-wide no-operator-access guarantee. OpenAI’s planned work is to cover “the rest of the plaintext-handling components of the Asynchronous Safety Pipeline.”
  • The original API request. PSP doesn’t change it. It keeps its normal ZDR protections and isn’t covered by confidential computing.
  • The bounded output itself. Small, but not zero: a decision and a short list of category labels (the example schema allows up to four), plus operational identifiers such as the response ID.
  • Metadata OpenAI keeps. For 30 days, the index can hold organization or project, region, object reference, content ID, timestamps, expiry, an optional customer safety identifier, and routing or policy metadata. It contains no content, but it shows who was flagged, when, and how often.
  • Operational logs. These are allowlisted, but can include request volumes, key-release status, safety-decision categories and sanitized failure types.
  • Non-targetability has limits. Shared inner keys stop key selection from singling out a customer. OpenAI notes this doesn’t stop an authorized workflow from selecting a customer’s records, or the content itself from identifying who wrote it.
  • Collaborative investigations. If a review raises a concern, OpenAI may notify the customer. Anything the customer chooses to share at that point can be read by OpenAI staff. The original records still stay sealed.
  • What’s out of scope. Amazon Bedrock and other third-party channels aren’t covered. Neither is legally required retention of images flagged as potential CSAM, which continues even under ZDR. The OpenAI-hosted variant, Private Retention with PSP, keeps encrypted records in OpenAI storage and isn’t ZDR.

None of this undoes the design. It’s what an honest threat model looks like, and OpenAI deserves credit for writing most of it down.

What I’m looking forward to in Private Inference

Private Inference is listed under Planned Enhancements, so details are still to come. End-to-end confidential inference is hard because every component that touches plaintext has to sit inside the attested boundary, not only the model server. What I’m curious to see:

  • Which CPU and GPU TEEs, and is their evidence combined into one session-bound result?
  • Where does the client’s encrypted channel terminate?
  • Are the router, tokenizer, batching, KV cache, and streaming inside the boundary?
  • Are CPU-to-GPU and GPU-to-GPU links protected?
  • What about tools, connectors, hosted shells, memory, and MCP calls?
  • Can a customer get attestation before sending a prompt?

Private tokens aren’t the same as private agents

A model provider is now selling attested workloads and key release as part of the product. Buyers will start asking model vendors for the same proof they already ask infrastructure providers for. And the pattern itself, review inside a constrained environment and release only bounded decisions, carries over to fraud detection, clinical quality review and compliance classification.

Agents are where it gets hard. OpenAI’s own ZDR eligibility list shows the gap: conversations, vector stores, hosted containers and third-party MCP servers each have their own state and retention rules. Protecting the tokens in one inference call is not the same as protecting an agent that remembers, holds credentials and calls tools. At some point the attested boundary has to cover memory, credentials and tool calls, so an agent can show which policy and tools were in effect when it acted.

The evidence I’d want next

PSP is a careful design, and it’s good to see it documented this openly. Private Inference is the chance to close the remaining gap. Concretely, I’d want a customer to be able to get:

  • attestation evidence for the environment that handled their data, before and after it ran,
  • a proof that the release policy was in the transparency log,
  • builds that tie published source to the measured workload,
  • a clear statement of which components, including inference and tools, are inside the boundary,
  • a limit on what repeated reviews can reveal.

That list is what would turn “trust our controls” into “check them yourself.”

Disclaimer: The views expressed here are my own and do not represent those of my employer.

Sources