PRIVACY
Where your data goes.
What stays in your browser, what gets sent, and what gets saved.
The path
One message, and who can read it
Your words are plain text only in your own browser tab.
Before anything leaves, the browser verifies the enclave and encrypts the request to its key.
Our relay checks your account and allowance, then forwards bytes it can’t open.
Inside the verified enclave the request is decrypted, and the model reads it and answers.
The answer returns encrypted through the relay, and your browser decrypts it.
Who sees what
Three parties, five kinds of data
| UndergroveRelay and servers | TinfoilThe model’s enclave | VercelOur host | |
|---|---|---|---|
| Workspace messages | Your browser encrypts each message to the verified enclave; our relay passes on bytes it can’t open. | Decrypted only inside the enclave your browser checked, to answer it. | Workspace requests pass through Vercel encrypted. |
| Developer API requests | Our gateway reads API requests in memory to check them, and doesn’t keep or log them. | Sealed to the enclave by the gateway after it verifies it. | The gateway that reads API requests runs on Vercel. |
| Files you attach | Text files are read in your browser; other kinds are encrypted to an enclave and turned into text there. | PDFs, Office files and audio are turned into text inside an enclave. | Ciphertext |
| Sync and shared links | We store encrypted copies whose key is on your devices or in the link, with sizes and times. | Not applicable | Ciphertext |
| Account and network | Requests and estimated spend are counted under a one-way hash, for up to two days. | Requests reach Tinfoil under Undergrove’s key. | Vercel sees ordinary request details such as your IP address, under its own logging and retention. |
What we keep
The limits
Read the full noticeHide the full notice
Contents
Data notice · updated 31 October 2026. Operator identity, privacy contact, and legal bases must be finalized before paid launch.
About the summariesEach section opens with a summary in plain words. Summaries are a reading aid, not part of the text: where they differ, the full text applies.
Your prompts
Processed in this browser tab. Sample responses are prewritten; nothing is sent to an AI provider.
Your conversations
Kept in your tab’s memory by default; refreshing clears them. You can choose to save them in your browser on your device, and download or delete them at any time. Memory notes and saved prompts are kept the same way. Your memory notes go with each message, as part of its instructions, unless you turn memory off; a model can offer a note, but none is saved unless you choose Save. A ChatGPT, Claude, Gemini or Perplexity export you import is read in your browser and isn’t uploaded; the conversations you pick from it are kept like any other. Notion, Obsidian and Markdown notes, bank statements and health records you bring in are read the same way, in a worker with no network access, and kept like documents; a model sees them only when you choose to ask it, and only the parts you pick (for statements, payee names only). Pages you watch are fetched through Undergrove’s server while the workspace is open, as when you add a web page. If you turn on sync, your browser encrypts each conversation (with its own settings and instructions), document, project, memory note, saved prompt, watched page, spending record and health record, and your memory setting, with a key only your devices hold, shown to you once as a recovery code. We store that ciphertext, with each item’s size and update time, and can’t read it. If you add a passkey to unlock sync, your browser locks the key with a secret that only that passkey produces, through the WebAuthn PRF extension; we store the locked key with the passkey’s ID and the name you give it, and can’t open it. A shared link holds an encrypted copy of a conversation or project for 1, 7 or 30 days, as you choose, or until it’s first opened if you share it to open once. Its key is the part of the link after the #, which browsers don’t send to us. A password you add to a link is used only in browsers, where it’s combined with that key, so we never see it either.
The public gallery
Publishing to the gallery is a separate choice from sharing a link, and isn’t encrypted. What you publish, an assistant’s set-up, a workflow’s steps or an app’s code, with the name you give it, is kept as sent and shown to anyone until you unpublish it or an admin removes it; its conversations and documents aren’t part of it. Reports are kept under a one-way hash of the reporter’s account or network address.
Your files
Only file names, sizes, and types are used. Contents are never read or uploaded.
Web search and web pages
Without live access, nothing is searched or fetched from the web.
Tools and model choice
Auto picks a model in your browser, and blind test votes are kept there too, saved only if you turn on saving.
Model routes
No model route is open yet. Every route will be listed here with its operator, location, and retention before it carries a single message.
Usage limits
To enforce fair-use limits, the gateway counts requests and estimated spend per account or key under a one-way hash. Counters expire within two days and contain no message content. A key’s own daily cap and model list are stored with the key. The workspace’s 30-day usage history is estimated in your browser from each answer and isn’t sent to us; it’s kept on your device only while you save conversations there.
Tracking
No advertising or analytics SDKs are included. Where our server keeps product counts, the workspace sends at most one report a day: one yes-or-no question about that visit, such as whether web search was used, answered with randomised response (local differential privacy, ε = ln 3), so the answer sent is the true one three times in four. The report holds only the question and the answer, with no account, cookie or identifier; the server adds it to that day’s totals and keeps nothing else. Nothing is sent if you turn product counts off in the workspace’s Settings › Privacy, or if your browser sends Global Privacy Control or Do Not Track. The method and the counts are on the product counts page. Account sign-in, when configured, uses Privy. Chat content is never sent to Privy. Payments are not enabled.
Crash reports and speed figures
Crash reports and speed figures are off until you say yes, and you’re asked once, shown exactly what would be sent. A crash report holds an error’s type, its message with anything that could be your content taken out, and where in our code it happened; speed figures are numbers of milliseconds. Both go to our own server with no account, cookie or address. Crash reports are counted by error, with the first report of each error kept, for 90 days; speed figures are added to public totals by day and not kept themselves. Change either in the workspace’s Settings › Privacy.
Landscape motion
On supported phones, device orientation moves the landscape. Browsers that require permission ask when you tap Enable tilt. These readings stay in page memory and are never stored or transmitted. Your reduced-motion preference disables the effect.
The site host
Vercel hosts the site and the gateway, and receives ordinary requests, which include your IP address. Its infrastructure logs and retention are controlled by Vercel; we do not promise zero hosting logs.
Model register
Checking the register…
Accounts, cookies, and requests
The account page and workspace load Privy only when sign-in is configured. Authentication may involve an email address, wallet address, account identifiers, and session storage or cookies. Read Privy’s privacy policy before signing in.
We do not use optional analytics or advertising cookies. Saving conversations uses your browser’s own storage and only after you turn it on.
Rights relating to account or hosting data depend on applicable law and the relevant provider. A public Undergrove privacy contact and full controller information will be supplied before paid launch. Do not submit personal information through the workspace as a privacy request.
What’s verified, and what isn’t yet
In the workspace, live models run in hardware enclaves operated by Tinfoil. Your browser checks each enclave’s attestation and published code before sending anything, then encrypts your messages so only that enclave can read them. Undergrove cannot read them in transit. You can inspect each check by selecting Verified in the workspace.
Answers from an enclave come with a receipt: the enclave, code release and measurements your browser verified before sending, and the key it encrypted to. While the tab that got the answer is open, you can download it with the enclave’s attestation report and check it again later; after that, it holds the report’s hash. A receipt is your browser’s own record, not a signed statement. The enclave it names is Tinfoil’s model router, which passes your request to the model’s own enclave. Your browser then tries to check that second enclave too, and the receipt says whether it could: most model enclaves run on Intel TDX hardware, which the verifier in your browser can’t check yet. For those it records which enclave answered; the router, whose published code your browser did verify, checks that enclave itself.
This has not yet been independently assessed, and you are trusting Undergrove to serve the verifying code as published. You can compare the code your browser loaded with the build’s manifest on Verify this page, and see aggregate counts and our scheduled checks on the transparency page. What verification proves.
View the workspace controlsOne message, stop by stop
- 01 · Your browser
You write a message.
Before anything leaves, your browser checks the enclave’s hardware attestation against the code Tinfoil published, so it knows which machine it’s talking to.
Readable here, on your device.
- 02 · Sealed
It’s encrypted to the enclave.
Your browser seals the message, and any files with it, to the key that attestation names: HPKE with X25519 and AES-256-GCM. From here on, it travels as ciphertext.
Readable only with the enclave’s key.
- 03 · The relay
Our relay passes it on.
Undergrove’s relay checks your sign-in and allowance and forwards the sealed bytes to Tinfoil. It can’t decrypt them, so it estimates usage from their size.
We see your account, the size and the time.
- 04 · The enclave
The model answers inside.
The message is opened and answered in Tinfoil’s hardware enclave (AMD SEV-SNP or Intel TDX). Tinfoil states that it can’t access the enclave and that nothing in it persists between restarts.
Your browser verifies Tinfoil’s model router, which passes the request to the model’s own enclave; that second enclave isn’t checked by your browser.
- 05 · Back to you
The answer returns sealed.
The reply is encrypted with keys from your request, streams back through the relay as ciphertext, and opens in your browser. The conversation stays there unless you save or sync it, and synced copies are encrypted first.
Readable in your browser again; in between, it was ciphertext.
The workspace shows every check under Verified. The developer API works differently: our gateway reads requests in memory to check them and never stores or logs them. None of this has been independently assessed yet. Privacy details · The architecture, with its code
What a provider can see
What the operator can technically read, what’s kept and what you can verify, for a typical AI chat service and for the Undergrove workspace.
Summarise this contract and flag anything about early termination.
- Your account
- Payment details
- IP address
- Usage
8f4a44ce 0b9d71e2 c35a0f19 7e62d4b8 a1f03c95 5d28e7b0 46c9f1a3 e07b52d6 93ae18c4 2fd6a970 b84c0e5f 61e9d327 fa0c85b1 7d34e9a6 c2581fd0 0e97b4c3…
- Your account
- IP address, through our host (Vercel)
- Size and time
- The kind of request: chat, transcript, speech…
- Whether search was on, and how many images
- Estimated cost
The same message sent to each. The bytes shown are an illustration, not a recorded request.
| A typical AI chat service | The Undergrove workspace | |
|---|---|---|
| Can the operator read your messages? | Decrypted on arrivalTechnically, yes. Messages are encrypted on the way (TLS), then decrypted on the provider’s servers so the model can run. Who may look is a matter of its policies. | Ciphertext onlyNot in the workspace. Your browser encrypts each message to a verified enclave, and our relay passes on ciphertext it can’t read. Our developer API reads requests in memory to check them, unless you use its encrypted mode. |
| Where are conversations kept? | On its serversUsually on the provider’s servers, linked to your account, for as long as its retention policy says. | On your deviceIn your browser. If you turn on sync or share a link, your browser encrypts the copy first; we store that ciphertext with its size and time. |
| Are they used for training? | Depends on the serviceIt depends on the service and your settings. Some use conversations to improve their models unless you opt out. | Nothing readable keptWe keep no conversation content we can read, so there’s nothing to train on. The models are open-weight copies, so their makers never receive your messages. |
| What can you check yourself? | Its wordIts policy and your settings. For how its servers handle your data, you rely on its word. | The enclave itselfThe enclave’s hardware attestation and published code, checked in your browser before anything is sent, with a receipt for each answer. |
| What does the operator still see? | Content and metadataYour account, payment details, IP address and usage, alongside the content itself. | Metadata, not contentYour account, your IP address (through our host, Vercel), and each request’s size, time and estimated cost. Not what it says. |
“Typical” means a hosted chat service that runs models on servers it or a provider controls, where messages are decrypted on arrival. Services differ, so read each one’s policy. Our side hasn’t been independently assessed yet. Privacy details · Named services, side by side