Attested #4: Anthropic can prove which model answered. Not who read your prompt

• Two breaches, and what an enclave changes
• FlashProve: proof of the model, not privacy of the prompt
• One Kimi K3.1 Pro, six kinds of “private”
• If you’re choosing a provider
• What we measured
  • Prices and catalog
  • Attestation
  • Post-quantum TLS
  • Tracker changes
• Security and research
• Elsewhere
• New names I’m looking at

This week in confidential inference · Nov 3 – Nov 9, 2026

Two kinds of “verifiable” showed up this week and they’re easy to mix up. Anthropic published a working proof system that tells you which model produced a reply. And Kimi K3.1 Pro landed on six services I track under the same name, with very different answers to who can read your prompt. One is a question about the model. The other is a question about the operator. You need both answered, and they aren’t the same answer. And as the week closed, two inference providers disclosed breaches, which is the case this whole category is sold on. That comes first.

§Two breaches, and what an enclave changes

On Nov 9 Fireworks updated its bulletin on an October intrusion. The attacker came in through a third-party cloud provider that hosted Fireworks development machines, and reached account and billing data and, for some customers, stored secrets, datasets and partial model weights. Fireworks says inference wasn’t affected because it keeps no prompts by default. What leaked was what it stored.

A few hours later NEAR AI paused NEAR AI Cloud, and by 03:32 UTC on Nov 10 it was back. Its incident report (dated Nov 9) says the attacker exploited a remote code execution bug in SGLang, the open-source inference engine on NEAR’s servers, to run code on one inference server and from there get access to its infrastructure. Through an internal system behind the deprecated Private Chat they downloaded account details (email, name, and for some accounts plan and balance) for about 100 users. They also reached 18 agents on a legacy NEAR AI Agents deployment that NEAR says wasn’t running in its TEE environment, and took their chat history, settings and logs. Two Cloud customers had API keys exposed in logs; those are revoked. NEAR says it found no indication that stored Private Chat conversations or uploaded files were accessed.

Then the part this newsletter exists for. NEAR writes that on Nov 8 the attacker “could also have observed user requests being processed on the accessed server, including requests running in confidential mode.” Its explanation: confidential computing “protects data from the operator and the host. It does not protect against a vulnerability in the software running inside the environment”. NEAR revoked sessions and admin credentials, replaced agent tokens, took Private Chat offline, deployed an SGLang fix on all inference servers, rotated the remaining credentials, completed a forensic review and reported the bug to the SGLang project. The report names no CVE.

That changes how to read my monitor. When NEAR came back, all 13 routes re-quoted with the same gates passing as before the pause, including workload identity on the same 8. Workload identity says which code is running. It says nothing about whether that code has a hole in it. Fireworks shows the limit of no-retention: it covers prompts, not what you upload. NEAR shows the limit of an enclave: it keeps the operator and the host out, not someone who gets in through the software inside it.

§FlashProve: proof of the model, not privacy of the prompt

Anthropic’s Frontier Red Team published FlashProve (post dated Nov 2, announced on X Nov 3). It’s an open-source zkSNARK system for “provable inference”. The provider commits to a set of weights, then attaches a proof to a reply showing those exact weights produced those tokens. You check the proof on a CPU without ever seeing the weights.

The numbers are a lot better than I expected from zkML. On Llama 4 Maverick (400B MoE, 4-bit), one H100 proves about 110 tokens per second. A proof is about 19 MB per 1,024-token request, and checking it takes 17 seconds on 24 CPU threads. Anthropic puts the cost at roughly 70 to 95 times the GPU time of serving the same requests on vLLM. Code and the Lean proofs of the protocol are Apache 2.0.

Anthropic lists the limits itself. Contexts go up to 1,024 tokens. The proof covers greedy decoding of an integer version of the model, so a sampled reply from a normal floating-point server won’t match it. Proofs are made after the fact, not inline. Side channels are out of scope. It’s a research prototype.

