aljaz
aljaz
← Back to all articles Attested #1

Attested #1

Oct 21, 2026 • 9 min read

This week in confidential inference: attested Leo, hash-pinned DeepSeek, a 38% Kimi K3 cut, and zero providers verified end to end

So here’s the first issue of Attested. I’ve been running **confidentialinference.net** for a while now, mostly because friends kept asking me which confidential inference providers to use (or didn’t know there were any). A weekly writeup felt like the obvious next step. Or a very elaborate way to procrastinate, I’m not sure which one is actually true. But it also gives me an excuse to keep myself up to date on all things confidential inference (and computing).

Brave Leo now talks to a NEAR enclave#

On Oct 15 Brave turned on end-to-end encrypted chat for GLM 5.3 Flash in Leo (Release, Beta and Nightly). Your prompt gets encrypted with Oblivious HTTP to a key that lives inside a NEAR AI TEE running TDX plus NVIDIA confidential computing. Brave’s relay sees your IP but not the prompt. NEAR’s enclave sees the prompt but not your IP.

Before anyone gets too excited - the prompt still gets decrypted. The model has to read it. What you get is operator isolation: the hardware is supposed to keep infrastructure operators (NEAR and Brave included) from reading what the attested code inside the enclave is processing.

The browser only gets the enclave key after Brave’s open source verifier checks the TDX quote, GPU attestation and a rebuild of NEAR’s code. Today that check runs in Brave’s gateway, not your browser. Brave says so itself and lists in-browser verification as a next step. And its opt-in, you only get it if you select GLM 5.3 Flash.

Its not the first confidential inference in production, Apple’s Private Cloud Compute was earlier. But a mainstream browser asking for an attestation quote instead of a pinky promise is the direction I want.

On my NEAR attestation page GLM 5.3 Flash is the only one of NEAR’s 9 TEE models that gets past the hardware check. The other 8 fail it.

For the harvest-now-decrypt-later crowd: OHTTP here is HPKE with X25519, which is classical, and NEAR’s public API endpoint didn’t negotiate hybrid post-quantum TLS in my latest probe, PQC run #32.

Tinfoil had DeepSeek’s new weights in a measured build the next day#

DeepSeek published DeepSeek-V4.1-Flash-1017 on Oct 17 and on Oct 18 Tinfoil switched the B300 build in its enclave repo to the new weights, pinned by commit hash to the same revision Hugging Face serves (1bae0e10…).

Each release ships with SEV-SNP and TDX measurements, the digest of its deployment manifest and a Sigstore entry for that digest. The container image has its own digest, pinned separately in the build’s config. Both v0.0.6+b300 and v0.0.7+b200 are up in the enclave repo.

This is how a model update on an attested service should look. Hash in a public config, a measurement to compare against the attestation report, an entry in a transparency log. No “trust me bro, we updated the model”.

Heres the catch tho. A public release doesn’t prove a given production request ran on that build, only fresh attestation from the serving endpoint matched to the release measurement does. I don’t have that yet. Tinfoil kept the public model name, deepseek-v4-1-flash, still at $0.65/$1.45 per M input/output in its model catalog, and my monitor couldn’t fetch fresh evidence for that route in its latest run (see the Tinfoil attestation page). So no match to a release. Yet.

Prem also lists “DeepSeek V4.1 Flash · 1017” among its confidential models, at $0.35/$1.40. Thats Prem’s own listing and my monitor hasn’t confirmed which checkpoint its enclave serves. Provider listing, not a deployment anyone has verified, unlike Tinfoil’s measured build. Its also the cheapest confidential price for that model I track, vs Tinfoil’s $0.65/$1.45 which PPQ and NanoGPT resell. And the same page has cached input on confidential models free until October 20. Which is the day this goes out, so don’t plan around it.

Chutes quietly cut Kimi K3 by 38%#

Chutes cut prices on four models on Oct 12 and didn’t announce it anywhere I could find. Kimi K3 went from $3.00/$15.00 to $1.85/$9.50 per M input/output tokens, so 38% off input and 37% off output. Date comes from archived copies of their own pages: the model API at 05:31 on Oct 12 still had the old prices, the pricing page at 19:24 the same day had the new ones (Rome time).

