Anvella — Privacy Policy
Last updated: 2026-10-05
1. What this covers
This policy describes what Anvella actually stores and sends, as implemented in this codebase, for both ways the console can be run: self-hosted (you run it, you're the only user) and operator-installed (someone else runs an instance and issues you a login code). Every factual claim below is grounded in what the code does, not in what a typical SaaS privacy policy says a typical SaaS product does — where those two things differ, this document follows the code.
2. Information collected
If you're the operator (self-hosted, or running an instance for others)
The machine's own settings file, which API keys and provider credentials you've configured, your Obsidian vault (notes, journal, spend ledger), and the machine's file system to the extent you point the assistant at it.
If you're a customer signing in with a login code
- Your login code is stored hashed. The accounts file holds a salted, slow (PBKDF2, 240,000 rounds) hash of it, so a leaked accounts file is not a leaked set of working logins. The operator sees a code once, when issuing or reissuing it, and cannot look it up in the console afterwards. Additional copies can exist: encrypted under the account password for an email-and-password account (so the code can be recovered with the password, until it is reissued), encrypted for a remembered device (opened by the
anvella_devicecookie), and in the email that sends you your code, which can stay in the sending mailbox's sent items. Reissuing a code makes the old one stop working. - Your email address and, for an email-and-password account, a scrypt hash of the password.
- Remembered-device records: on a device where a PIN is set or entered (the operator, or a customer signed in with an account code), an encrypted copy of your code that only that device's cookie opens.
- A 4-digit PIN, if you set one (as a second factor), stored the same way: hashed, not stored in the clear.
- Any API keys or provider credentials you personally add to your account (for example, your own Anthropic key, if the operator's instance supports bring-your-own-key) are encrypted at rest. The encryption key is derived from your login code, not stored alongside the encrypted data, so the secrets are protected by the code. An email-and-password account can recover its code with the password. If a code is reissued instead, secrets sealed under the old code are dropped and have to be entered again.
- Your own workspace data: conversation history, notes, journal entries, and anything else the assistant records for you, kept in a workspace separate from the operator's and from any other customer's account. Two different login codes on the same installation cannot read each other's workspace.
- A display name, persona, and usage limits, set by the operator for your account, plus your email address and, if you pay through Stripe, your Stripe customer id. These are stored unencrypted (not secret) specifically so the operator can manage your account — rename you, cap your spend, or turn your code off — without needing your login code to do it.
For everyone: a session cookie (anvella_session), set only after you sign in, and a device cookie (anvella_device, kept for 400 days), set automatically when a PIN is set or entered (the operator, or a customer signed in with an account code), so that device can unlock with the PIN after a restart. Both are marked HttpOnly (unreadable by page scripts) and SameSite=Lax. They are used for signing in and nothing else — not for tracking or advertising, and this console does not run any third-party analytics or advertising script.
3. What is not collected
There is no telemetry phoning home to whoever built Anvella. An operator running their own instance does not transmit usage data anywhere outside that instance by virtue of running the software. There is no advertising identifier, no cross-site tracking, and no analytics SDK embedded in the console.
4. Third-party AI providers and other sub-processors
When you send the assistant a message, the operator's instance may route that message to a third-party AI provider to generate a reply. Only providers the operator has actually configured and enabled are ever used. The full set this codebase supports: Groq, Cloudflare (Workers AI), Mistral, DeepSeek, Google Gemini, OpenAI, Anthropic (Claude), OpenRouter, Z.ai, Cerebras, and OpenCode Zen.
Whichever provider handles a given turn receives the text of that message (and relevant recent conversation history) as part of generating a reply. That provider then processes it under its own privacy policy, which this document has no control over. Known secret-shaped values (API keys, tokens, credential-looking strings) are stripped before anything is written to logs, audit records, or diagnostic output — but this is a best-effort filter based on recognizing common shapes and key names, not a guarantee that every possible secret in free-form text is caught, and it does not change what is sent to whichever AI provider actually answers your message.
Beyond the AI providers above, the business also relies on a small number of other vendors as sub-processors: Supabase (database and authentication), Stripe (billing), Cloudflare (CDN, DNS, TLS and Workers, in addition to the Workers AI role above), Google (Apps Script and Workspace automation, and Gmail API/OAuth for sending and reading tenant mail), and Formspree (receives and delivers the intake-audit request form on anvellaai.com). Each is used only for the role named here.
5. Browser and desktop control
If you turn on browser or desktop control for your account, the assistant can act on sites and applications you have explicitly allowed — nothing is reachable until you add it to that allow-list. Passwords, card numbers, and similar sensitive-looking form fields are never filled or read automatically by the browser or desktop agents. Actions with real consequences (sending, spending, deleting, or saving a change) stop and require your specific approval unless covered by a bounded, expiring grant you created yourself. Turning either control on always shows you what it does and does not permit before it takes effect, every time you turn it on — turning it off is immediate. See the Terms of Service, Section 4, for more detail.
6. Data retention and deletion
Data in your workspace is kept until you or the operator delete it. If your login code is revoked, the workspace itself is not automatically erased — deletion is a separate, explicit step the operator can take. If you want your data deleted, ask the operator running your instance; if you are the operator running your own instance, your data is a folder on your own machine, and deleting it is exactly that. Backups and snapshots taken before a deletion can keep copies of the deleted data until they are rotated out or removed.
7. Children's privacy
This service is not directed at children, and it is not knowingly used to collect information from anyone the operator knows to be under the age where local law requires parental consent for this kind of service. If you believe a child has an account, contact the operator running that instance.
8. Changes to this policy
This document may be updated as the service changes. The "Last updated" date at the top reflects the most recent revision.
9. Contact
Questions about this policy, or a request about your own data: through the address given to you at sign-up or point of sale, or however the operator running this instance has told you to reach them.