What an attestation proves, and what it doesn’t

“Encrypted to the enclave” is a short phrase for a chain of checks. Each link in it is worth knowing, because each one rests on something different: a processor vendor’s keys, a published release, a header, or code that we serve. This note walks the chain in order and marks where it ends.

The check, in order

Before the workspace sends a message, your browser fetches the enclave’s attestation bundle through our relay and verifies it with Tinfoil’s verifier, in the tab. The bundle holds a hardware report signed with keys rooted in the processor’s vendor (AMD SEV-SNP for the router), a measurement of the code the enclave booted, and the public key the enclave will decrypt with.

• The report’s signature shows it came from genuine enclave hardware.
• The measurement is compared with a signed, published release of the router’s code, so the browser knows which code is running.
• The key in the report is the one your message is then encrypted to, with HPKE, before it leaves the tab.

The relay caches that public bundle for a minute. Because the browser verifies it, passing it through our server can’t weaken it: a changed bundle fails the check, and nothing is sent.

What a passed check shows

That an enclave at that address is real hardware running that published release, and that it holds the key your message was sealed to. Your message can be opened only inside that code, for as long as the hardware’s protections hold. Our relay, our host and the network between see ciphertext.

Where it stops

The enclave your browser verifies is Tinfoil’s model router. Its published code decrypts your request and passes it to the model’s own enclave, over a TLS connection bound to that enclave’s attested key. Your browser can’t confirm that hop itself; it rests on the router’s published code.

The workspace does try to check the model’s enclave too, and says on each answer’s receipt what it found. Today that check often can’t finish in a browser. Tinfoil’s browser verifier reads AMD SEV-SNP reports only, and Kimi K3, GPT-OSS 120B, DeepSeek V4.1 Flash and most Gemma 4 31B enclaves run on Intel TDX, so their receipts say they can’t be checked in a browser yet. Some SEV-SNP enclaves, GLM-5.3’s among them, report a processor version the verifier doesn’t accept yet, and show as not confirmed. Neither means the enclave is wrong; it means the browser couldn’t show it was right. These findings are from 28 October 2026.

Two things a check can’t cover

• The verifying code comes from us. If we served a verifier that lied, the check would pass. That’s why /verify compares the code your browser loaded with the build’s published manifest, and why the build can be repeated byte for byte.
• Attestation rests on the vendor’s signing keys and on the enclave hardware working as designed. It can’t tell you about a flaw in either.

Check it yourself

How verification works draws the whole chain. Seal it yourself runs the sealing step in your browser with nothing sent. Verify this page hashes the code you loaded, and Try to break it publishes one encrypted request as our relay saw it.