Attested #3: OpenAI's "confidential computing" starts after it reads your prompt

This week in confidential inference · Oct 27 – Nov 2, 2026

The biggest name in AI is now selling “confidential computing” on a product page. That’s good for everyone in this market and also a nice exercise in reading the diagram and the PDF side by side. Meanwhile the small providers found a new thing to sell inside enclaves: models with the refusals cut out, for security teams.

---

OpenAI Private Intelligence: the safeguards read your prompt first

OpenAI first showed Private Intelligence at DevDay on Sep 29, with Private Inference “coming this fall”. This week it pushed it again (Oct 30), and the white paper behind it is dated Oct 26. Private Intelligence is a bundle of business privacy controls. Most of it is stuff enterprise customers already had: Zero Data Retention, “you own your inputs and outputs”, limits on what agents can do. The new piece is Private Inference, and on the product page it sits right in the middle of the request flow, between “Your prompt” and “Your response”, labelled “Confidential computing, strict verifiable controls” and tagged “API Preview”.

The only technical description I could find is OpenAI’s Private Safety Processing white paper. It’s a lot narrower than the diagram. Quote:

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.

The paper is scoped to safety processing, so it only describes Private Inference for the workloads that re-read your content for safety review. It doesn’t spell out how the answering model is covered. The diagram fills in the order, though. Your prompt enters OpenAI’s environment and goes through “real-time safeguards” first, and only then reaches the Private Inference box. Even if the model call itself runs in confidential computing, OpenAI’s own safety layer has already read your prompt in plaintext outside it. That’s not end to end. The paper’s planned-work section talks about extending confidential computing to the rest of the safety pipeline “when necessary technology, capacity, and product commitments are met”. No date. And it’s only for customers that meet “eligibility and capacity requirements”.

And who verifies? The paper says approved workload configurations go into a transparency log that “authorized auditors” can inspect. I didn’t find anything about a customer fetching a quote for their own request. No public API docs, no model list, no price for the preview either.

Why it matters: this is the “trust me bro, but with a TEE somewhere in the building” pattern. If the confidential part only starts after OpenAI’s own safeguards have read the prompt, it isn’t end to end, whatever runs inside the box. It’s still a real step (eligible safety workloads in attested enclaves with no human access beat the alternative), and OpenAI saying “confidential computing” out loud will send buyers looking. But if you’re comparing, ask the same question as for everyone else on my list: can you, the customer, check a quote bound to your request? Nothing public from OpenAI says you can. Verification goes to authorized auditors, and the preview has no public API docs.

Uncensored, in an enclave, for security work

Two providers pitched the same thing about a day apart.

NEAR AI launched abliterated versions of DeepSeek V4.1 Flash 1017 and Qwen 3.8 27B on Oct 29, plus NEAR AI RED, a program for security teams (20% off the first month, private Slack, manual review of applications). The models themselves are open to every account. Per NEAR’s model API: Qwen 3.8 27B abliterated at $0.04/$1.35 per M tokens, DeepSeek 1017 abliterated at $0.30/$1.20, both verifiable: true.

Maple was already selling an abliterated DeepSeek V4.1 Flash (blog, Oct 24) and spent Oct 30 pushing it at security people: “Security models on Pro, Max and Team”. Redpill, NanoGPT and Venice list uncensored Gemma 4 26B TEE routes too.

The pitch is coherent, I’ll give them that. Your vuln findings are exactly the prompts you don’t want a provider reading, and mainstream models refuse a lot of them anyway. But “it runs in an enclave” is a checkable claim, so I checked (monitor, Oct 29 – Nov 2):

• NEAR’s two abliterated routes pass hardware, TCB, freshness, channel binding and workload identity on every run since they appeared. Source provenance and request route aren’t proven for either. Same state as NEAR’s new 1017 TEE route below. Better than most, not end to end.
• Maple: the monitor verifies the Nitro signature, freshness and channel on Maple’s enclave (TCB not proven), but it checks the enclave, not each model. Maple says its enclave verifies the model release before forwarding; I can’t see that step, so the abliterated route has no check of its own.
• Redpill’s uncensored TEE routes: the attestation it returns is missing the workload identity field my verifier needs, so hardware wasn’t evaluated.

Why it matters: this is the first use case where buyers will actually ask for the attestation, because the threat model is concrete. Good. Make the providers show it per model.

What we measured

Prices and catalog

• Chutes cut prices on two TEE models. Kimi K2.6 TEE went from $0.45/$1.95 to $0.39/$1.80 per M tokens, GLM 5.1 TEE from $0.98/$3.08 to $0.90/$2.90 (Chutes model API now vs. its Oct 24 Wayback copy). No announcement; my monitor first saw it on Oct 27. The models it’s been promoting since (DeepSeek V4 Pro, Qwen3.8 Max, Kimi K2.7 Code) are in its non-TEE batch from Oct 27.
• NEAR AI moved DeepSeek 1017 into its own TEE. Last issue I pointed out NEAR’s 1017 was served through OpenRouter ZDR, verifiable: false. This week a second 1017 route showed up, verifiable: true, “served privately from NEAR AI’s attested TEE infrastructure”, $0.30/$1.20 (model API). The OpenRouter one is still listed at the same price, so check which model ID you’re calling. Monitor status is the same as the abliterated routes above.
• And NEAR labelled Kimi K3.1 Pro honestly. Launched Oct 27 at $2/$10, and NEAR’s own follow-up post says it “runs on a partner provider’s infrastructure”, not in a TEE. API says verifiable: false. Credit where due.
• Tinfoil repriced PII redaction. It was $0.005 per request flat with an 8,192-token limit (Oct 26 Wayback copy); now it’s $0.80 per M input tokens plus $0.0002 per request, up to 80,000 tokens.
• Confidential AI now lists DeepSeek V4.1 Flash at $0.30/$1.20 (pricing). Result is partial: hardware, firmware, freshness and the TLS channel check out; workload identity, source provenance and request route aren’t proven.

---

Elsewhere

Phala x Foundry. Phala says it’s bringing its confidential GPU compute to Foundry’s OpenAI-compatible API, paid in USDF. Another payment-flavoured front end on dstack, the Umbra/Surplus pattern again.

Chutes on SayGM. SayGM’s “private models” can now run on Chutes, alongside NEAR AI Cloud which was already there. SayGM says its own gateway runs in Intel TDX with nonce-bound attestation, but its docs say the buyer-facing verification interface “is still being prepared”. Chutes’ post also says “all of the models we currently serve run inside hardware-attested TEEs”, one day after it announced seven non-TEE models. Its API flags 7 of 17 as not confidential.

Releases. Privatemode v1.61.0 (Oct 29): GLM-5.3 can switch reasoning off now, Contrast bumped to v1.26.0. tinfoil-go shipped v0.17.0-rc.5 and rc.6. dstack v0.6.3 (verifier, KMS, gateway, Nov 2): the KMS now always checks the OS image hash (the config switch to skip it is gone), and builds are reproducible. Nothing from nvtrust.

---

New names I’m looking at

OffRouter turned on private image generation (Oct 30): FLUX.2 klein in “a sealed GPU enclave”, $0.012 per image, USDC per call, signed receipt. Not verified.

Foundry (foundry_fi), see Phala above. No attestation docs of its own seen yet.