ᛊ  Sealed inference · threat model

How private is "private"?

When you add -TEE to a model, your request runs in a sealed hardware enclave. Here is exactly what that protects, what it doesn't, and how you can check for yourself — no marketing words.

What a TEE actually is

A Trusted Execution Environment (TEE) is a hardware-isolated region of a CPU and GPU — Intel TDX plus NVIDIA Confidential Computing on H100/H200-class hardware. Code and data inside it are encrypted in memory and shielded from the host operating system, the hypervisor, and the operator running the machine. Your prompt is decrypted only inside that sealed boundary, processed, and the result handed back — without the host being able to casually read it in between. On modern GPUs this runs large models at a single-digit-percent performance cost, which is why it's the one privacy technology viable for real-time, frontier-scale inference today.

What it protects — and what it doesn't

ᛊ It defends against

  • A curious or compromised node operator reading your prompts
  • The host OS, hypervisor, and other tenants on the machine
  • Casual logging or retention of your prompt/response content
  • Tampering with the model or code — attestation would catch it

⚠ It does NOT defend against

  • A well-resourced attacker with physical access to the machine
  • Hardware side-channels (e.g. the 2025 TEE.Fail DDR5-interposer attack on attestation keys)
  • You having to trust Intel and NVIDIA's silicon and firmware roots
  • Bugs in the enclave's own code (attestation proves what ran, not that it's flawless)
This is why we never say "trustless," "provable," "verifiable," or "the host cannot see this." Those are overclaims. The honest, defensible statement is narrower and still worth a great deal: your prompt runs in a sealed enclave the operator can't casually read, and you can verify the exact code and hardware that ran it.

How you verify it (attestation)

You don't have to take our word that a request ran in a genuine enclave. The hardware produces a signed attestation quote — a cryptographic statement of which code, model, and hardware booted inside the TEE. A client can check that quote against reference measurements before trusting the endpoint with anything sensitive. Attestation proves the environment is genuine and the code is what was published; it does not, by itself, prove the code is bug-free or that no exotic physical attack exists. We're building a per-request attestation surface so this check is one call, not a research project — and so you verify against an independent reference, not just our say-so.

Where TEE sits on the privacy spectrum

No single technology is "most private" for free — each trades capability, speed, or trust for confidentiality.

local / on-device  →  TEE (where OpenTau runs)  →  ZK  →  FHE
max trust,           the real-time       proves correctness,  max privacy,
least capability   sweet spot        not privacy      not yet real-time

Zero-knowledge ML proves a result is correct but doesn't hide your prompt from the prover, and can't keep pace with interactive token generation. Fully homomorphic encryption is the strongest — computing on data that's never decrypted — but remains orders of magnitude too slow for large language models. For running a frontier-scale model that returns a token in real time, a TEE is the honest sweet spot, and that's where OpenTau's -TEE models run.

Going private

Same API, one suffix. Add -TEE to the model id (or flip Privacy on in DeChat / the playground) and the request routes to a sealed enclave instead of an ordinary node.

Further reading — NVIDIA H100/H200 Confidential Computing; Intel TDX; the TEE.Fail attack (ACM CCS 2025); and the "Confidential Computing's Inconvenient Truth" critique of attestation independence. We cite the attacks against our own stack on purpose.
Read the bigger picture in our essay on decentralized AI, or try a sealed model →