Open any "private AI" landing page and you'll find the same sentence, dressed in slightly different words: we can't see your data. It's a wonderful promise. It's also, in the strong form most companies imply, not quite true — and the gap between what they say and what the hardware actually guarantees is where trust quietly goes to die.
We use these words too — OpenTau runs sealed models, and we tell you the operator can't read your prompt. So this essay is partly a confession and partly a standard. Because if "private" is going to mean anything, someone has to say exactly where the line is. Here is ours.
§ 01 — The promiseThe sentence everyone borrows
"End-to-end encrypted." "Zero-knowledge." "Verifiable privacy." "Even we can't access it." These phrases get applied to AI inference as if they were interchangeable, and as if they meant the strongest possible thing: that your prompt is mathematically, unconditionally hidden from everyone, forever, no matter what.
Almost none of them mean that. Most mean something narrower and genuinely valuable — that the company running the model has gone to real lengths to make casual access impossible. The trouble is that the marketing borrows the certainty of cryptography while the engineering ships the reality of hardware. And hardware has edges.
"We can't see your data" is a spectrum, not a fact. The only honest move is to tell you where on it you actually are.
§ 02 — The mechanismWhat a sealed enclave actually is
When OpenTau says a model is sealed, it means the inference runs inside a Trusted Execution Environment — a TEE. In practice that's a modern CPU and GPU (Intel TDX paired with NVIDIA's confidential-computing mode on H100/H200-class chips) carving out a hardware-isolated region of memory. Code and data inside that region are encrypted in RAM and walled off from the host operating system, the hypervisor, the other tenants on the machine, and the person who owns the server.
Your prompt arrives encrypted, is decrypted only inside that sealed boundary, runs through the model, and the answer is handed back — without the host ever holding a readable copy in between. On today's GPUs this costs a single-digit percentage of performance, which is the entire reason it's usable: it's the one privacy technology that can run a frontier-scale model and still return a token in real time.
That's the real, shippable thing. It's good. It's also the part everyone advertises. The rest of this essay is the part they don't.
§ 03 — The winsWhat it genuinely protects
Sealed inference is not security theatre. Against the threats that actually describe most people's risk, it works:
- A curious or careless operator. The person running the node cannot open your prompt and read it over coffee. This is the single most common real-world privacy failure, and the enclave closes it.
- The host stack and the neighbours. The operating system, the hypervisor, and other workloads sharing the hardware are all on the outside of the wall.
- Silent logging and retention. There's no readable stream to quietly tee off into a database, a training set, or a subpoena response.
- Tampering you'd never notice. If someone swapped the model or modified the code, attestation (next section) would catch it.
For a journalist drafting a sensitive story, a clinician asking a blunt question, a founder pasting in a contract, an engineer debugging proprietary code — this is the difference that matters. The realistic adversary is an operator with access and an incentive, and against that adversary the enclave holds.
§ 04 — The edgesWhat it does not protect
Here's the part the landing pages skip. A TEE is a very strong lock on a very real door. It is not a law of physics.
- A determined attacker with physical access. In 2025, researchers demonstrated TEE.Fail — using a roughly thousand-dollar DDR5 memory interposer to extract the keys underpinning attestation on production hardware. If someone can get hands on the physical machine and is willing to spend real effort, the guarantees weaken.
- Side channels. Timing, power, and memory-access patterns can leak information without ever "reading" the data directly. This is an active, ongoing arms race, not a solved problem.
- Trust in the silicon itself. The whole edifice rests on Intel and NVIDIA's chips and firmware doing what they claim. Attestation proves the enclave booted genuine hardware — it does not let you audit that hardware's deepest roots.
- Bugs in the enclave's own code. Attestation proves what ran. It cannot prove that what ran was flawless. A vulnerability inside the sealed code is still a vulnerability.
None of this makes sealed inference worthless — far from it. It makes it bounded. It defends superbly against the operator and the software; it is not an absolute shield against a well-resourced adversary with a screwdriver and a grudge. Anyone who tells you otherwise is either confused or selling.
§ 05 — The checkHow you verify it yourself
The best feature of sealed inference is the one almost nobody uses: you don't have to take the provider's word for any of this. The hardware can produce an attestation quote — a cryptographically signed statement of which code, which model, and which silicon actually booted inside the enclave. Before you send anything sensitive, a client can check that quote and confirm the endpoint is what it claims.
Two honest caveats keep even this from being magic. First, attestation proves the environment and the code identity — it doesn't prove the code is bug-free or that no exotic physical attack exists. Second, if the provider runs both the enclave and the service that checks the quote, you're still ultimately trusting the provider; the check only becomes meaningful when you can verify against an independent reference. The goal we're building toward is to expose the quote on every sealed request so this is one call, not a research project — and to verify against something that isn't just us.
§ 06 — The spectrumWhy a TEE, and not something stronger
If a TEE has edges, why not use the cryptographically perfect thing? Because for large language models, the perfect things don't run in time yet. Privacy techniques sit on a spectrum, and each trades something away.
Running it locally on your own device is the most private option of all — nothing leaves — but you're limited to small models. Zero-knowledge ML can prove an answer was computed correctly, but it doesn't hide your prompt from the prover and can't keep pace with interactive generation. Fully homomorphic encryption is the dream — computing on data that's never decrypted — and remains orders of magnitude too slow for anything LLM-sized. For a real model answering you right now, a TEE is the honest middle: strong protection, real-time speed, edges you can name.
§ 07 — The standardWhy we'd rather under-promise
It would be easier to write "your data is completely private, guaranteed" and move on. Every competitor does. We don't, for a reason that's strategic as much as ethical: in privacy, the overclaim is a time bomb. The moment one skeptical researcher demonstrates the edge you papered over, every other claim you made dies with it. Honesty isn't the cost of doing this; it's the moat.
So here is the standard we hold ourselves to, and the one you should hold any "private AI" to: tell me what you defend against, tell me what you don't, and let me check. Sealed inference on OpenTau defends against the operator, the host, the neighbours, and the silent log. It does not defend against a state-level adversary with physical possession of the machine. And you can ask the hardware to prove the first part for itself.
That's a narrower promise than "we can't see your data." It's also one we can actually keep — which, when the subject is your most unguarded thoughts, is the only kind worth making.