Sign up

HOW VERIFICATION WORKS

Checked in your browser.
Sealed to the enclave.

What your browser checks, what our relay sees, and what you still trust us for.

Not independently assessed yet

  • Enclave checked first

    How we know

    Before your first message, Tinfoil’s open-source verifier checks the chip-signed report in your browser. A report that doesn’t verify stops everything.

    Read how

  • Sealed in your tab

    How we know

    Each request is encrypted with EHBP (HPKE, AES-256-GCM) to the key the attestation named, before it leaves.

    Read how

  • The relay sees bytes

    How we know

    Our relay checks your account and allowance and passes ciphertext to Tinfoil’s hosts. It sees sizes, times and your account, and keeps no copy.

    Read how

  • A receipt per answer

    How we know

    Your browser checks the enclave of the model that answered, where its hardware allows, and keeps what it found with the answer.

    Read how

Who could look, and what stops them.

  1. The network

    Residual risk: Low
    Gets
    Sealed bytes, sizes, times
    Stopped by
    HTTPS, then sealing to the enclave
    Still open
    Traffic sizes and timing

  2. Our relay

    Residual risk: Medium
    Gets
    Your account, IP, sizes, model
    Stopped by
    Sealed in your tab; it can’t open them
    Still open
    The metadata it sees

  3. The cloud host

    Residual risk: Medium
    Gets
    Encrypted enclave memory
    Stopped by
    AMD SEV-SNP or Intel TDX, attested
    Still open
    Hardware flaws; Tinfoil’s own statements

  4. A fake enclave

    Residual risk: Low
    Gets
    Nothing: your tab refuses it
    Stopped by
    Attestation, checked in your browser
    Still open
    Verified code isn’t reviewed code

  5. Changed site code

    Residual risk: Medium
    Gets
    What you type, before sealing
    Stopped by
    Build manifest, signature, your own rebuild
    Still open
    A page can’t fully vouch for itself

  6. The developer API

    Residual risk: High
    Gets
    Your request, in memory
    Stopped by
    No storage or logs, by our policy
    Still open
    You trust our gateway

INSIDE ONE SERVER

Where the enclave begins, and ends.

Scroll to take a GPU server apart: what sits inside the enclave boundary, and what stays outside it.

  1. Heat spreaderThe metal lid over the GPU’s chips.
  2. GPU dieWhere the model runs. Tinfoil’s documentation says its NVIDIA GPUs (H100, H200 and B200) run in confidential computing mode.
  3. High-bandwidth memoryHolds the model’s weights, and your request while it’s answered.
  4. Confidential virtual machineOn the server’s processor (AMD SEV-SNP or Intel TDX): Tinfoil’s router and the model’s server, in memory the host can’t read. Its chip signs the report your browser checks.
  5. The enclave boundaryWhat the hardware keeps the host out of, and what the attestation describes. Your request is opened only inside it.
  6. The hostThe board, its hypervisor and drivers, and whoever operates it: outside the boundary. It carries sealed bytes in and out.

An illustration of the kind of machine Tinfoil runs, not a picture of a particular one. Tinfoil’s signed release record names each enclave’s CPUs, memory and GPUs; the workspace’s Verified panel shows them.

Read the full textHide the full textAbout 12 minutes, six diagrams

In short

Undergrove runs open-weight models inside hardware enclaves operated by Tinfoil. Some of what that means your browser checks for itself; some of it is Tinfoil’s statement; and some of it rests on us. Here is which is which.

Your browser checks

  • That the enclave is genuine hardware running the code Tinfoil published.
  • That each request is sealed to that enclave’s key before it leaves your tab.
  • For each answer’s receipt, the enclave of the model that answered, where its hardware allows.

Tinfoil states

  • That it can’t access its enclaves, and that nothing in them persists between restarts.
  • That its supported GPUs run in confidential computing mode.

You trust us for

  • The code this site sends your browser, which you can compare with the build.
  • What the relay does with what it can see: sizes, times and your account.
  • The developer API’s gateway, which reads requests in memory.

None of this has been independently assessed yet.

01 · Attestation

The chip vouches for the code.