Then the part that matters for this newsletter. Zero knowledge here hides the weights. It doesn’t hide your prompt. To check a proof you need the commitment, the prompt and the reply, and the prover had your prompt to run the model in the first place. So FlashProve answers “did the model I paid for answer me?” and says nothing about who saw the question. Anthropic says as much: trusted hardware and cryptography “are complementary approaches with different guarantees”.

“Which model actually answered” is a real gap in confidential inference today. TEE attestation proves what code runs on which chip. It doesn’t by itself prove your request went there. My monitor has a gate for exactly this (request route: is the request bound to the attested backend?) and it passes on 8 of 89 checks where it applies. A proof per reply would close that gap from the other side. Until it works at real context lengths and someone ships it next to an enclave, the two answer different questions. Watch for anyone selling one as the other.

§One Kimi K3.1 Pro, six kinds of “private”

Moonshot released the Kimi K3.1 Pro weights on Nov 4. By Nov 8 six services I track were selling it. Same model name, prices per million input/output tokens:

• NEAR AI: $2/$10. NEAR’s model list says ownedBy: moonshotai, providerType: external, verifiable: false. Moonshot serves it, not NEAR’s TEE. NEAR labels it honestly, same as last week.

• Redpill: $2/$10, and its model API marks it is_tee: false. Redpill’s Kimi K3 is a TEE route via Chutes. K3.1 Pro isn’t.

• Venice: $2/$10, announced Nov 4 as “now Private”. On Venice “Private” means no storage, and Venice’s own privacy page calls that tier “trust-based”. Its model API flags this model supportsTeeAttestation: false and supportsE2EE: false. Venice does have TEE and E2EE tiers. This model isn’t in them.

• Tinfoil: $4/$20 (model API), live in enclaves on Nov 5, about 30 hours after the weights. My monitor started checking it Nov 6. Hardware, TCB, freshness, TLS channel and request route pass. Workload identity and source provenance aren’t proven.

• PPQ.AI: $4.22/$21.10 for private/kimi-k3-1-pro, which PPQ’s model API lists as owned by Tinfoil. That’s Tinfoil plus 5.5%. On my monitor hardware, TCB and channel pass. PPQ hands the backend check to Tinfoil’s router and there’s no receipt for PPQ’s own hop.

• Maple: $8/$25 (pricing). Maple thanked Tinfoil (Nov 5) “for getting Kimi K3.1 Pro running in secure enclaves”, and adds its own encrypted app and enclave on top. My monitor checks Maple’s enclave (Nitro signature, freshness and channel pass, TCB not proven), not the model behind it.

A seventh, NanoGPT, has listed a TEE/kimi-k3.1-pro since about Nov 8, with no price at first and now $4/$20, Tinfoil’s price. On Nov 9 its attestation endpoint answered “TEE attestation is not available for this model”. Since Nov 10 it returns an AMD SEV-SNP report from a Turin host with TSME, AMD’s always-on memory encryption, switched off, and my policy fails that.

So the same name costs $2 with no TEE and $4 in Tinfoil’s enclave, and Maple charges twice that again for its app. “Private” on one menu is a quote you can check. On another it’s a no-retention promise. Two resellers sit on the same Tinfoil enclave at different prices. The model name tells you nothing, check the route. It’s the “which model answered” problem from above, seen from the buyer’s side.

One more: Tinfoil’s API marks Kimi K3 deprecated with a removal date of Nov 12. If you pinned K3 there, move.

§If you’re choosing a provider

• Check the route, not the model name. Kimi K3.1 Pro costs $2/$10 with no TEE at three of the services above and $4/$20 in Tinfoil’s enclave. Ask for an attestation of the exact model ID you’ll call.

• A quote proves the chip, not where your request went. Of the 89 checks where it applies, 8 bind the request to the attested backend, all of them Tinfoil routes.

