Privacy Policy
The short version. Your account is an email address — there is no password. If you sign in with Google we also keep the name on that Google account, and nothing else about it. Sign in by email, or with Google if you would rather; either way it is the same account. Your threads, and everything a run produces in them, are held on our servers and are yours: you can take a complete copy at any time, and deleting your account erases them.
When a run happens on your own machine, your prompt goes from that machine to your AI provider under your login. We never see a model credential and are not in that path.
There is no analytics, no advertising, no tracking, and no cookie. Nothing about you is sold or shared with anyone who is not needed to run the service.
This summary is not the document. Where the two differ, the document below is what holds.
1. Who this is about
Grothendieck Labs ("grothendieck", "we") operates grothendieck and is the controller of the personal data described here. Questions about this policy, and any request to exercise a right under it, go to privacy@grothendieck.io.
2. What we hold, and why
Your account
An email address, and the date the account was created. There is no handle and no password — the address is the account. It is held because it is the only way to sign you in and the only way to reach you about the service.
If you signed in with Google, also your first and last name as Google reports them. It is held for one purpose, which is to have something to call you by in the interface instead of a fragment of your address; nothing is decided by it and it is never shown to anyone but you. You never typed it, so if you want to see exactly what we were told, it is in the export. It is refreshed from Google each time you sign in that way, and it is not held at all for an account that has only ever signed in by email — the interface reads a name out of the address in that case, and gets it wrong as often as not.
Signing in with Google
If you use the Google button, Google tells us four things: a stable identifier for
your account there (an opaque id, not your address), the email address on that account,
whether Google has verified it, and the first and last name on it. We keep those, joined to
your account, so pressing the button again brings you back to the same place. We ask Google
for nothing else — the consent screen requests identity only (openid,
email, profile), and we never receive or store a token that could
read your Gmail, Drive, contacts, or anything else.
Two consequences worth stating. If the address Google reports already belongs to an account here, the two become one account — that is the point, so that signing in by email and signing in with Google do not leave you holding two halves of your work. And we will only do that when Google says the address is verified; an unverified one is refused rather than joined, because otherwise anyone able to set your address at a provider could reach your account.
Google will also know that you signed in to grothendieck, and when. That is between you and them under their privacy policy, and it is the unavoidable cost of the button. Signing in by email involves Google not at all.
Signing in by email
Signing in mails you a six-digit code. While a code is outstanding we hold the address it was sent to, a keyed hash of the code, a count of the attempts made against it, the name your browser or app gives itself, its platform and version, and the IP address the request came from. The code itself is not recoverable from what we store. The record is held so that a code can only be used once, cannot be guessed, and cannot be pointed at a stranger's inbox.
Your sessions
A signed-in device holds a token; we hold a keyed hash of it, never the token. Alongside it we hold the device's self-reported name, platform and version, when it was created, when it was last seen, when it expires, whether it has been revoked, and the IP address it signed in from. This is what the device list in the product shows you, and it exists so that you can see and end a session you do not recognise.
Your threads
A thread is an append-only log of events: what you asked, what the model narrated and concluded, which tools it reached for, the artifacts it produced, your annotations, and the timings. That log is the product, and it is held on our servers so that it survives the machine that produced it and reaches every device you sign in on. Larger artifacts — reports, figures — are stored as content-addressed objects, referenced from the log by the hash of their content.
Attachments you add to a thread are part of it and are held the same way. What you put in a thread is up to you; if you paste someone else's personal data into one, you are the one deciding to do that.
Your machines
A machine you pair reports a label you chose, whether it is reachable, which AI harnesses it can drive and how they answered, its version, and whether its runs are confined to a sandbox. It never reports the contents of your disk, your files, or your AI credentials.
What things cost
Per day, per machine, per harness and per model: tokens in, tokens out, how many runs, and how long they were active. Aggregated at that grain and not tied to individual threads.
Lending and borrowing machines
If you lend a machine or accept one, we hold the record of that arrangement: who lent, who borrowed, which machine, when it started, and when it ended. Each side can see the other's email address, because you cannot sensibly revoke a lend to a person you cannot identify.
Skills you write
Skills you author are held as their text and their version history, under your account.
What we do not hold
- No model credentials. The only component that touches one is the executor, which runs on your own machine, one process per run. It is not something we can read, and not something that reaches our servers.
- No passwords. There are none in this product.
- No analytics, telemetry, advertising or tracking of any kind, on the website or in the app.
- No cookies. See §6 for what is stored on your own device instead.
3. Why we are allowed to hold it
For readers in the EU, UK, or anywhere with an equivalent law: your account, your threads, your machines, and your usage records are processed to perform the contract you enter by using the service — without them there is no service. Sign-in records, attempt counts and IP addresses are processed under our legitimate interest in keeping accounts from being broken into and the service from being abused, which we consider proportionate because each is short-lived and narrow. Where we ask for consent, we ask for it plainly and you can withdraw it by deleting your account.
4. AI providers, and where your prompts actually go
This is the part most services describe vaguely, so here it is exactly.
On your own machine. The run executes there, under the AI subscription already signed in on that machine. Your prompt travels from your machine to Anthropic, OpenAI, or whichever provider you have signed into, under your own account and their own privacy policy. It does not pass through us. What comes back is written into your thread's log, which is where we do hold it.
On a machine someone lent you. The same, except the subscription paying for it is theirs. The owner of that machine can see that runs happened on it and what they cost; the design keeps your thread's contents out of their account, but you are running on hardware they control, and you should treat that as you would any borrowed computer.
On our hosted tier. If you have no machine of your own and use the hosted option, the run executes on our infrastructure under our API key, and your prompt goes to the model provider under our commercial agreement with them. Providers under those agreements do not train on the content.
5. Who else touches it
A small, named list. Each is a processor acting on our instructions, under a data processing agreement, and none of them is permitted to use your data for their own purposes.
| Who | What for | Where |
|---|---|---|
| Render | Runs the backend and its Postgres database — accounts, threads, event logs, everything relational | United States (Virginia) |
| Cloudflare R2 | Stores artifact content as content-addressed objects | United States |
| Cloudflare Pages | Serves this website | Global edge |
| Resend | Delivers sign-in codes. Receives the address and the message; nothing else | United States |
| Only if you use the Google sign-in button, and only to tell us who you are. Not involved at all if you sign in by email | United States | |
| Anthropic, OpenAI, and other AI providers | Only on the hosted tier, as described in §4. On your own machine they are your provider, not our processor | United States |
We do not sell personal data, do not share it for advertising, and have never done either. If we ever add a processor to this list we will say so here before it starts, and the version line at the top will move.
Transfers. Our infrastructure is in the United States. If you are in the EU or UK, your data is transferred there under the European Commission's Standard Contractual Clauses (and the UK Addendum where it applies), which is the mechanism our agreements with each processor above rely on.
6. What is stored on your own devices
Not cookies. The web app stores, in your browser and only in your browser: your session token
(in localStorage, so that closing a tab does not sign you out), an installation
identifier so your device list shows one entry per browser rather than one per sign-in, and a
local copy of the threads you have opened (in IndexedDB, so a thread draws instantly and survives
being offline). All of it is strictly necessary to the service you asked for, none of it is read
by anyone but the app, and signing out clears the token.
A machine you pair keeps a fuller local replica — the threads and their logs — in a database under your home directory, so that runs work while the machine is offline. Deleting your account tells every machine still connected to erase that replica. A machine that is switched off at the time will erase it when it next reaches us.
7. How long it is kept
| What | How long |
|---|---|
| Your account, threads, event logs, artifacts, annotations, skills, usage records | Until you delete your account. This is a working archive by design — a thread from a year ago is meant to still be there |
| Sign-in challenges (address, code hash, attempts, IP) | Deleted one day after the code expires |
| Your name, if Google told us one | Until you delete your account. Refreshed from Google each time you sign in that way; an account that has only ever signed in by email has none stored |
| A linked Google identity | Until you delete your account. Unlinking one on its own is not offered yet; until it is, deletion is the way to remove it |
| The short-lived rows a Google sign-in needs while it is in flight | Single-use, valid for minutes, deleted an hour after they expire |
| Machine pairing tickets | Deleted one day after they expire |
| Machine-sharing codes that were never redeemed | Deleted after they expire |
| The IP address on a session | Erased 30 days after that session is revoked or expires. The rest of the session record stays, so your device list can still show you that it was signed out |
| Records of lends, after either side ends them | Kept, marked as ended, until either account is deleted — so "it was revoked" and "it never happened" stay different facts |
| Server logs | Operational logs kept by our hosting provider on their own short rolling window; they carry request metadata, never thread content |
8. Your rights, and the buttons that honour them
Every one of these is a thing you can do yourself, in the product, without asking us. That is deliberate: a right you have to email someone about is a right with a queue in front of it.
- Access and portability. Export my data, in the account menu at the bottom of the sidebar, returns a single JSON document containing your account record, every thread with its complete event log, artifacts, annotations, usage, skills, sessions, machines, lending records, and any linked identity. Artifact content is referenced by hash and fetchable with the same session.
- Erasure. Delete account, in the same menu, confirmed by typing your address. It erases the account and everything scoped to it, tells every connected machine to erase its local replica, and removes stored artifact content that nothing else references. It is immediate and cannot be undone.
- Rectification. The only facts we hold about you that you did not author are your email address, your name if Google gave us one, and, if you linked one, your Google identity. To change the address, delete the account and sign in with the one you want. To change the name, change it at Google and sign in again — we take what it tells us, so correcting it there corrects it here.
- Objection and restriction. Write to us. In practice, for a service with no profiling and no marketing, the meaningful form of objection is deletion.
- Complaint. If you are in the EU or UK you may complain to your local supervisory authority. We would rather you told us first.
Requests sent to privacy@grothendieck.io are answered within 30 days.
9. Security
What is worth stating precisely, rather than in adjectives:
- There are no passwords to leak, reuse, or reset.
- A Google sign-in is bound end to end: the request that starts it is written down here first and the code that comes back is checked against it, once, using PKCE — so a code intercepted on the way back is worth nothing on its own. The session token is never put in a redirect URL, where it would be written to access logs; the callback hands over a one-time code in the URL fragment, which browsers do not send to servers, and that code is spent within seconds.
- Sign-in codes, session tokens, socket tickets, pairing tickets and sharing codes are all stored as keyed hashes of values we have already forgotten. A copy of our database is not enough to sign in as anybody.
- Sign-in codes are single-use, expire quickly, and are rate-limited per address and per IP address so that neither a code nor an inbox can be hammered.
- Revoking a session closes its live connections immediately rather than waiting for its next request.
- The runner installer and every update verify a cryptographic signature before running anything, so control of the download server is not enough to hand out code.
- A machine may only be lent while it reports that its runs are confined to a sandbox, and the service refuses to create a sharing code otherwise.
Reporting a vulnerability. security@grothendieck.io, also published at /.well-known/security.txt. We will not pursue anyone who reports a flaw in good faith.
If something goes wrong. If a breach affects your personal data we will notify the relevant supervisory authority within 72 hours of becoming aware of it, and tell you directly where the law requires it or where the risk to you warrants it regardless.
10. Age
This service is not for people under 16. We do not knowingly hold data about anyone younger, and will delete an account we learn belongs to one.
11. Changes
The version line at the top of this page is the one the product records against your account when you agree to it. If this document changes in substance, that version moves, and the next time you open grothendieck it asks you to read and accept the new one before going on — with signing out as an equally available answer. Typo fixes do not move the version.