A hardware enclave is a part of a server that its own host can’t look into: the processor encrypts the enclave’s memory and keeps the host’s software out of it. On its own, that would only be a promise. What makes it checkable is attestation. When the enclave starts, the processor measures the code it loaded and signs a report of that measurement with a key the chip maker vouches for. The report also names the public key the enclave will decrypt with.

Before your first message, the workspace fetches that report for Tinfoil’s router enclave, through our server, and runs Tinfoil’s open-source verifier on it in your browser. Fetching it through us changes nothing: we can’t forge the chip’s signature, and a report that doesn’t verify stops everything.

Tinfoil’s enclaveHardware reportThe processor measures the code the enclave booted and signs a report of it, naming the enclave’s public key, with a key the chip maker vouches for.
GitHub and SigstorePublished releaseTinfoil builds its open-source code in public and records each release’s measurement in Sigstore’s public transparency log.
Your browserTinfoil’s open-source verifierChecks the report’s signature against the chip maker’s keys, checks the release’s signed build record, and compares the two measurements.

They match: requests are sealed to the key the report names.

Anything fails: nothing is sent, and the workspace says why.

Figure 1. Your browser compares two things it can check without trusting us: the chip’s signed report of the code running in the enclave, and the release Tinfoil published for that code. Only if they match does it seal anything.

The verifier’s checks, in order

  1. Find the release Tinfoil published for this code.
  2. Check the enclave’s hardware attestation report against the chip maker’s signing keys.
  3. Check the release’s signed build record (Sigstore, from GitHub).
  4. Compare: the code measured in the enclave must be exactly that release.
  5. Check that the encryption key is the one the enclave’s attestation names.

A verified report is reused for up to ten minutes, in this tab or another of this site’s tabs, and only if it’s the very same one, by its SHA-256. The workspace shows each check under Verified, and the architecture page shows the code that runs it.

02 · Sealing

Only the enclave can open it.

With the enclave verified, every live request is sealed in your tab before it leaves. Its body is encrypted with EHBP, Tinfoil’s protocol for encrypting HTTP bodies, to the key the attestation named. EHBP uses HPKE, a standard for encrypting to someone’s public key: your tab makes a fresh key pair for the request, combines it with the enclave’s key into a shared secret, and encrypts with AES-256-GCM.

The fresh public half travels beside the ciphertext, as the encapsulated key. Only the enclave’s private key, which never leaves the enclave, can turn it back into the secret. The answer comes back the same way, in sealed frames your tab opens as they stream.

Your tabA fresh key pair, per requestCombined with the enclave’s verified public key, it gives a secret no one else can work out.
Ciphertext + encapsulated key
Undergrove relayPasses it onHolds no key that opens it.
Same bytes
Tinfoil’s enclaveOpens itWith the private key that never leaves the enclave.
Figure 2. EHBP seals the body of each request with HPKE: X25519, HKDF-SHA256 and AES-256-GCM. The answer streams back sealed too, and opens only in your tab. Seal a message yourself and watch each step.

03 · The relay

Bytes it can’t read.

Sealed requests go to our relay, a function on Vercel, rather than straight to Tinfoil. It checks who’s asking and that they’re within their allowance, and puts Undergrove’s Tinfoil key on the request, so you don’t need an account with Tinfoil. It refuses anything that isn’t addressed to one of Tinfoil’s own hosts or doesn’t carry an encapsulated key.

It can’t count your words, so it estimates each request’s cost from the ciphertext’s size, erring high. It keeps no copy, and its logs hold route names, status codes and timings only.

On the outside: the relay sees

  • Your account, and your IP address (through Vercel, our host)
  • Each request’s size, time and path
  • Which model answered, from a header Tinfoil sets
  • Whether web search or images were used, as your browser declares, so they can be charged

Sealed inside: it can’t read

  • Your messages and files
  • The answers
  • Your instructions and memory notes
Figure 3. The relay refuses anything that isn’t sealed to one of Tinfoil’s own hosts, swaps in our Tinfoil key and passes the bytes on. It charges by size because it can’t count words. See one request as the relay saw it.

04 · Receipts

Two enclaves, and a receipt for each answer.

The router enclave your browser verified doesn’t run the model. It opens your request and passes it to the enclave where the model runs with its GPUs, which the router verifies itself, under its published code, and names in a response header.