![](https://substackcdn.com/image/fetch/$s_!EBfI!,w_1456,c_limit,f_auto,q_auto:good,fl_progressive:steep/https%3A%2F%2Fsubstack-post-media.s3.amazonaws.com%2Fpublic%2Fimages%2F118acd16-e98a-42ed-94ce-b286b144a258_1200x1361.png)

Pricing in this space is still very .... varied. Kimi K3 elsewhere, public per-token TEE prices per M in/out, checked Oct 19:

The Redpill one is my favorite. Its a TEE route that Redpill’s own API says is served by Chutes, at a 62% markup on Chutes’ direct input price. Reselling with a markup, as one does.


What my monitor saw#

Prem joined on Oct 17 with the full check. First results from the Oct 19 run: 2 of 5 models pass hardware and TCB, DeepSeek V4.1 Flash and Nemotron 3 Ultra, both on Intel TDX. Both stall at channel binding. My monitor couldn’t verify that the encryption key is bound to the attested environment, so it can’t confirm the attested E2EE Prem documents and files both as “TEE-only gateway”. Thats a gap in what I could establish. Its not evidence that Prem’s gateway sees plaintext. The other 3 have been unreachable since Oct 17, so no verdict, good or bad.

Now the number thats gonna get screenshotted. Of the 97 checks my monitor runs on 11 providers, 55 pass hardware and TCB and 0 pass every gate my policy applies, as of the Oct 19 run.

![](https://substackcdn.com/image/fetch/$s_!zYhY!,w_1456,c_limit,f_auto,q_auto:good,fl_progressive:steep/https%3A%2F%2Fsubstack-post-media.s3.amazonaws.com%2Fpublic%2Fimages%2F4bea2c85-44ac-419f-bf2d-48616a0ac443_1200x1104.png)

Before somebody takes that out of context: its about my verifier, the routes I test, my policy and this observation window. It doesn’t prove that no provider can be verified end to end.

Almost everyone stops at workload identity (15 of 97), source provenance (1 of 97) or request route (0 of 96). Privatemode gets 13/13 through hardware and TCB, Chutes 13/14, Tinfoil 9/9 (tho 8 of Tinfoil’s had no fresh evidence in the latest run). NEAR AI gets 1 of 9, the Brave model.

Post-quantum TLS, from PQC run #32 on Oct 18: 9 of 11 provider endpoints negotiated hybrid X25519MLKEM768. Chutes and NEAR AI didn’t, and all 11 still accept a classical handshake. The nine hybrid ones are marked edge-only, because the monitor hasn’t established that TLS on those tested endpoints terminates inside the attested TEE. TLS only tho, application-layer encryption is separate. For Chutes the attestation dashboard records ML-KEM-768 application encryption keys.


Two software-only breaks of SEV-SNP#

FABRICKED and STALEUS, both from Benedict Schlüter and Shweta Shinde’s group at ETH Zurich, published at USENIX Security 2026 (the publisher dates it to August 2026). Both hit AMD SEV-SNP without physical access.

  • FABRICKED needs an attacker controlling both the UEFI firmware and the hypervisor and ends in arbitrary read/write in the guest plus forged attestation reports (CVE-2025-54510).

  • STALEUS needs hypervisor privileges and gets arbitrary read/write inside a fully attested CVM (CVE-2025-54509).

“The hardware attested” only means something if the TCB version behind it has the fix. On my monitor Privatemode and Tinfoil attest on SEV-SNP, and so do the PPQ and NanoGPT routes that resell Tinfoil. Thats why TCB policy is its own column on the attestation pages.

Patch your dstack#

Phala’s dstack v0.6.1 (Oct 13) fixes a bug where, on SEV-SNP, a certificate request could pass authorization with one os_image_hash while the issued certificate claimed another. Thats exactly where “attested” turns into “trust the cert”. On dstack? Upgrade guest OS, KMS and verifier. For context, NEAR’s GLM 5.3 Flash route shows up as Phala/dstack on its provider page and Redpill uses Phala attestation.

DDRop#

DDRop is going to ACM CCS in November. Its a DDR5 interposer that silently drops memory writes. The attacker needs privileged control of the host plus brief physical access to install it, and the paper puts the parts at about $159 per system when building ten, not counting assembly, testing or R&D. It breaks memory integrity on TDX, Scalable SGX and SEV-SNP, and on TDX they forged attestation reports with it. Intel and AMD call it out of scope (of course).

The researchers expect NVIDIA’s confidential GPUs to be out of reach because HBM sits inside the chip package, but they mark that as inferred from documentation, not tested. So no, confidential-GPU services aren’t shown to be immune. Who physically operates the hardware still matters.


CC overhead keeps shrinking#

Confidential AI published KV-cache offloading under CC on Oct 13. On B300s, CC on in both configurations, encrypted offloading did 141% more throughput than HBM-only serving on llm-d’s benchmark and cut mean time to first token from 39 s to 1.5 s. Careful tho, thats offloading vs no offloading. Its not a CC-on vs CC-off speedup.

If you want CC on vs off, NVIDIA’s own B200 numbers do that: on DeepSeek-R1 CC kept 96.1 to 98.2% of baseline output-token throughput (so 1.8 to 3.9% lost) and added 1.2 to 4.3% per-token latency. “TEEs are too slow” is getting hard to defend for inference.


New names (mostly routers)#

Most new entrants are routers on top of a few enclave operators. Question is always the same: does the router verify the upstream enclave or just pass the claim along?

NanoGPT at least answers it honestly for Kev-4B, Jared Palmer’s decision model that Phala has started serving. Its model API says it “does not currently enforce attestation or verify signed receipts for this route”. So the enclave is Redpill’s claim, not something NanoGPT checks for you.

And one I don’t track yet and haven’t run my verifier against. Umbra went live on Oct 18, an x402 pay-per-request gateway paid in stablecoin. It says the gateway runs in an Intel TDX VM on Phala’s dstack. But its own domains, umbra-inference.app and api.umbra-inference.app, are on Vercel, so there TLS terminates on conventional cloud hardware before reaching the TDX gateway. Only the phala.network endpoint goes to the enclave directly. The “standard” tier is Claude via Anthropic, which sees the prompt (Umbra labels this). Calls itself a public testnet. None of this is verified.


Thats it for #1. Full issue and the data behind it are archived at confidentialinference.net, and attestation changes go out as they happen via the alerts RSS.

If you run one of these services and I got something wrong let me know.

Aljaz

aljaz

aljaz

Freedom maximalist. https://nostr.eu | https://nostr.at || https://nostr.ae || https://start.nostr.net || wot.nostr.net || relay.nostr.net || https://my.nostr.net

aljaz@nostr.si
About Author
aljaz
aljaz ✓ aljaz@nostr.si

Freedom maximalist. https://nostr.eu | https://nostr.at || https://nostr.ae || https://start.nostr.net || wot.nostr.net || relay.nostr.net || https://my.nostr.net

Value 4 Value

Comments & Discussions (0)

Decentralized replies powered by Nostr (NIP-22 / NIP-10)
Loading Nostr comments...
🏷️ Topics
No items in this list.
Disclaimer: This article was syndicated from the open Nostr protocol. Jotstr does not host or curate decentralized third-party content.