• Ask what runs inside the enclave as well as what sits outside it: what the provider stores, who can push a new image, how fast it patches the inference engine, and whether you’d see that change in the quote. NEAR’s breach went through the software inside the enclave, and Fireworks’ through what it stored outside one.

• Nobody pins machine identity yet (see the CVE below), and Intel and AMD treat physical memory attacks like DDRop, presented at CCS on Nov 18, as out of scope. If the datacenter operator is in your threat model, ask who runs the hardware.

§What we measured

§Prices and catalog

• Tinfoil cut three prices. DeepSeek V4.1 Flash input went from $0.65 to $0.60 per million and cached input from $0.13 to $0.01. Kimi K3 cached input went from $0.80 to $0.60, and Nomic Embed from $0.05 to $0.016. That’s the model API now against its Oct 27 Wayback copy. No announcement, my monitor saw it this week. Maple still lists DeepSeek V4.1 Flash at $0.65/$1.45.

• Venice added an abliterated DeepSeek 1017 to its E2EE tier. e2ee-deepseek-v4-1-flash-1017-abliterated is $0.375/$1.50 on Venice’s model API. NEAR sells its own abliterated 1017 at $0.30/$1.20. In the Nov 9 runs the Venice route passed hardware, TCB, freshness, channel and workload identity on my monitor. Provenance and request route weren’t proven, same as NEAR’s.

• Routine: NanoGPT dropped three TEE routes (Qwen3.5 27B, Kimi K2.7 Code, Nemotron 3.5 Lightning). Confidential AI’s API now serves only DeepSeek V4.1 Flash 1017. The site now prices it at $0.30/$1.20, matching its pricing page. Prem’s API still returns 403.

§Attestation

