In short. Of the 17 private-AI offerings we chose and scored from public documents and audits, only five check the server from the user’s own software on their standard path. Four more ship a client check that path doesn’t use, and most of the rest leave the check to a gateway, the vendor or nobody we could find. We’d rethink where the check belongs if published client verifiers accepted stale, replayed or altered evidence.
What this is. A scorecard built from the public documentation and independent audits of 17 private-AI offerings, as of 3 November 2026.
Contents
A real H100 vouched for a fake server
The TEE.fail team, from Georgia Tech and Purdue with an independent researcher, set up a server with no enclave. Their machine had an NVIDIA 3060 and a modified copy of vllm-proxy. Phala Network and NEAR AI had published that front end for private model serving. [1]
Asked for an attestation, the fake server sent two. The first was a forged TDX quote, Intel’s signed report. The team signed it with an attestation key they had extracted. The second was genuine. The fake server fetched it on demand from an NVIDIA H100 in a cloud server the team had rented. NVIDIA doesn’t tie an H100’s attestation to one virtual machine. Both checks passed. [1]
The team disclosed the attack to the affected deployments between May and July 2025. The paper says those deployments were working on mitigations. [1] As far as the authors know, nobody has used it in the wild. [2] But they say a provider could use one H100 to vouch for hundreds of instances. And a dishonest host, they write, could “covertly log all LLM requests while claiming confidentiality.” [1]
An attestation is a hardware enclave’s signed report of the software it booted. This essay asks who checks that report in 17 private-AI offerings, and what a passing check can and can’t prove.
Who can run the check
Our essay on cheap inference uses the word boundary for the point where data first becomes readable to someone else. For private AI, the boundary is wherever the prompt is first decrypted. The attestation check guards it. Whoever runs the check is the party you end up trusting. That party is one of four.
- The user’s own software (Client). Apple’s devices and the WhatsApp client both check before they send. [5] [6]
- A gateway, on the user’s behalf (Gateway). This is a server the user doesn’t run. Brave’s browser works this way. In Brave’s words, “Today, your browser relies on the gateway for this check.” Brave plans to move the check into the browser. [7]
- The vendor, checking its own systems (Vendor). Here the user’s software doesn’t check. In OpenAI’s safety review, a cloud key vault releases OpenAI’s keys to the review runtime only after checking attestation against policies OpenAI manages. [8] The review runtime sees only content referred for review, after OpenAI’s ordinary API servers have handled the request. [8]
- Nobody (None found). This leaves the customer trusting a policy. The label means we found no public description of a check, not that none exists.
Google’s Private AI Compute is the one offering we score Vendor, apart from its server-side memory feature. In the design NCC Group assessed in 2025, a central Google service checks the frontend server’s attestation. The phone trusts a key meant to be hardcoded in its code or configuration. [9]
Google’s September 2026 brief says a server gets its key only after passing attestation, and devices check that key before sending. It also describes the client setting up mutual attestation of auditable binaries over its Noise channel. [11]
But it lists device-side checks of the server’s evidence as a next step. It describes that as a move from Google-asserted compliance toward devices that check the evidence themselves. [11] We read that as leaving today’s server check with Google’s service, so the row says Vendor.
We add one more label. Customer option means the provider ships or documents a client check, but its standard path doesn’t use it.
For each offering we score the first path it documents, which is its own app or its API quickstart. We ask who checks the first component that can read the prompt.
Where each offering runs the check
Each line below reports what the provider or an auditor published, as of 3 November 2026, for the path the provider documents first. The appendix has the full entry for each offering. We’ll correct any cell a provider shows us is wrong.
| Offering | Who verifies | Why, in one line |
|---|---|---|
| Apple Private Cloud Compute | Client [5] | Device sends only to nodes whose measurements are in a public log. |
| WhatsApp Private Processing (Meta) | Client [25] | App checks a front orchestrator, which verifies the backend enclaves. |
| Privatemode (Edgeless Systems) | Client [34] | Via the SDK or local proxy that the API quickstart uses. |
| Maple (Maple Privacy Labs) | Client [56] | App checks the enclave and sends nothing if a check fails. |
| Tinfoil | Client [50] | Via the SDK that the quickstart uses. |
| Brave Leo with NEAR AI | Gateway [7] | Gateway checks before relaying, using a verification at most an hour old. |
| Google Private AI Compute | Vendor [9]; Client for the server-side memory feature [10] | A central Google service checks the server; devices check its key. [11] |
| NEAR AI Cloud | Customer option [37] | The quickstart uses curl and the standard OpenAI client, with no check. |
| Venice | Customer option [12] | Standard TEE requests reach Venice’s own API in plaintext. |
| Phala confidential AI (also via RedPill and OpenRouter) | Customer option [65] | The quickstart’s standard OpenAI client doesn’t verify the gateway. |
| Nillion nilAI | Customer option [63] | The quickstart sends a plain HTTPS request and checks nothing. |
| OpenAI API: Zero Data Retention and Private Safety Processing | None found [8] | First servers: no check found. A TEE later reviews referred content. |
| OpenAI Private Inference | None found [28] | The announcement doesn’t say who checks the attestation. |
| Proton Lumo | None found [40] | Proton’s post and support page describe no enclave or attestation. [68] |
| Anthropic confidential inference | Research design [30]; products: none found | A keyserver checks the loader; the API server still reads prompts first. |
| Zama Concrete ML (FHE) | Not applicable [51] | The server runs linear layers on ciphertext; no hosted LLM service found. |
| zkML: Lagrange DeepProve, EZKL | Not applicable [53] | Proofs show what ran, not who saw the input. |
The count is five Client, one Gateway, one Vendor, four Customer option and three None found. The last three rows are a research design and two cryptographic tools. Attestation doesn’t apply to the two tools.
A passing check proves only what the evidence binds, and a client check guards only the paths that use it. Each gap comes from the provider’s own documents, except Nillion’s fail-open behavior, which comes from our reading of its node’s code.
- In Privatemode’s proxyless mode, nothing the user runs checks the confidential proxy, run by Edgeless, that reads the prompt first. [33]
- A direct call to Tinfoil’s endpoint skips the SDK’s check and is covered only by audit-time verification. [50]
- Apple’s release notes say its devices and proxy nodes don’t yet enforce proof that a node’s certificate appears in Apple’s public log. [5]
- NEAR AI says all instances of one model share a signing key, even when their measured setups differ, so a signed response doesn’t show which instance answered. [4]
- Venice tells developers not to rely on the verified flag its own server returns. Its reference code leans on that flag and the nonce match. [12]
- Nillion’s optional n8n node checks the enclave’s AMD SEV-SNP attestation before sending. But it still sends when the check fails, and it doesn’t confirm the TLS binding live. [62]
Every check ends at a chip maker’s key
Fourteen of the 17 offerings put a hardware enclave somewhere on the prompt’s path. Most of those 14 rely, at least in part, on keys rooted with Intel, AMD or NVIDIA. Even a check on the user’s own device ends at a key a chip maker vouches for. Whoever steals that key can sign evidence that every verifier trusting it will accept.
Researchers with physical access have broken Intel and AMD attestation several times with cheap devices on a server’s memory bus. The table shows four such attacks.
| Attack | Cost | What it did |
|---|---|---|
| TEE.fail [1] | Under $1,000 for the whole setup, by the authors’ estimate | Recovered the key that signs a DDR5 Xeon server’s attestation keys. Intel’s provisioning certification service had rated the server fully up to date. The team then made TDX quotes that Intel’s quote-verification library accepted without any TDX virtual machine running. It needs physical access and root. |
| WireTap [13] | Under $1,000, by the authors’ estimate | Pulled the attestation key of SGX’s quoting enclave out of an older DDR4 Xeon server. |
| Battering RAM [14] | Less than $50 in parts | Could read and write the protected memory of Intel’s Scalable SGX on DDR4 servers. Broke AMD SEV-SNP attestation on fully patched systems by replaying launch measurements. |
| DDRop [15] | About $159 per unit | Brought active interposer attacks to DDR5 in September 2026. By dropping memory writes on Intel TDX, it let a rogue virtual machine replace its own launch measurement with a legitimate workload’s and pass remote attestation. |
Intel and AMD place physical memory-bus attacks outside what their products defend. Intel said TEE.fail doesn’t change its earlier position that such physical attacks are out of scope. [17] It said DDRop’s scenarios fall outside its standard threat model. [19] AMD’s 2020 SEV-SNP white paper puts tampering with the memory bus while a virtual machine runs out of scope. [55] The TEE.fail and Battering RAM researchers report that AMD held that position for their attacks. [2] [14]
The appendix has the rest of Intel’s statements and the longer history of stolen keys.
By our reasoning, an enclave doesn’t take the operator out of the boundary. You still trust whoever can physically reach the machine.
Trail of Bits made that point in its audit of WhatsApp’s Private Processing. It asked Meta to keep chain-of-custody records for every enrolled CPU. With them, Meta can show that each CPU is in its custody and exclude any that may have faced key-extraction attacks. A second recommendation notes that SEV-SNP’s threat model doesn’t defend against advanced physical attacks. [6]
Put the check on the user’s device
We think the check belongs on the user’s own device. It should refuse to send when the check fails. A gateway or vendor that checks for you moves the trust to itself. A client check still ends at a chip maker’s key. But your own software, not a gateway or vendor, checks the first component that can read the prompt.
The four Customer option vendors already ship or document client checks, and NEAR AI’s SDKs stop when a required check fails. [60] The work left is to close gaps like the ones listed earlier and make client checks the default path. Our page of proposed studies sets out a test of whether published client verifiers refuse stale, replayed or altered evidence.
An enclave makes it harder for insiders to reach your data. It doesn’t prove they can’t. It also does nothing about a copy kept outside it. A US court has ordered OpenAI to produce a sample of 20 million de-identified ChatGPT logs. The court noted OpenAI had kept tens of billions in the ordinary course of business. [3]
A team buying private AI for sensitive work should ask these questions before it picks a service.
- Client check. Does our own app or browser check the server before it sends the prompt?
- Open verifier. Is the verifier open source, and can we run it ourselves?
- Instance binding. Does a passing check name the instance that answered? Does it run on our side, or rest on a flag your server returns?
- Hardware root of trust. Which chip makers’ keys do we end up trusting, and how do you show who can physically reach the machines?
- Visible metadata. What metadata stays visible, such as IP address, model name, token counts and tool definitions?
- Retention exemptions. Which features and data types are exempt from your retention promise?
- Independent audits. Which independent audits cover this service, and which findings are still open?
Start with the first question. If the answer is no, you’re trusting whoever checks for you, or a policy.
Scope and limits
- What we did
- We scored each offering on who checks, before the prompt is sent, the first component that can read it. Cells rest on the provider’s own documentation, and on independent audits where they exist, for the path it documents first. Status uses the provider’s own words where it gives them.
- What we didn’t do
- We tested no service and ran none of the published verifiers. Every cell reports what a provider or auditor published. The 17 are offerings we chose, not a systematic sample of the market. The counts describe this set, not private AI as a whole.
- What this can’t tell you
- Whether a check exists that nobody describes in public. Whether a memory-bus attack is practical against a well-run data center. How many API customers check attestation when given the means. Who will check it for OpenAI Private Inference. What a Client check proves beyond the first component.
- Confidence
- Moderate. Each cell rests on what a provider or auditor published, and a provider can correct us. The memory-bus attacks are documented but need physical access. The TEE.fail researchers ran theirs on their own machines or test networks and know of no use in the wild.
- What would change our view
- A test of each published client verifier against evidence made stale, replayed or altered, including relayed GPU evidence like TEE.fail’s rented H100. If the verifiers accepted bad evidence, where the check runs would matter less than we argue. How a verifier fails would then matter as much as who runs it.
- Corrections
- We log every correction, with its date, on How we work. Send one through a research enquiry.
Appendix
The scorecard, offering by offering
Each entry gives one offering’s row and notes, as of 3 November 2026, from what the provider or an auditor published. In the Client rows, the user’s software mostly checks a front component that vouches for the machines behind it.
Apple Private Cloud Compute (Client)
Who verifies: The device checks the proxy node and sends only to nodes whose measurements are in a public, append-only log. [5] Apple’s proxy node can decrypt requests, and it checks worker nodes for the device. Devices and proxies don’t yet enforce proof that a node’s certificate is in the log. [5]
How privacy works: Apple-silicon nodes run with Secure Enclave and Secure Boot, behind a third-party relay. [22] Google Cloud nodes, announced June 2026, use Intel TDX, NVIDIA confidential GPUs and Titan chips. For parts that could leak user data, their attestation roots in at least two independent vendors. [23] GPU firmware rests on NVIDIA’s root alone. [5]
What the operator can still see: There is no remote shell or debugger. Only logs and metrics that Apple approves before a release leave a node. Crash reports are redacted on Apple silicon, and traces are allow-listed on Google Cloud. Apple says this reduces but can’t eliminate the risk of leakage. [5]
Status: In production. The first Google Cloud release has served requests since the 27.0 operating systems launched. [5]
WhatsApp Private Processing, Meta (Client)
Who verifies: The app checks a front orchestrator, which verifies the backend enclaves. [25] The client refuses enclaves that show evidence of tampering. [6] A third party keeps the transparency log, which Meta calls a simple log rather than a Merkle tree. [25]
How privacy works: Confidential VMs run on AMD SEV-SNP with NVIDIA Hopper GPUs. Attested TLS runs from the phone, through an IP-hiding third-party relay. [25] Trail of Bits found no indication that user data is available to Meta during processing or kept afterward. [6]
What the operator can still see: Allowlisted logs leave the enclave. Service counters leave without further filtering, and Meta says they hold no user data. Optional web searches send Meta up to 100 characters in plaintext. [25] In August 2025 the images couldn’t yet be fully rebuilt from public sources. [6]
Status: Live since June 2025, starting with Message Summaries. [26] Whitepaper V3 is dated 20 October 2026. [25]
Privatemode, Edgeless Systems (Client)
Who verifies: The SDK or local proxy that the API quickstart uses. [34] They check the Coordinator, Privatemode’s attestation service, against a manifest Edgeless publishes, unless the user pins their own. The Coordinator checks the workers. [35] In proxyless mode, nothing the user runs checks the Edgeless proxy that reads the prompt first. [33]
How privacy works: Confidential VMs run on AMD SEV-SNP or Intel TDX with NVIDIA H100 or B200 GPUs. Encryption keys go only to workers that pass attestation. [31]
What the operator can still see: Metadata such as IP address, API key and token usage is kept up to 90 days. Token usage per key is kept permanently for billing. The model name travels in plaintext headers. [32] Proxyless mode ends TLS in a confidential proxy Edgeless runs, where no-retention isn’t technically enforced. [33]
Status: Offered commercially. Documentation version 1.61. [31]
Maple, Maple Privacy Labs (Client)
Who verifies: The app checks the enclave’s attestation and sends nothing if a check fails. It checks a fresh nonce, Amazon’s certificate chain, the signature and an approved image fingerprint. Maple’s enclave then checks the model’s enclave, which the user doesn’t check directly. [56]
How privacy works: An AWS Nitro enclave holds keys and decrypts requests. It runs reproducibly built open-source code. Models run in their own attested enclaves. [56] Maple’s open-source backend routes them to Tinfoil and to Edgeless Systems’ Privatemode. [57]
What the operator can still see: Maple says prompts are decrypted only in its enclave and the model’s attested enclave. A matching fingerprint shows Maple approved the software, not that it was built from public source. [56]
Status: Offered. Maple says there is no independent audit yet. [56] The architecture was first described in February 2025. [39]
Tinfoil (Client)
Who verifies: The SDK that the quickstart uses. [50] It checks the router enclave against Sigstore-published measurements and stops on a mismatch. The router checks each model enclave. [49] A direct connection to the OpenAI-compatible endpoint skips that check and is covered only by audit-time verification. [50]
How privacy works: Confidential VMs run on AMD SEV-SNP or Intel TDX. Each NVIDIA GPU is checked for confidential-computing mode at boot. [48] Requests are encrypted to keys bound into each enclave’s attestation. [49]
What the operator can still see: The router enclave reads requests in order to route them. [49]
Status: Offered. V3 attestation, used by the Go and Swift SDKs and the CLI, is in beta. [49] [50]
Brave Leo with NEAR AI (Gateway)
Who verifies: Brave’s gateway. It checks the enclave’s attestation before releasing the key or relaying, using a verification no more than an hour old. Brave plans to move the check into the browser. [7]
How privacy works: NEAR AI runs GLM 5.3 Flash in Intel TDX with NVIDIA confidential computing. The browser encrypts each prompt to NEAR AI’s gateway enclave, which passes it to the model enclave. The browser sends it over Brave’s Oblivious HTTP relay. [7]
What the operator can still see: Brave sees the IP address, not the message. A deployment log pins the runtime, which isn’t rebuilt from source. The enclave doesn’t yet attest the exact weights. [7]
Status: In all Brave channels. The model is in beta. [7]
Google Private AI Compute (Vendor; Client for the server-side memory feature)
Who verifies: A central Google service checks the frontend server’s attestation, and devices check only the key a server gets after passing it. [9] [11] For the server-side memory feature, the label is Client. Android checks the enclave before sending key material. [10] The body gives our reasons for the Vendor label.
How privacy works: Gemini runs on TPUs in Titanium Intelligence Enclaves. [24] CPU work runs in AMD SEV-SNP, with Noise channels, third-party IP-blinding relays and a public ledger of production binaries. [11]
What the operator can still see: NCC Group found data exposed only if Google as a whole organization decided to, in a review that excluded the AMD SEV-SNP platform and the phone apps. [9] Trail of Bits found in 2026 that hashes of response fragments reach services outside the enclave. It lists the finding as unresolved and high severity, though hard to exploit and needing privileged internal access. [10]
Status: Announced 11 November 2025, first for Magic Cue and Recorder on Pixel. [24] The memory feature is described in the September 2026 brief. [11]
NEAR AI Cloud (Customer option)
Who verifies: The quickstart uses curl and the standard OpenAI client, with no attestation check. It points to a separate verification page. [37] NEAR AI’s own SDKs, at version 0.2.1, check the gateway’s evidence before sending and stop if a required check fails. [38] [60]
Verification tools: NEAR also publishes an attestation endpoint, a browser verification page and a verifier. [4] [59] Its documentation lists what a careful verifier checks before sending, from the DCAP quote and a fresh nonce to the event log and configuration measurement. Instances of one model share a signing key, so a signature doesn’t identify the instance that answered. [4]
How privacy works: NEAR’s documentation says its Intel TDX VMs run with eight NVIDIA H200 GPUs per node. Requests pass through NEAR’s gateway enclave to model enclaves. End-to-end encryption is optional. [36] “Incognito” models from OpenAI, Anthropic, Google and others run on their providers’ servers, outside any enclave. [58]
What the operator can still see: The gateway enclave handles requests that aren’t end-to-end encrypted. [36]
Status: Offered commercially. Documentation undated. [36]
Venice (Customer option)
Who verifies: On the standard TEE path, a request reaches Venice’s own API in plaintext, and we found no attestation for that server. [12] In Venice’s E2EE mode, the client checks the attestation against its own nonce and encrypts the prompt to the enclave’s key before sending. Its reference code leans on the server’s verified flag and the nonce match. The docs advise checking the TDX quote and NVIDIA attestation client-side in production. [12] E2EE replies in the app carry an icon that opens the attestation report. [61]
How privacy works: Enclave-hosted (TEE) and end-to-end-encrypted (E2EE) models run on Intel TDX with NVIDIA confidential computing. [12] Partners NEAR AI Cloud and Phala Network run them. [61]
What the operator can still see: Under E2EE only user and system messages are encrypted. The docs say tool definitions aren’t. [12] Venice says TEE users still trust it not to keep data in transit. [61]
Status: Offered. Documentation undated. [12]
Phala confidential AI, also via RedPill and OpenRouter (Customer option)
Who verifies: The quickstart uses the standard OpenAI client, which doesn’t verify the gateway. [65] Phala’s ACI verifier SDK and Private AI Proxy do check the gateway, though the SDK doesn’t check whether the dstack OS image is a production build. [41] The gateway checks each upstream and requires a channel binding before forwarding. [44]
How privacy works: A gateway in an Intel TDX enclave terminates TLS and forwards prompts to enclave-hosted providers. [41] [42] RedPill’s gateway is also a TDX workload, checked with Phala’s tools. [43]
What the operator can still see: The gateway enclave processes plaintext. [42] For NEAR AI upstreams it delegates per-model checks to NEAR’s gateway. For Tinfoil it checks the router, not each model worker. [44]
Through OpenRouter: OpenRouter also serves Phala’s models. [45] As a proxy, it handles the prompt first, though by default it doesn’t log prompts. [46] We found no check of it and no OpenRouter statement about enclaves or attestation. On 27 October 2026 OpenRouter said it will screen every inference request in flight for child sexual abuse material. [66]
Status: Offered. Documentation undated. [44]
Nillion nilAI (Customer option)
Who verifies: The quickstart sends prompts in a plain HTTPS request with an API key and checks nothing. [63] Nillion’s n8n node checks the enclave’s AMD SEV-SNP attestation before sending. By our reading of its code, it still sends when the check fails. It doesn’t confirm the TLS binding live. [62]
How privacy works: Inference runs in a TEE built on NVIDIA confidential computing, with an attestation API and signed responses. [47]
What the operator can still see: The documentation says prompts are hidden from the cloud provider. [47] The n8n node’s README says the operator, including Nillion, can’t see prompts or output. [62]
Status: Available with API keys from a developer portal. No release status stated. [47]
OpenAI API: Zero Data Retention and Private Safety Processing (None found)
Who verifies: None found for the servers that first read the prompt. [8] Classifiers run during the ordinary request, which Private Inference doesn’t automatically cover. Attestation applies only later, when a cloud key vault releases keys to the review runtime. Authorized auditors can inspect approved setups. [8]
How privacy works: Abuse-monitoring logs are kept up to 30 days by default. Zero retention needs prior approval. [27] Private Safety Processing encrypts content into customer storage for at least 30 days, for an automated review runtime in a TEE. The content is what a classifier flags or what an approved sampling policy picks. [8]
What the operator can still see: The whitepaper says the review runtime is shielded from human access, but its storage-disabled inference path lacks an inference-wide Zero Operator Access guarantee. It also says bounded safety signals and operational metadata reach staff in plaintext. [8] Some state persists under zero retention, such as encrypted prompt-cache tensors for up to 24 hours. [27]
Status: Zero retention by approval. [27] Whitepaper dated 26 October 2026. [8]
OpenAI Private Inference (None found)
Who verifies: The announcement doesn’t say who checks the attestation. [28] The product page doesn’t say either. [29] Nor does the whitepaper. [8] We found no mention of Private Inference in OpenAI’s developer documentation.
How privacy works: It was announced as combining confidential computing with strict, verifiable controls. [28] The whitepaper describes it as optional, extending operator-access protections and attestation to eligible safety-inference workloads. [8] The product page says it is designed to protect prompts and responses during processing. [29]
What the operator can still see: It doesn’t automatically cover the initial API request, which keeps its configured retention protections. [8]
Status: Preview announced at DevDay on 29 September 2026 as coming this fall. [28] Listed as a preview. [29]
Proton Lumo (None found)
Who verifies: None found. Proton’s post describes no enclave or attestation. [40]
How privacy works: The device encrypts each request’s key to the inference server’s public PGP key. Stored chats use zero-access encryption. [40]
What the operator can still see: The inference server decrypts and reads the message. Proton says the server doesn’t log or keep a request once it has answered. [40]
Status: Security model dated 4 August 2025. [40] Lumo 2.0, released 30 June 2026, was rebuilt on a new architecture. [67] Proton’s support page still describes no enclave or attestation. [68]
Anthropic confidential inference (Research design; products: none found)
Who verifies: In the research design, the keyserver checks the trusted loader. The API server reads the prompt first, and the post leaves that server’s security outside its scope. [30] For products, none found.
How privacy works: The design, with Pattern Labs, has a small trusted loader in an isolated VM and a keyserver that releases decryption keys only to environments that pass attestation. [30]
What the operator can still see: In the design, the API server still decrypts customer data. Anthropic relies on its compute providers for physical and hypervisor security. [30]
Status: Research report, 18 June 2025. Anthropic said it was too soon to forecast product features. It says it’s exploring models in which other parties run independent keyservers. [30]
Zama Concrete ML, FHE (Not applicable)
Who verifies: Not applicable. The protection is cryptographic.
How privacy works: Hybrid FHE computes on data while it stays encrypted. The server runs linear layers on encrypted data, and the client runs attention and activation functions locally. [51]
What the operator can still see: The server sees ciphertext. A GPT-2 model exchanges about 2.2 MB of data per token. [51]
Status: A library with a GPT-2 example. No hosted LLM service found. [51]
zkML: Lagrange DeepProve, EZKL (Not applicable)
Who verifies: Not applicable. Anyone with the proof can check the computation. The proof shows what ran, not who saw the input. [53]
How privacy works: Zero-knowledge proofs that a stated model produced an output. [52] [53]
What the operator can still see: The prover runs the model on the inputs, so it holds them. [54] [53]
Status: Developer tools. Proofs can hide inputs from the verifier. [53] We found no LLM product that hides them from whoever runs the model. [52]
The memory-bus attacks in more detail
TEE.fail. The interposer is a board between a memory module and its slot. The team hand-built it from secondhand parts and fitted it under a DDR5 module in a 5th-generation Xeon server. From the encrypted traffic they recovered the machine’s Provisioning Certification Key, which signs its attestation keys. With it they signed attestation keys of their own. The attack needs physical access and root. It also pulled an application’s signing key out of a virtual machine protected by AMD SEV-SNP, with ciphertext hiding switched on. [1]
The papers and teams. A version of the TEE.fail paper, retitled “Transparent Domain eXtensions”, appeared at IEEE S&P 2026. [64] WireTap came from an overlapping Georgia Tech and Purdue team. [13] Battering RAM came from a KU Leuven-led team. [14]
Intel’s other statements. An earlier Intel statement says WireTap and Battering RAM can reach SGX-protected secrets, including attestation keys. Intel’s memory encryption gives limited confidentiality and no integrity or anti-replay protection against physical attackers. So Intel plans no CVE. It names TME-MK integrity mode as a partial mitigation for aliasing attacks. [18] On DDRop, Intel is evaluating hardening and detection. That work includes Platform Owner Endorsements, still in development and meant to let remote parties learn who physically holds the hardware. [19]
Stolen keys have undone trust before. None of this is new in kind. In 2018 Foreshadow used speculative execution to pull the attestation keys of Intel’s quoting enclave out of SGX. Its authors then passed off code running outside SGX as a genuine enclave. [20]
Outside enclaves, the US Cyber Safety Review Board found that in the Storm-0558 intrusion, a Microsoft consumer signing key created in 2016 and a token-validation flaw let the intruder forge tokens. Those tokens opened the mailboxes of 22 organizations and more than 500 individuals. When the board reported, Microsoft still didn’t know how or when the key was taken. [21]
One result outside the scorecard’s question
In a USENIX Security paper, an attacker in one partition of a split H100 could tell which of 20 LLMs ran in another, with 94.28 percent macro-F1. The victim served a fixed batch size. Confidential computing was off because NVIDIA hadn’t released a driver for it. [16]
The open question
Can attestation checks run on the user’s own device, fail closed before a prompt leaves, and still work with the models people want to use?
A dated scorecard of 17 private-inference offerings, each cell sourced to the provider’s own documentation or an independent audit, as of 3 November 2026. The follow-up we propose, a test of whether published client verifiers refuse stale, replayed or altered evidence, is on our page of proposed studies.
References
A selected review of published sources, with Lugano’s analysis and proposed work identified in the text. Source dates and conditions matter; historical results are not current-model rankings.
- 1
TEE.fail: Breaking Trusted Execution Environments via DDR5 Memory Bus Interposition
Authors’ preprint (October 2025), text read 3 November 2026; a version retitled “Transparent Domain eXtensions: Breaking Intel TEE Implementations via DDR5 Memory Bus Interposition” appeared at IEEE S&P 2026 (source 64). On a Xeon Silver 4509Y (5th generation) that Intel’s PCS rated UpToDate, a hand-built DDR5 interposer made from secondhand parts (under $1,000 in total) recovered the machine’s Provisioning Certification Key; quotes signed with it were fully verifiable by Intel’s DCAP Quote Verification Library. Section 8.3: a modified vllm-proxy from Phala Network’s and NEAR AI’s private ML SDK, run outside TDX on a machine with an NVIDIA 3060, passed TDX and NVIDIA CC attestation using a forged TDX quote and a genuine H100 attestation fetched on demand from a rented server, because NVIDIA does not bind the H100 to the identities of specific VMs. The same setup extracted OpenSSL ECDSA signing keys from a VM protected by AMD SEV-SNP with ciphertext hiding enabled.
Scope. Requires physical access and root on the host. All attacks ran on the authors’ own machines or on project testnets. The consequences for LLM hosts (covert logging, one H100 attesting for hundreds of instances) are the authors’ inference. We read the preprint, not the proceedings version.Back to the essay
- 2
TEE.fail project site
Researchers’ site for the paper, read 3 November 2026: its citation entry gives the venue as the 47th IEEE Symposium on Security and Privacy (S&P 2026); states that, as far as the authors know, the attack has not been exploited in the wild; that AMD, like Intel, considers interposer attacks out of scope for SEV-SNP; and that because TEE.fail does not directly attack NVIDIA’s confidential-computing elements, there are no mitigations on NVIDIA’s side.
Scope. The researchers’ summary of vendor positions. We have not read AMD’s own bulletin on TEE.fail (AMD-SB-3040), linked from the site, so AMD’s position here rests on the researchers’ account and on AMD’s SEV-SNP white paper (source 55), which states its general position.Back to the essay
- 3
Order affirming the 20-million-log production orders (MDL ECF 1021)
Court record of 5 January 2026, filed as a scanned document. Affirms Magistrate Judge Wang’s orders of 7 November and 5 December 2025 to produce a 20-million-log de-identified sample; notes that OpenAI has retained tens of billions of consumer logs in the ordinary course of its business; holds that the privacy interest in chats users voluntarily disclosed to OpenAI, which OpenAI retains in the normal course of its business, is weaker than in the wiretapped calls of SEC v. Rajaratnam.
Scope. A discovery ruling in copyright litigation; it does not decide the merits. Later filings were not reviewed.Back to the essay
- 4
NEAR AI Cloud documentation: model attestations
First-party: instances of the same model share one signing key, including instances with different measured configurations, so a matching signer does not establish that the report and the completion came from the same instance. Lists the checks to run before sending, including DCAP quote verification under the verifier’s own TCB policy, binding of a client nonce and signing address in the report data, event-log replay against RTMR3, and comparison of the configuration measurement.
Scope. Undated page.Back to the essay
- 5
Private Cloud Compute Security Guide (Release transparency, Release notes, No privileged runtime access, Request handling, Management, Google Cloud roots of trust)
First-party guide read 3 November 2026: requests are first handled by a proxy node, which re-wraps the device’s key to the worker node, and the device validates the node’s attestation before releasing that key; a device sends a request to a node only if its attested measurements appear in the public, append-only log; where a proxy node validates on the device’s behalf, it validates worker attestations transitively. Release notes list as a known issue that verification of a certificate’s inclusion in the log is not yet enforced, and call the first Google Cloud release in production, serving requests at the launch of the 27.0 operating systems. Only log lines and metrics Apple approves before a release, and redacted crash reports, leave a node; Apple says this can reduce but not eliminate the risk of leakage. Google Cloud nodes export allow-listed logs, metrics and distributed traces and do not currently collect crash reports. GPU firmware rests on NVIDIA’s root of trust alone.
Scope. Undated pages.Back to the essay
- 6
Meta WhatsApp Private Processing: Security Assessment with Fix Review
Independent assessment with fix review (final report 26 August 2025): the WhatsApp client refuses to connect to enclaves that show evidence of tampering; no indication that user data is available to Meta during server-side processing or retained after it; CVM images not yet fully reproducible from public sources (TOB-WAPI-18, partly resolved). Its recommendations include chain-of-custody documentation for enrolled CPUs, so Meta can verify they are in its custody and exclude CPUs that may have faced key-extraction attacks; a separate recommendation on physical protection of host servers notes that the SEV-SNP threat model does not defend against advanced physical attacks.
Scope. Commissioned by Meta; a point-in-time review.Back to the essay
- 7
Another Brave User-First AI Win: Leo adds End-to-end Encryption, Oblivious HTTP, and Verifiable Confidential Computing
First-party post of 15 October 2026: GLM 5.3 Flash in Intel TDX with NVIDIA confidential computing, operated by NEAR AI; the browser encrypts each prompt with Oblivious HTTP to NEAR AI’s gateway TEE, which passes it to the model TEE; Brave sees the IP but not the message; Brave’s open-source gateway checks the TEE’s live attestation before releasing the key or relaying, using a verification no more than an hour old, and the browser relies on it for that check today; the runtime is pinned by a deployment log because it is not rebuilt from source; attesting the exact weights loaded is future work; attestation checks to move into the browser.
Scope. Operator’s description; the model is in beta.Back to the essay
- 8
Private Safety Processing Overview (whitepaper)
First-party whitepaper of 26 October 2026: content referred by a safety classifier or an approved sampling policy is HPKE-encrypted into customer storage kept at least 30 days and decrypted only inside an attested review runtime; a cloud key vault’s Secure Key Release gives the runtime OpenAI’s keys only when attestation evidence meets a release policy; the storage-disabled inference path does not provide an inference-wide Zero Operator Access guarantee; bounded safety signals and operational metadata are visible to staff in plaintext; authorized auditors can inspect approved configurations. Describes Private Inference as optional and not automatically covering the initial API request.
Scope. Operator’s description; does not name the TEE vendor or say whether the auditor log is public.Back to the essay
- 9
Private AI Compute in the Cloud: Assessment Overview
Independent assessment (v1.4, 8 November 2025). Describes a design in which the public half of the server key is meant to be hardcoded in the client code or its configuration, and a central Google service (Borg Prime) delivers a token only after validating the frontend server’s remote attestation. Concludes that user data is protected unless Google, as a whole organization, decides otherwise.
Scope. Commissioned by Google; excluded the AMD SEV-SNP platform and the phone apps.Back to the essay
- 10
Google Private AI Compute, Secure Server-Side Memory: Security Assessment
Independent assessment (final report 21 September 2026; review June to July 2026) of the server-side memory addition: the Android client verifies the enclave’s remote attestation before any key material is sent. Finding TOB-PAICSM-9 (high severity, high difficulty, unresolved): deterministic hashes of LLM response substrings are exposed to non-confidential services; exploitation would require privileged internal access.
Scope. Commissioned by Google; scoped to the memory addition and related client and connection logic.Back to the essay
- 11
Google Private AI Compute: Enabled with Secure Server-Side Memory (technical brief)
First-party brief dated September 2026 (PDF created 24 September 2026; read 3 November 2026): AMD SEV-SNP for CPU workloads, a hardened TPU platform, Noise channels, IP-blinding relays run by third parties, and a tamper-evident public ledger of production binaries. Page 13 says server instances are provisioned with a cryptographic key only after hardware and software attestation, and clients verify this key before transmitting data; page 5 describes the client establishing mutual attestation of auditable binaries over its Noise connection. Its next steps (page 14) include client-side attestation verification, moving from Google-asserted compliance toward devices that validate server evidence before sending.
Scope. Operator’s description.Back to the essay
- 12
Venice documentation: TEE and E2EE models
First-party: TEE models run on Intel TDX and NVIDIA confidential computing; a TEE-only request reaches the Venice API as plaintext; the attestation response’s verified field reflects server-side verification and developers are told not to rely on it alone but to parse the quote client-side; under E2EE only user and system messages are encrypted and tool definitions are not; E2EE requires client-side implementation. The documented E2EE flow has the client generate an ephemeral secp256k1 key pair, fetch /api/v1/tee/attestation with its own 32-byte nonce, check the nonce match, debug mode and attestation validity, and encrypt user and system messages to the model’s public key (ECDH, HKDF-SHA256, AES-256-GCM) before sending; the reference code checks the server’s verified flag and the nonce, and the best-practice notes say to parse the Intel TDX quote and check the NVIDIA attestation client-side in production.
Scope. Undated page.Back to the essay
- 13
WireTap: Breaking Server SGX via DRAM Bus Interposition
First-party research site (ACM CCS 2025): on 3rd-generation Xeon Scalable servers with DDR4 memory, extracted the ECDSA attestation key of Intel SGX’s quoting enclave from a machine in fully trusted status; the authors say the project should cost under $1,000, including the logic analyzer.
Scope. Studies SGX on DDR4 systems only; testnet case studies.Back to the essay
- 14
Battering RAM: Low-Cost Interposer Attacks on Confidential Computing via Dynamic Memory Aliasing
First-party research site (IEEE S&P 2026; embargo lifted 30 September 2025): a custom DDR4 interposer that can be built for less than $50 (bill of materials $47.62) gave arbitrary plaintext read and write access to Scalable SGX and broke SEV-SNP attestation on fully patched systems by capturing and replaying launch measurements. Reports that Intel and AMD called physical DRAM attacks out of scope for their current products.
Scope. DDR4 only; physical access required. We have not read AMD’s bulletin linked from the site (AMD-SB-3024), so AMD’s position is as the researchers report it. The site contrasts its cost with commercial interposers that need analyzers typically retailing above $150,000.Back to the essay
- 15
DDRop: Active Memory Interposer Attacks on Confidential VMs by Dropping DDR5 Writes
First-party research site (ACM CCS 2026; coordinated disclosure 14 September 2026): an active DDR5 interposer with a bill of materials of about $159 per unit (build quantity of ten) drops memory writes; on Intel TDX a rogue VM overwrites its launch measurement with that of a legitimate workload and passes remote attestation; on AMD SEV-SNP the site reports interference with victim memory.
Scope. Physical access required. We have not read AMD’s advisory linked from the site (AMD-SB-3048) or the full paper, only the project site.Back to the essay
- 16
Behind Bars: A Side-Channel Attack on NVIDIA MIG Cache Partitioning Using Memory Barriers
Peer-reviewed (USENIX Security 2026); paper read 3 November 2026. On one H100 PCIe split by MIG, an attacker in one instance fingerprinted 20 LLMs running in another with 94.28% macro-F1 and distinguished output lengths at single-token granularity with 97.4% accuracy (GPT-Neo 1.3B, batch size of one).
Scope. The authors could not test MIG with confidential computing enabled because NVIDIA had not released that driver; the attack assumes one request at a time.Back to the essay
- 17
Intel Security Announcement 2025-10-28-001
Vendor statement of 28 October 2025: the TEE.fail research does not change Intel's earlier out-of-scope position on physical attacks.
Scope. Vendor position; lists no mitigation.Back to the essay
- 18
More Information on Encrypted Memory Frameworks for Intel Confidential Computing
Vendor statement (updated 27 October 2025): interposer attacks are outside the scope of the boundary of protection of AES-XTS memory encryption; the WireTap and Battering RAM methods can attack SGX-protected assets, including SGX attestation keys; because the encryption gives no integrity or anti-replay protection against physical attackers, Intel does not plan to issue a CVE.
Scope. Vendor position; names TME-MK integrity mode as a partial mitigation for aliasing attacks.Back to the essay
- 19
DDRop: Physical Memory Interposer Research (Intel security announcement)
Vendor statement, revision 1.0, 14 September 2026: the described scenarios fall outside Intel’s standard threat model for confidential computing; Intel is evaluating additional architectural hardening and detection mechanisms, including the development of Platform Owner Endorsements, which are meant to let remote parties establish who physically holds the hardware.
Scope. Vendor position. The URL carries the ID 2026-08-11-001, while the page’s Announcement ID field reads 2026-09-14-001.Back to the essay
- 20
Foreshadow: Extracting the Keys to the Intel SGX Kingdom with Transient Out-of-Order Execution
First-party research site (USENIX Security 2018): Foreshadow, a speculative-execution attack, read SGX enclave memory and extracted the attestation keys used by Intel’s quoting enclave, then convinced a remote party that a genuine enclave was running while the code ran outside SGX under the attackers’ control.
Scope. Historical attack mitigated by microcode and software updates.Back to the essay
- 21
Review of the Summer 2023 Microsoft Exchange Online Intrusion
Independent public review (March 2024): Storm-0558 compromised the Exchange Online mailboxes of 22 organizations and over 500 individuals using authentication tokens signed by a key Microsoft created in 2016; as of the report, Microsoft did not know how or when the key was obtained.
Scope. A review of one intrusion; used here as an analogy about trusted signing keys, not as evidence about TEEs.Back to the essay
- 22
Private Cloud Compute: A new frontier for AI privacy in the cloud
First-party description of 10 June 2024: Apple-silicon servers with Secure Enclave and secure boot, a third-party OHTTP relay, and devices that send requests only to attested nodes.
Scope. Design statement by the operator.Back to the essay
- 23
Expanding Private Cloud Compute
First-party post of 8 June 2026: PCC nodes on Google Cloud with NVIDIA confidential computing, Intel TDX and Google’s Titan chip, with attestation rooted in at least two separate roots of trust from independent vendors for components that could be abused to exfiltrate user data (Apple’s guide says GPU firmware rests on NVIDIA’s root alone); protections ramping through a summer preview.
Scope. Operator’s description; Apple named no external audit of the Google Cloud nodes.Back to the essay
- 24
Private AI Compute: our next step in building private and helpful AI
First-party announcement of 11 November 2025: Gemini on TPUs inside Titanium Intelligence Enclaves; first used for Magic Cue and the Recorder app on Pixel.
Scope. Announcement; technical detail is in the brief.Back to the essay
- 25
Private Processing technical whitepaper (V3)
First-party whitepaper (V3, 20 October 2026): confidential VMs on AMD SEV-SNP with NVIDIA Hopper GPUs; OHTTP through a third-party relay that hides the requester’s IP, then RA-TLS from the device to the TEE; the client verifies the orchestrator, which verifies backend TEEs; only allowlisted logs and metrics leave the CVM; optional web search sends queries of up to 100 characters to Meta in plaintext outside the TEE; the transparency log is a simple log kept by a third party, not a Merkle tree.
Scope. Operator’s description.Back to the essay
- 26
Catch up on conversations with Private Message Summaries
First-party announcement of 25 June 2025 (last updated 13 October 2025) introducing Message Summaries, which uses Private Processing, rolling out in select markets.
Scope. Product announcement.Back to the essay
- 27
Data controls in the OpenAI platform
First-party documentation read 3 November 2026: API abuse-monitoring logs retained up to 30 days by default; Zero Data Retention needs prior approval; some state persists under ZDR, such as encrypted prompt-cache tensors up to 24 hours and images flagged for possible CSAM review.
Scope. Undated page.Back to the essay
- 28
DevDay 2026 Recap
First-party recap dated 29 September 2026: introduces OpenAI Private Intelligence, including Zero Data Retention with Private Safety Processing and a preview of Private Inference, coming this fall, that combines confidential computing with strict, verifiable controls.
Scope. Announcement; names no hardware and does not say who verifies attestation. Read 3 November 2026.Back to the essay
- 29
Private Intelligence
First-party product page read 3 November 2026: lists Private Inference (preview), which combines confidential computing with strict controls designed to protect prompts and responses while the model processes them, and Zero Data Retention for eligible API workflows.
Scope. Undated product page; names no hardware or verifier.Back to the essay
- 30
Confidential Inference via Trusted Virtual Machines
First-party research of 18 June 2025, with Pattern Labs: a small trusted loader in a separate isolated VM; a keyserver that releases decryption keys only after the recipient proves itself through attestation; the API server still decrypts and re-encrypts requests and its security is beyond the scope of the post; Anthropic relies on its compute providers for physical datacenter and hypervisor security; Anthropic is exploring independent keyservers run by other parties; too soon to forecast product features.
Scope. Research sketch, not a product.Back to the essay
- 31
Privatemode documentation: server-side architecture
First-party (v1.61): all workloads run in confidential VMs based on AMD SEV-SNP or Intel TDX; the API uses NVIDIA H100 and B200 accelerators; encryption keys are released only to verified GenAI workers after successful attestation.
Scope. Undated page.Back to the essay
- 32
Privatemode documentation: trust and compliance
First-party (v1.61): metadata including IP address, timestamp, API key and token usage stored up to 90 days; token usage per API key stored permanently for billing; the model name and an estimated token count stay in plaintext headers; the SDK and proxy verify the backend before sending, while the proxyless API verifies on the user’s behalf.
Scope. Undated page.Back to the essay
- 33
Privatemode documentation: proxyless API
First-party (v1.61): in the proxyless API, TLS terminates inside a proxy operated by Edgeless Systems in a confidential computing environment, where the request is plaintext; it provides memory encryption but no client-side remote attestation, and users trust the zero-retention policy without technical enforcement.
Scope. Undated page.Back to the essay
- 34
Privatemode documentation: API quickstart
First-party quickstart (v1.61): users connect through the SDK or the Privatemode proxy; the SDK verifies the deployment before the first request; the proxyless API is offered for evaluation, with memory encryption but no client-side attestation.
Scope. Undated page.Back to the essay
- 35
Privatemode documentation: attestation overview
First-party documentation (v1.61): before any data is processed or key exchanged, the client-side proxy (and the SDK, by the same steps) verifies the Contrast coordinator’s evidence against AMD or Intel roots; the coordinator verifies workloads against the manifest and certifies only those that pass.
Scope. Undated page; the manifest is fetched by default from an Edgeless file service unless the user pins their own. The old URL (/architecture/attestation/overview) now redirects here.Back to the essay
- 36
NEAR AI Cloud documentation: private inference and verification
First-party documentation: Intel TDX CVMs with eight NVIDIA H200 GPUs per node; gateway mode routes through cloud-api.near.ai, which runs in its own TEE before forwarding to the model TEE; optional end-to-end encryption.
Scope. Undated pages. NEAR says no party, NEAR included, can access data; that is the operator’s claim.Back to the essay
- 37
NEAR AI Cloud documentation: quickstart
First-party quickstart read 3 November 2026: the first examples call https://cloud-api.near.ai/v1 with curl and with the OpenAI Python SDK pointed at that base URL; the page does not mention an attestation check and points to a separate verification page.
Scope. Undated page.Back to the essay
- 38
NEAR AI Cloud documentation: inference SDK
First-party: NEAR AI Inference SDKs for JavaScript, Python, Rust and Go provide an OpenAI-compatible client with attestation verification; the clients verify gateway evidence before sending chat requests and model evidence where supported; end-to-end encryption is off by default.
Scope. Undated page; still shows version 0.1 install lines, while npm and PyPI list 0.2.1 (29 October 2026, source 60).Back to the essay
- 39
OpenSecret technicals
First-party post of 6 February 2025: authentication, key management and encryption run in an AWS Nitro Enclave built reproducibly with Nix; the client verifies the enclave attestation before login or data upload; the enclave re-encrypts data for a GPU TEE, with Edgeless Systems named as the NVIDIA TEE provider.
Scope. Architecture as of February 2025. Maple’s current pages (sources 56 and 57) describe the same client check and say Maple’s enclave verifies the model’s enclave.Back to the essay
- 40
Lumo security model
First-party post of 4 August 2025: the device generates a per-request AES key encrypted to the LLM server’s public PGP key; the server sees the decrypted message; Proton says the request is not logged or retained by the server after it completes; stored chats use zero-access encryption; no TEE or attestation is described.
Scope. Operator's description.Back to the essay
- 41
Phala Cloud confidential AI documentation: verify attestation
First-party: the gateway’s TEE technology is currently TDX; applications should verify it with connectAci() from the ACI SDK, and agent tools with Private AI Proxy, both of which handle TLS binding.
Scope. Undated page; the ACI SDK verifies the quote but does not check whether the dstack OS image is a production build.Back to the essay
- 42
Phala Cloud confidential AI documentation: trust boundary
First-party: plaintext is processed in the gateway TEE, where TLS terminates; ordinary clients do not verify the quote, pin TLS to the attested key or audit receipts.
Scope. Undated page; names no TEE technology (the verification page does).Back to the essay
- 43
RedPill documentation: verify a response
First-party: the client verifies that the measured compose ran in a genuine TDX workload; users verify RedPill’s gateway with connectAci() from Phala’s @phala/aci-verifier or with Private AI Proxy; a base URL alone does not verify the TEE.
Scope. Undated page.Back to the essay
- 44
Phala Cloud confidential AI documentation: providers
First-party: every model at Phala’s endpoint uses a TEE-only policy; the gateway requires upstream verification and an enforceable channel binding before forwarding; for NEAR AI upstreams per-model verification is delegated to NEAR’s gateway; for Tinfoil it attests the confidential model router, not each worker; ordinary clients do not verify each response and should use the ACI verifier or Private AI Proxy for client-side checks.
Scope. Undated pages.Back to the essay
- 45
OpenRouter provider page: Phala
First-party listing: every model on the page is served by Phala through the OpenRouter API and API key.
Scope. Undated; says nothing about TEEs, attestation or whether OpenRouter can read prompts.Back to the essay
- 46
OpenRouter FAQ
First-party: OpenRouter is a proxy that sends requests to the model provider; it logs metadata such as timestamps, model and token counts and does not log prompts by default.
Scope. We found no OpenRouter statement that it cannot read prompts routed to TEE providers.Back to the essay
- 47
nilAI documentation: private LLMs overview
First-party: all processing in a TEE built on NVIDIA confidential computing, hidden from the cloud provider; an attestation API; a cryptographic signature on every response; API keys from a developer portal.
Scope. Undated page; does not say whether the SDK verifies before sending, what Nillion as operator can see, or the release status.Back to the essay
- 48
Tinfoil documentation: attestation architecture
First-party: hardware quotes from AMD SEV-SNP or Intel TDX are verified against the vendor’s certificate chain; at boot each NVIDIA GPU is checked with NVIDIA’s nvattest tool to confirm confidential-computing mode; neither the host nor the router can read plaintext outside a verified enclave.
Scope. Undated page; the provider’s description.Back to the essay
- 49
Tinfoil documentation: verification in Tinfoil
First-party: before sending any data, the SDK compares Sigstore-provided measurements with the enclave attestation, whose report covers the TLS and HPKE public keys, and stops all connections on a mismatch; the router enclave reads requests to route them and verifies every model and tool enclave before forwarding; V3 attestation is in beta.
Scope. Undated page; V3 attestation in beta.Back to the essay
- 50
Tinfoil documentation: quickstart
First-party quickstart read 3 November 2026: the first example uses the Tinfoil SDK client; SDK and proxy connections get connection-time verification; a direct connection to the OpenAI-compatible endpoint skips connection-time verification and is covered only by audit-time verification; Tinfoil recommends the SDK or proxy where possible.
Scope. Undated page.Back to the essay
- 51
Concrete ML documentation: LLM inference
First-party documentation: hybrid FHE in which the client executes non-linear layers such as attention and activation functions and the server executes linear layers on encrypted data; a GPT-2 model exchanges about 2.2 MB of data per token (about 18 MB for Llama 3.2 1B).
Scope. Undated page read 3 November 2026; the only code example is GPT-2, and no hosted service is described.Back to the essay
- 52
DeepProve README
First-party: a zero-knowledge proof system for neural-network inference with end-to-end LLM proving; a 512-token GPT-2 run proved in 7.6 minutes on a 24-core CPU server.
Scope. Undated repository page; says nothing about input privacy.Back to the essay
- 53
EZKL README
First-party: frames use as proving that a publicly available network was run on private data (or a private network on public data); proofs can be verified on-chain, in a browser or on a device.
Scope. Undated repository page; a developer library, not an LLM private-inference product.Back to the essay
- 54
zkLLM: Zero Knowledge Proofs for Large Language Models
Peer-reviewed (ACM CCS 2024): the prover (such as an AI company) owns the model and gives a verifier API access; the verifier submits a prompt and requests a proof. Proved LLaMA-2-13B inference at sequence length 2,048 in about 803 seconds on one A100.
Scope. The paper does not state in one sentence that the prover sees the prompt; that follows from its setting.Back to the essay
- 55
AMD SEV-SNP: Strengthening VM Isolation with Integrity Protection and More (white paper 70366)
Vendor white paper of January 2020, read 3 November 2026 from AMD’s documentation portal: SEV-SNP can block some physical attacks, such as cold-boot analysis of DRAM, but on-line DRAM integrity attacks, such as attacking the DDR bus while the VM is running, are out of scope; the threat-model table lists manipulating the DDR bus while a VM runs under physical access attacks.
Scope. Predates TEE.fail, Battering RAM and DDRop, and speaks of integrity attacks, not passive snooping. We have not read AMD’s bulletins on those attacks (AMD-SB-3024, AMD-SB-3040, AMD-SB-3048).Back to the essay
- 56
How Maple Works: Private AI You Can Check
First-party page read 3 November 2026: before sending anything, the app checks a fresh nonce, the certificate chain to Amazon’s Nitro root, the document signature and an approved PCR0 fingerprint, and if any check fails no session is created and nothing is sent; Maple’s enclave verifies the model’s attested enclave before forwarding a prompt, and the user does not attest it directly; a fingerprint match shows Maple approved the software, not that it was built from public source; Maple has not yet been audited.
Scope. Undated page; the operator’s description.Back to the essay
- 57
Maple monorepo: OpenSecret provider registry (services/opensecret/src/provider_registry.rs)
First-party open-source backend code at the linked commit, where this file was last changed on 3 November 2026 (UTC): the two inference providers are Tinfoil and Continuum, which the code comments identify as Privatemode; the service README says Tinfoil runs in-process through Tinfoil’s attested SDK.
Scope. Source code on the main branch, read but not run; routing weights can change.Back to the essay
- 58
NEAR AI Cloud documentation: available models
First-party: the catalog labels models with three privacy tiers; Incognito models (OpenAI, Anthropic, Gemini and others) pass through NEAR’s TEE gateway but run on the provider’s infrastructure outside a TEE, so TEE guarantees do not extend upstream.
Scope. Undated page.Back to the essay
- 59
NEAR AI Cloud documentation: verification
First-party: a browser Verification Center at cloud.near.ai/verify, an example verifier and a fuller NEAR AI Cloud Verifier on GitHub.
Scope. Undated page.Back to the essay
- 60
NEAR AI Inference SDK (README and v0.2.1 release)
First-party repository read 3 November 2026: the SDKs verify gateway evidence, and model evidence where supported, before inference, and required verification failures stop the request; E2EE and OHTTP are optional and off by default. npm and PyPI list version 0.2.1, published 29 October 2026.
Scope. Operator’s description; we did not run the SDKs.Back to the essay
- 61
Venice Launches End-to-End Encrypted AI
First-party post of 18 March 2026: TEE and E2EE models are operated by two external partners, NEAR AI Cloud and Phala Network; in TEE mode data still passes through Venice’s proxy and users still trust Venice not to retain it in transit; in the app, an E2EE response shows a verification icon that opens the attestation report.
Scope. Operator’s description; it does not say whether the app checks attestation before it sends a prompt.Back to the essay
- 62
n8n-nodes-nilai
First-party n8n node (npm 0.1.6, 22 July 2026), read 3 November 2026: by default it verifies the enclave’s AMD SEV-SNP report against AMD’s certificate chain and a known-good measurement once, before the request loop; on failure it records attestation_verified false and still sends the prompt; it surfaces but does not live-check the TLS binding; the README says the operator, including Nillion, cannot see prompts or output.
Scope. An optional integration, not the documented quickstart; code read, not run.Back to the essay
- 63
nilAI documentation: quickstart
First-party quickstart read 3 November 2026: the example route sends messages to the nilAI chat-completions endpoint with an API key and returns the response and signature; it describes no attestation check.
Scope. Undated page.Back to the essay
- 64
IEEE Symposium on Security and Privacy 2026: Accepted Papers
Lists “Transparent Domain eXtensions: Breaking Intel TEE Implementations via DDR5 Memory Bus Interposition” by the six TEE.fail authors, and Battering RAM by its four authors.
Scope. Titles and authors only; we did not read the proceedings version.Back to the essay
- 65
Phala Cloud confidential AI documentation: on-demand API
First-party quickstart read 3 November 2026: the first examples use the standard OpenAI SDK pointed at Phala’s gateway; ordinary SDK clients and cURL do not verify the gateway or each response, and Phala points to its TypeScript ACI verifier or Private AI Proxy for client-side checks.
Scope. Undated page.Back to the essay
- 66
CSAM Screening Across OpenRouter
First-party announcement dated 27 October 2026: OpenRouter will screen all inference requests in flight for child sexual abuse material, including traffic under its Zero Data Retention policy, and may retain flagged content for human review.
Scope. Written in the future tense; says nothing about TEE providers.Back to the essay
- 67
Introducing Lumo 2.0
First-party post of 30 June 2026: Lumo was rebuilt on a new architecture, runs on Proton’s European infrastructure with zero-access encryption, and has more than 10 million users.
Scope. Product post; describes no change to the security model.Back to the essay
- 68
Lumo privacy
First-party support page read 3 November 2026: Lumo’s models run only on servers Proton controls; questions travel to those servers over TLS and are erased after the response; no enclave or attestation is described.
Scope. Undated page.Back to the essay