Your browser then checks that named enclave too, with the same verifier, against the repository Tinfoil’s router pins for that model. What it found is kept with the answer as a receipt: the enclave, the code measured in it, the release it matched and the key the request was sealed to. A receipt is your browser’s own record, not signed by us or by Tinfoil; the attestation behind it is signed by AMD and GitHub, so anyone can check it again.

Enclave 1Tinfoil’s routerVerified before sending. Opens the request.
Enclave to enclave
Enclave 2The model and its GPUsNamed in the tinfoil-enclave header.
Checked again
Your browserThe answer’s receiptKept with the answer: the enclave, the code measured, the release and the key.
Verified
Genuine hardware, running a published release of the repository Tinfoil’s router pins for the model.
Not checked
Hardware the browser verifier can’t read yet: it reads AMD SEV-SNP reports, so an enclave on Intel TDX is recorded as not checked.
Unconfirmed
The check ran and a step failed, for instance an enclave already on a newer release than the one Tinfoil’s service pairs it with.
Figure 4. Tinfoil’s router verifies the model’s enclave itself, under its published code, and names it in a response header. Your browser checks that enclave again for the answer’s receipt. The header isn’t covered by the encryption, so this shows the named enclave is genuine, not that this request went there; that hop rests on the router’s published code.

05 · The developer API

A different path, said plainly.

Code that calls the developer API sends its request over HTTPS to our gateway, which reads it: to check it, apply limits and run tools. It reads it in memory and never stores or logs it. The gateway then does what your browser does in the workspace: it verifies the enclave with Tinfoil’s SDK and seals the request to it.

So on this path you trust us with the request while the gateway holds it. What you can still check is the enclave: each answer from Tinfoil’s route carries headers naming the attestation bundle the gateway verified, for you to verify again. The developer documentation shows how.

Workspace
Your browserVerifies, then seals
RelayCan’t read it
EnclaveOpens it
Developer API
Your serverSends over HTTPS
Our gatewayReads it in memory to check it; never stores or logs it
EnclaveVerified by the gateway first
Figure 5. Two paths to the same enclaves. In the workspace your browser seals; through the API our gateway does, after reading the request in memory to check it. Every API answer from Tinfoil’s enclaves names the attestation bundle the gateway verified, which GET /v1/attestation?sha256= returns for you to check again.

06 · This page

Checking the code that checks.

Everything above runs in code this site sends your browser, so that code matters too. Each build writes a manifest: the SHA-256 of every file the site serves, and the commit it was built from.

A page can’t fully vouch for itself: a check that runs in the page is only as honest as the page. The stronger check doesn’t involve us at all: rebuild the commit yourself in the pinned environment and compare the manifests.

The buildA manifestThe SHA-256 of every file the site serves, and the commit it came from.
Published with the site
Your browserHashes what it loadedAny file that differs is named.
Or, on your machine
AnyoneRebuilds the commitAnd compares the two manifests.
Figure 6. Verify this page hashes the files your browser loaded and compares them with the manifest of the build and its commit. Rebuilding that commit in the pinned environment (npm run rebuild:site) should give the same manifest, byte for byte; anyone can run it and compare, without asking us.

07 · Limits

What this doesn’t prove.

  • Tinfoil’s statements stay Tinfoil’s. That it can’t access its enclaves, that nothing in them persists between restarts and that its GPUs run in confidential computing mode are what Tinfoil says. Your browser checks that the hardware is genuine and runs the published code.
  • The hardware is part of what you trust. The protection is as good as the processors, their firmware and the chip makers’ keys, and hardware enclaves have had published vulnerabilities before.
  • One hop rests on published code. That your request went from the router to the model’s enclave rests on the router’s published code. Your browser can check the model’s enclave on AMD SEV-SNP only; on Intel TDX it’s recorded as not checked.
  • The relay sees the outside. Your account, your IP address, sizes, times and which model answered.
  • Published isn’t the same as reviewed. The verifier shows which code runs, not that the code has no flaws.
  • No independent assessment yet. No auditor has reviewed this design or its code so far.

For who could see what, observer by observer, read the threat model.

08 · Go further

See each part working.