How we protect your data.

Infrastructure

BizBot runs on a hardened Linux host (Hetzner CPX22, EU region) behind Caddy with automatic Let's Encrypt TLS. The application database is Supabase (managed Postgres, US region) accessed only over TLS. Container images are pinned and rebuilt from controlled Dockerfiles; no production binaries run from unverified sources.

The marketing site, dashboard, automation engine, and database each run as separate services on isolated networks. Public traffic enters only through the reverse proxy on ports 80 and 443.

Encryption

• In transit. All traffic to businessbot.us and app.businessbot.us is served over TLS 1.2+ with HSTS preload. Internal service-to-service calls use TLS or run inside a private Docker network.
• At rest. Database storage and backups are encrypted at rest by our infrastructure providers. Secrets in transit between services are passed via environment variables loaded from disk-encrypted volumes.
• Passwords. User passwords are stored as salted bcrypt hashes by Supabase Auth. We never see your plaintext password.
• Tokens. Session tokens use short-lived JWTs with refresh; OAuth refresh tokens are encrypted in the database and scoped to the issuing tenant.

Tenant isolation

BizBot is multi-tenant by design. Every record in the database — customers, bookings, conversations, services, staff — is tagged with a business_id, and Postgres Row-Level Security policies enforce that no authenticated user can read or write data outside their own tenant. The dashboard connects with anonymous credentials plus the user's JWT, so RLS is the gatekeeper for every query.

Service-role keys (which bypass RLS) live only in our automation engine and are never exposed to the browser. Cross-tenant access requires a deliberate, audited admin action.

Access control

• Only a small number of named engineers have production access. Access is granted by role, not by individual exception.
• SSH access uses ed25519 keys and is gated by allowlisted IPs.
• Administrative dashboards (Supabase, Hetzner, Stripe, etc.) require strong, unique passwords stored in a password manager and second-factor authentication.
• Internal "super admin" actions inside BizBot are gated by an explicit app_admins table and recorded in an immutable audit log.

Secure development

• All code lives in version control. Production deploys come only from the main branch.
• Every change is reviewed and runs through TypeScript type-checking, build verification, and our smoke / e2e test suites.
• Dependencies are tracked and patched on a regular cadence. Critical advisories are addressed within days.
• Secrets are kept out of source control by convention and by .gitignore; deployed services receive secrets via environment variables, not source.

Monitoring & logging

• Application and reverse-proxy logs are retained for 90 days for security and debugging.
• Failed authentication attempts, suspicious traffic, and unusual API patterns trigger alerts to the on-call engineer.
• Webhook calls between services use shared-secret headers; inbound carrier webhooks (Twilio, Telnyx, Meta) are validated against signed HMACs.

Backups & continuity

• The primary database is backed up automatically by Supabase, with point-in-time recovery available within the retention window.
• Backups are retained for up to 30 days and rotated out.
• Recovery procedures are documented and rehearsed periodically. Our recovery objectives are RPO ≤ 1 hour and RTO ≤ 4 hours for catastrophic data loss.

Subprocessors

We rely on a vetted set of vendors. Each is bound by a written data-processing agreement. The current list is in our Privacy Policy. We will notify customers in advance of material changes to the subprocessor list.

AI & LLM safety

BizBot uses large language models to draft customer replies. We take specific measures so that AI does not become a back door:

• No training on customer data. Our LLM provider does not retain or train on prompts or responses sent through our gateway.
• Tenant-scoped prompts. Each prompt is constructed from one tenant's data only; cross-tenant data is never sent to the model.
• Deterministic actions. The model never executes side effects directly. All actions (creating a booking, updating a record, sending a message) go through our backend, which re-validates tenant permissions before executing.
• Anti-hallucination guardrails. Responses to customers are constrained to facts the model can verify against the tenant's database (services, hours, availability). If the model is unsure, it hands the conversation off to a human staff member.

Incident response

• An on-call engineer is reachable 24/7 for service-impacting incidents.
• If an incident affects you, we will notify you and your designated security contact without undue delay, and in any case within 72 hours of confirming a personal-data breach as required by applicable law.
• Post-incident reviews are conducted for every Sev-1 or Sev-2 event, and corrective actions are tracked to completion.

Responsible disclosure

If you've found a vulnerability, please tell us — we appreciate the help.

• Email: security@businessbot.us with a clear description, reproduction steps, and the impact you assess.
• Acknowledgement: within 48 hours.
• Triage and remediation: we'll keep you updated as we work on a fix.
• Public credit: we'll happily credit you once the issue is resolved, unless you prefer to remain anonymous.

We do not currently run a paid bug-bounty program, but we'd love to send a swag pack and a public thank-you for material reports.

Contact

Security disclosures: security@businessbot.us
General questions: hello@businessbot.us