How data is protected
- In transit — every request is served over HTTPS/TLS. There is no unencrypted endpoint.
- At rest — all stored data sits in Cloudflare Workers KV and D1, encrypted at rest by Cloudflare.
- Connected-store tokens — access tokens for a merchant's Shopify or WooCommerce store get an additional application-level layer: AES-GCM with a key derived from a secret held only in the Workers runtime, and a fresh random initialisation vector per write. A stolen copy of the database does not yield a usable token.
- Least privilege — we request read-only scopes from connected stores. We never request write access.
- Data we deliberately do not keep — order data fetched to answer "where is my order?" is used for a single reply and never written to storage. Card details never reach our servers; payments are handled by Stripe. Account passwords are handled by Google Firebase Authentication and are never seen by us.
- AI provider (OpenAI) — to answer a visitor, the conversation text is sent to OpenAI's API, which generates the bot's reply. Per OpenAI's API terms, data sent this way is not used to train their models. We send only what is needed to respond — never card details or account passwords.
- Access control — production access is limited to those who need it to run the service, protected by unique credentials and multi-factor authentication. Customer dashboards are role-based, so an employee only reaches the bots they were added to.
- Backups — a nightly backup runs into Cloudflare D1, encrypted at rest, on a 30-day rolling window. Backups are never exported to third-party or removable storage.
- Audit trail — administrative actions and access to stored conversations and leads are recorded to an append-only log.
If something goes wrong
Our commitment: if a personal data breach affects a business's data, we notify that business without undue delay and within 72 hours of becoming aware of it — including when we are still investigating, because a partial picture delivered on time is more useful than a complete one delivered late.
1. Report
Anything suspected is reported immediately to security@botdesk.studio. Reports from outside — researchers, customers, providers — go to the same address and are treated with the same urgency. We do not take legal action against good-faith security researchers who report a finding privately and give us a reasonable chance to fix it.
2. Triage
Within 24 hours of a report we establish what happened, what data and whose data could be involved, whether it is still ongoing, and how severe it is. If we cannot rule out access to personal data, we proceed as though it occurred.
3. Contain
Stopping the bleeding comes before diagnosis. Depending on the incident that means revoking or rotating the affected credentials, disabling the affected endpoint or feature, or taking the service offline. Rotating a connected-store token is always safe: the merchant simply reconnects.
4. Notify
Affected businesses are told within 72 hours by email, covering what happened, which data was involved, what we have done, what we recommend they do, and who to contact. Where a business is the controller of the affected personal data, we support them in notifying their own customers and any regulator. Regulators are notified where the law requires it.
5. Recover
We restore service from a known-good state, using backups where required, and confirm the vulnerability is actually closed rather than merely quiet.
6. Learn
Within two weeks of resolution we write up the timeline, the root cause, and the specific changes that prevent a recurrence — and, wherever the failure is one a test could catch, we add that test. Fixes are tracked to completion rather than closed with the incident.
Reporting a vulnerability
Email security@botdesk.studio with enough detail to reproduce the issue. We aim to acknowledge within one business day and to keep you updated until it is resolved. Please do not access, modify, or retain data belonging to anyone else while investigating.
Independent audits
BotDesk has not yet undergone a third-party security audit or certification. An independent review is planned before public app-store distribution. We would rather say so plainly than imply a certification we do not hold.
Changes
We update this page as our practices change and revise the date above.