Overview
Grounded is a multi-tenant platform: one deployment hosts many chatbots ("bots"), each created and operated by its own bot owner. Two kinds of data exist here: data the platform stores to run the service (described below), and the knowledge a bot owner uploads for their bot to answer from, which belongs to that owner and is used only to answer that bot's questions.
Accounts and sign-in
Signing in is optional for most bots. There are two ways to create and use a Grounded account, and they store different things. This page used to describe only the first one and state that we never see or store a password — that was wrong for anyone who used the second, and it is corrected here.
Single sign-on (Google, Microsoft, GitHub)
You authenticate with the provider and we never receive your provider password. We store the opaque, stable subject id the provider issues for you, the email address that provider reported, and — if the provider supplies them — a display name and avatar URL. The subject id is what your next sign-in is matched against; the email is what team and bot invitations addressed to you are matched against.
Email and password
You may instead register directly with an email address and a password of at least 8 characters. In that case we do store a password — never the password itself, only a one-way hash of it. Specifically: PBKDF2-HMAC-SHA256, 10,000 iterations, with a 16-byte random salt generated per account, stored as scheme, iteration count, salt and derived key. The plaintext exists only in memory for the duration of the request that verifies it; it is never written to the database, never written to a log, and never included in an error report. A hash cannot be reversed into your password, but it is not nothing either: choose a password you do not use elsewhere.
The two methods can coexist on one account with the same email address. An account created through single sign-on has no password stored at all until you set one.
Sessions
A successful sign-in returns a signed session token, valid for 30 days, which your browser holds in localStorage (not a cookie) and sends on requests that need it. The token is signed, not encrypted, and carries only your account id and a revocation counter — no email, no name. Signing out increments that counter, which invalidates every outstanding token for your account on every device at once, and so does completing a password reset. Changing your password while already signed in deliberately does not: your current session stays alive, because you have just proved you are the one holding it.
Password reset
Requesting a reset stores a hash of a single-use token (never the token itself) with a 45-minute expiry, and emails you the token as a link. Using it, letting it expire, or requesting another one retires it. Reset requests are rate-limited per IP address and per email address, and the response is deliberately identical whether or not an account exists at that address, so the form cannot be used to discover who has an account here.
What an account record contains
Email, display name, avatar URL, the password hash if you set one, account status, the session revocation counter, your two email notification preferences, the date you created the account, and the date you last signed in. That is the whole record.
Deleting your account
Account deletion is available from your settings (you confirm by typing your own email address). It deletes the account record, every linked sign-in identity, your stored preferences, your ownership rows, any reviews you left, and — outright, not merely unlinked — the conversations tied to your account. Two things deliberately survive, and you should know about both. First, each bot's own question log and token-usage ledgers: these are the bot operator's analytics and billing records, keyed to the bot rather than to you, and they retain the text of questions asked and answers given. They carry no account id, email or name of yours. Second, bots you own are left standing — deleting a whole tenant's knowledge base as a side effect of one member closing their account would be the wrong default, so transfer or delete your bots first if you want them gone too.
Chat history
When a bot has history enabled, your conversations with it are stored in the platform database so you can return to them. Access is owner-scoped: only your browser (via its visitor id) or your signed-in account can list or read your conversations.
- Anonymous use. If you chat without signing in, your browser holds a random visitor id in
localStorage. It is not tied to your identity; clearing your browser storage discards it. - Retention. Anonymous conversations are automatically deleted after the retention period the bot's owner configures; an owner may also choose to keep them indefinitely. A "delete my data" control in the chat removes all of your conversations with that bot on request.
- Owner analytics. Each bot's owner can review recent questions and answers asked of their own bot, to find gaps in its knowledge. Owners never see your activity on other bots.
Answer caching
To answer common questions quickly, the first answer of a brand-new conversation may be cached for about one hour, keyed to the bot and the question text. Cached entries hold the answer, not who asked it.
File uploads
Files you attach in a chat (documents, images, audio, video) are used as context for that conversation only. They are stored temporarily, expiring after roughly 2 hours, and then automatically removed. Uploaded files are never added to a bot's knowledge base unless the bot's owner separately ingests content through their admin console.
Bring-your-own API keys
A bot owner may connect their own LLM provider key. Keys are encrypted at rest with AES-256-GCM, are never displayed again after saving, and are never logged or returned by any API. Usage on an owner-supplied key is billed by the provider directly to that owner.
Usage ledger
The platform keeps a per-bot ledger of model token usage by month, used for billing, monthly caps, and cost reporting to the bot's owner. The ledger holds counts, not conversation content.
Analytics and telemetry
This section is a correction. An earlier version of this page and of the consent panel said there were no analytics on this site. That was not accurate, and this is what is actually running.
Cloudflare Web Analytics is enabled for this domain. Cloudflare's network injects a small measurement script (static.cloudflareinsights.com/beacon.min.js) into HTML pages served from groundedbuilds.dev, and your browser sends one measurement to /cdn-cgi/rum per page view. It reports page load timing and Core Web Vitals, the URL, referrer, and coarse device/browser/country information, so the operator can tell whether pages are fast and whether anything is broken.
What it does not do, and this is the part that matters: it sets no cookie, writes nothing to your device, assigns you no visitor id or fingerprint, cannot follow you to any other website, and is not used for advertising, profiling, or resale. Cloudflare processes it as our service provider and does not build a cross-site profile from it.
Why it is not on the consent switch. The script is injected by Cloudflare's network after this application has finished producing the page, so no code in this product can withhold it on the basis of a choice made in the browser. Offering a toggle that did nothing would be a worse lie than the one this section corrects. If you would rather it did not run, any content blocker or a cloudflareinsights.com block in your DNS or hosts file stops it cleanly — the site is fully functional without it.
There is no Google Analytics, no advertising pixel, no session recorder, no heatmap, and no A/B testing service on this site. The Content-Security-Policy this site serves permits scripts from its own origin and from Cloudflare's analytics host, and from nowhere else, so a third-party tracker could not load here even if one were added by mistake.
Who else processes this data
Grounded runs on infrastructure and services operated by other companies. Which ones apply to you depends on which features the bot you are using has switched on.
- Cloudflare — hosting, CDN, object storage, key-value storage, and the page-view telemetry described above. Sees all traffic to this site.
- Turso — the managed database holding accounts, bots, knowledge, and conversations.
- Model providers — the question, the retrieved knowledge, and the conversation context are sent to whichever LLM provider is configured for that bot in order to produce an answer. A bot owner may supply their own provider key, in which case usage is billed by that provider directly to them.
- Identity providers — Google, Microsoft or GitHub, only if you choose to sign in with one.
- Email delivery — used for password resets and invitations.
- Stripe — only for accounts that purchase a paid plan. Card details are entered on Stripe's own hosted page and never pass through, or exist anywhere in, this platform.
What we don't do
- No advertising, no advertising trackers, and no advertising cookies.
- No selling or renting of personal data, to anyone, ever. Data is disclosed only to the service providers listed above, and only as needed to operate a feature you or the bot's owner switched on.
- No cross-site tracking and no profile of you assembled across bots.
- No use of your conversations, or a bot owner's knowledge, for anything beyond operating the service — including no use as training data.
Contact and requests
Questions about this policy, a data-access or deletion request the in-chat and settings controls do not cover, or anything else about how your data is handled: use the contact page. Privacy and data-deletion requests are handled there and do not require you to have an account.
For a specific bot's knowledge, retention window, or the answers it gives, the bot's owner is the right first contact — they control that content, and Grounded does not. If you cannot reach them, tell us on the contact page and we will pass it on or act on it ourselves where the platform is the right place to fix it.