Last updated: 2026-07-07. This is an honest v1 describing the system as built; pending legal review before paying customers.
badBots gives you a personal AI assistant ("your badBot") running on a server dedicated to you. This policy explains what data exists, where it lives, who can touch it, and how to get rid of it. Plain language, no dark patterns.
badBots is operated by a single named operator (the "Operator"; see operator-access-policy.md). Contact: morgantrowland@protonmail.com.
Stripe customer/subscription id. We do not store your card details; Stripe does. Held in the central fleet database.
by using your badBot. These live on your dedicated VPS, in your assistant's own encrypted credential store and local database. We do not copy your conversation content into the central fleet database.
your prepaid balance. Aggregate cost figures are reconciled centrally; the content of calls is not.
(see the operator-access policy).
Your badBot runs on a Hetzner Cloud VPS in the EU (Nuremberg, Germany). Your conversation data, memory, and credentials stay on that VPS. The central fleet database (billing identity, balance, provider-key *identifiers* — never the secrets) is operated by the Operator.
See data-processing.md for the full list and roles. In short: Hetzner (hosting), Fireworks AI (the LLM inference your bot calls, under a key dedicated to you), Stripe (payments), Cloudflare (DNS/TLS for your subdomain), Resend (login/notification email). We pass through provider costs with no hidden markup.
Your badBot is backed up nightly, client-side-encrypted before it leaves the VPS, to off-site object storage. The encryption key is escrowed — meaning the Operator technically *can* decrypt your off-VPS backups (needed for restore and lawful continuity). We disclose this plainly: trust in the Operator is part of the model. Operator access to live data is logged and maintenance-only.
Your badBot isn't a locked-down chatbot: it runs code, browses the web, and can build and use its own tools on your behalf. That capability is the point — and it carries a real, industry-wide risk we'd rather name than hide: indirect prompt injection. If your bot processes malicious content (a booby-trapped web page, document, or email you ask it to read), that content could try to trick the bot into acting against your interest — for instance, sending your data somewhere, or granting lasting access to your bot.
What bounds that risk:
data on *your* VPS — never another customer's bot, and never the wider fleet (each customer is a physically separate server).
held by a separate component your bot cannot read, and your prepaid balance is a hard ceiling — a compromised bot can't run up an unbounded bill.
something looks wrong, access is pulled and the bot relaunched clean. We monitor your bot for anomalous device pairing and alert on it.
This trade-off is inherent to *any* capable AI agent — it's the same one you'd accept running one on your own laptop. We containerise and isolate each bot to bound the blast radius, disclose it plainly here rather than overstate our safety, and are hardening it further (tighter isolation of the agent from its own control plane) as the product matures. Treat your badBot like a capable assistant with real reach: be thoughtful about pointing it at untrusted content.
is destroyed, rendering any backup copy permanently undecryptable (verified by a post-erase recovery attempt; our object store keeps no recoverable versions).
(Hetzner, in the EU) wipes reclaimed disks; today we rely on that provider-side wipe for the live disk (full-disk encryption of the live VPS, which would make this a provider-independent cryptographic guarantee, is a planned hardening — we disclose this honestly rather than overstate it).
personal details from our records (a minimal billing record is retained where legally required).
forfeiture).
access; losing it is an account-recovery, not a data-loss, event.
Conversation/memory data persists on your VPS for as long as your subscription is active. On cancellation/lapse, see continuity-plan.md (grace → suspend → erasure). Backups follow the bucket retention there.
Questions or requests: morgantrowland@protonmail.com.