82 of 90 checks pass hardware and TCB, 23 pass workload identity, 2 pass source provenance, 8 of 89 pass request route, and 0 pass every gate (attestation page, run #3629, Nov 10). Two fail outright, both NanoGPT (below), and five didn’t answer. Last week hardware and TCB was 70 of 94, out of a different set of checks. On the morning of Nov 9 it dipped to 68 of 94, mostly NanoGPT, and most of that was my verifier; the fix below brought it back.

Around Nov 5, NanoGPT changed its attestation response. Seven TEE routes (GLM 5.1, GLM 5.1 Thinking, GLM 5.2, GLM 5.2 Thinking, Kimi K2.6, Kimi K3, Gemma 4 31B Thinking) now return a list of instances, plus failed_instance_ids and excluded_instance_ids. My verifier didn’t parse that format until Nov 9, so for four days the site showed them as failed. That was a parser gap, not evidence of a broken enclave. The fix went live on Nov 9, and since then all seven have read partial: six pass hardware, TCB and freshness, Gemma 4 31B Thinking passes hardware and TCB, and none has workload identity pinned yet. In run #3629 GLM 5.1 Thinking and GLM 5.2 Thinking didn’t answer, so they show as unavailable for now.

Here’s what the raw responses show. Each route returns 5 to 47 Intel TDX instances with NVIDIA GPU evidence (labelled Hopper for GLM 5.1 and Kimi K2.6, Blackwell for GLM 5.2, Kimi K3 and Gemma). My nonce is in every instance body, the failed and excluded lists are empty, and the certificates come from Chutes’ sek8s CA. That matches NanoGPT’s own docs, which say these routes go to Chutes TEE first. Last week GLM 5.1 and GLM 5.1 Thinking returned the wrong nonce, so on NanoGPT’s side this looks like progress. Three other NanoGPT routes (DeepSeek V3.2, Qwen3.5 397B, Qwen3.6 27B) still don’t return my nonce. They relay Chutes evidence through Redpill that’s bound to its own nonce, which NanoGPT’s docs describe, so since Nov 10 the site shows them as partial with freshness not proven rather than failed.

The two failures are NanoGPT’s DeepSeek V4.1 Flash and Kimi K3.1 Pro. Both attest from AMD Turin hosts with TSME off, and my policy fails that. The same two models pass hardware and TCB on Tinfoil’s own endpoint. Before this week’s Turin fix (see tracker changes) they failed on TCB instead.

Elsewhere, Confidential AI’s cluster check and NEAR’s Kimi K3 route came back from unreachable. NEAR’s GLM 5.3 looked like it didn’t return my nonce for three weeks; that was my verifier not reading NEAR’s Tinfoil-backed format, and since Nov 10 it shows as partial (hardware, TCB and freshness pass). Two checks now pass both workload identity and source provenance (run #3629, Nov 10). One is Tinfoil’s router (v0.0.173 in that run, released Nov 10), a gateway rather than a model route, so it doesn’t count as end to end. The other is Tinfoil’s PII filter, which I now check directly; it still lacks freshness and route proof.

§Post-quantum TLS

No change. 10 of 11 providers negotiate hybrid X25519MLKEM768 and NEAR AI negotiates none. All 11 still accept a classical handshake, and for the ten hybrid ones I can only see the edge, not whether TLS ends inside the enclave.

§Tracker changes

A new providers table puts all 13 providers on one page, including two additions. Enclave42 publishes per-token prices (Gemma 4 31B TEE $0.16/$0.48, Kimi K3 TEE $3.90/$19.50) billed from a wallet, and most of its models also need a plan from $99/mo. Cohere’s encrypted Model Vault is priced per GPU-hour. Neither exposes attestation I can check without an account, so both are listed but not monitored. The verifier now applies AMD’s per-generation TCB minimums, so Turin hosts aren’t held to Genoa’s numbers. And run pages now say “Aborted” when a run stops partway, instead of “Completed”. A new methodology page spells out how checks run, the seven evidence gates, what a TEE doesn’t prove and the known physical attacks on server TEEs, and /llms.txt gives AI tools a map of the site and its APIs.

§Security and research

Diversion attacks get a CVE. On Nov 5 NVD published CVE-2026-119344 for Cocos AI, Ultraviolet’s open-source confidential computing system (advisory from September, fixed in v0.9.0). Older Cocos versions accepted any valid TEE evidence with the right firmware and measurements “without binding the Evidence to an allowed platform owner or unique machine identity”. Someone who controls another genuine platform that the same verifier trusts can hand in that platform’s evidence instead. The CVE text says it “can’t be patched in source code alone, since the vulnerability arises from the confidential computing threat model itself”. The workaround is an allowlist of hardware instance IDs (PIIDs on TDX). Intel’s Platform Ownership Endorsements are meant to fix it properly, but per the advisory no cloud offers them yet. A second CVE, -119345, covers attesting only once on a long-lived TLS connection.

This applies to every verifier in this market, mine included. My TDX policy checks TCB level and attributes, not which machine signed the quote, and none of the providers I track publish a machine list to pin against.

Papers. CORDE (Nov 4) proposes “Confine or Declare” for confidential VMs. Data derived from your prompt can leave the CVM only after it’s logged (contents, recipient, reason) in a tamper-evident log you can read. About 0.5% latency on AppWorld on an H100. That’s a cleaner answer to last issue’s problem, where OpenAI’s safety layer reads your prompt outside the confidential part. Bilateral protection for private LoRA inference (Nov 3) has both the client and the adapter owner check the TDX attestation and its TLS key binding before releasing inputs or the adapter key. Under 1% steady-state overhead, CPU inference.

§Elsewhere

Google put confidential computing on a TPU. On Nov 9 Google announced TPU 8tx “for secure and confidential inference”: TPU 8t silicon on 5th Gen AMD EPYC hosts, with up to 2x lower latency than TPU 8t and “a near-zero performance penalty”, per Google. AMD’s release says the hosts use SEV, that an accelerator’s identity and security configuration are verified before it gets direct access to protected memory, and calls it the first cloud TPU with hardware-enforced confidential computing. Google gives no date or price. Google Cloud’s Mark Lohmeyer told Network World that “that entire system is attested”, but there’s no published way for a customer to check that for their own request yet. Same open question as OpenAI’s and Cohere’s offers.

Cohere put a price on encrypted Model Vault. Its pricing page started listing per-GPU-hour rates between Nov 3 and Nov 4 (going by Wayback). An encrypted H100 is $9.00 an hour against $6.25 standard, a B200 is $12.00 against $9.75. That’s 44% more on H100 and 23% on B200. Until Mar 31, 2027 both tiers cost the same promo rate ($4.25 and $8.00). The same week Cohere added open models to Model Vault. For the encrypted tier its docs now list Gemma, GPT-OSS, Phi, Qwen, Ministral and Devstral, not DeepSeek or GLM. It’s dedicated GPUs by the hour, so it doesn’t fit the per-token comparison, but it’s a large vendor putting a public number on confidential.

NEAR AI is in Palo Alto Networks’ Prisma AIRS as a model provider, per NEAR (Nov 4). Enterprise security tooling is a better sales channel for this than crypto Twitter.

AWS Nitro Sandboxes went live on Nov 9: each EKS pod, ECS task or small VM can run in its own Nitro-isolated VM, at no extra charge. The part that matters here is Confidential mode. The Nitro Security Module signs an attestation of what booted, KMS releases secrets only to the expected image and policy, and AWS says a cluster admin can’t read the pod’s memory. No GPUs are mentioned, and the root of trust is AWS’s own Nitro hardware, as with Nitro Enclaves. So it’s a cheap way to keep your own operators out of a CPU workload, not a confidential GPU.

Phala says it served 120.5B tokens in 24 hours on Phala Confidential AI (Nov 5, its own count, 69% of it Kimi K3). It also put FLUX.2 klein 4B image generation in a TDX GPU TEE (Nov 6).

Standards. IETF 127 starts Nov 14 in San Francisco. SEAT, the working group for putting attestation into TLS and other secure channels, has its agenda up. RATS went in with fresh CoRIM and EAR (attestation results) drafts, posted Nov 1 and 2.

On HN. “Gemini trains on chat history, even for subscribers” passed 730 points (Nov 4). It quotes Google’s help pages: chats picked for human review are kept up to three years, and “Please don’t enter confidential information”. That’s the demand side of everything above.

Releases. Privatemode shipped v1.62.0 (Nov 4) and v1.63.0 (Nov 7), with fixes for GLM-5.3-Flash 400 errors and stereo audio transcription, and Contrast v1.26.1. Its release notes also announce a coming breaking change: “Shared prompt cache will be enabled by default.” If you rely on cache isolation between users, read that one. Tinfoil shipped router v0.0.169 to v0.0.172 and tinfoil-go v0.17.0-rc.7 and rc.8. Nothing new from dstack after v0.6.3, or from nvtrust.

§New names I’m looking at

Solrouter (docs) is encrypted chat and API that decrypts inside an Intel TDX CVM on Phala, with a Solana receipt per call. Its public key endpoint answers with INTEL-TDX-PHALA. Read the fine print though. Only Qwen3.5 122B runs on a confidential H200. The smaller models (GPT-OSS 20B, Qwen3.8 27B, Qwen3-coder 30B) run on Nosana GPU nodes that can see the prompt and the reply, and the docs say so. Not on my monitor yet.

Orbio (docs) launched on Nov 3 as one chat for many models, with a Private mode. Per its docs, the browser encrypts to a key inside a Phala or NEAR AI enclave, Orbio only relays, and the browser checks the provider’s evidence before showing the answer. Then the interesting part: “A private answer is only billed if its evidence verified.” Private covers open-weight models only, and tool calls (search, pages, files) leave as normal requests, which the docs say. Not on my monitor.

Every issue, plus the live provider data behind it, is archived at confidentialinference.net. You can follow attestation changes as they happen via the alerts RSS.

If you run one of these services and I got something wrong, reply to this email and I’ll fix it in public.

Aljaz