We cannot read your passwords. That is by design.
The vault's HMAC key is derived inside your authenticated session and never persisted on Bella's servers. When you store a credential, we receive ciphertext we cannot decrypt. When you ask Bella for a login by voice, it retrieves ciphertext, decrypts it client-side, and auto-fills — the raw secret never touches our API in plaintext.
Key derivation: PBKDF2-SHA256, 310,000 iterations, per-user salt. Ciphertext envelope: AES-256-GCM with a 96-bit random nonce per entry. HMAC integrity check on every read.
Revoke everything. Instantly.
Every Bella integration — calendar, email, voice, grocery, contacts — has an independent kill switch. One toggle in Settings stops that integration dead. The check runs against a live database row on every request, with no caching layer in between. There is no 'propagation delay'. It stops when you say stop.
Implemented in Bella's request middleware. The kill switch table is queried on each inbound API call after JWT validation, before any handler runs. A disabled integration returns 403 immediately. The same mechanism applies to the master account kill switch — one toggle, full stop.
AES-256-GCM at rest. TLS 1.3 in transit. No exceptions.
All data at rest is encrypted at the disk level by our infrastructure provider and at the application level for sensitive fields. All data in transit uses TLS 1.3 with HSTS enforced. API keys and integration tokens are encrypted separately from the data they protect and rotated quarterly.
Disk: Supabase AES-256 transparent encryption. App layer: libsodium-wrappers AES-256-GCM for credential fields, relationship signals, and vault entries. AWS Secrets Manager for key storage with automatic quarterly rotation. TLS 1.3 enforced at the CloudFront distribution layer with HSTS max-age 31536000.
Your data is invisible to everyone else. Including us.
Bella's database enforces Row-Level Security on every table, including queries from service-role connections. Your organisation's data is scoped by org_id at the database level, not just the application level. A bug in application code cannot leak your data to another tenant — the database itself enforces the boundary.
PostgreSQL FORCE ROW LEVEL SECURITY on all tables. org_id column in every user-data table. CI migration lint fails the build if a new table ships without RLS policies. Internal tooling used by Bella staff operates under the same RLS constraints — support staff cannot view your data without an explicit, logged, time-limited consent grant.
Your data is stored where you choose.
On signup you choose your region: Australia (Sydney) or Europe (Frankfurt). Your database records are created in that region and not replicated cross-region. Backups stay in the same region as primary storage. If you delete your account, all database records are purged within 30 days. Note: AI inference requests are processed by Anthropic, OpenAI, and Google at their global infrastructure, which may be outside your chosen storage region.
Regions: ap-southeast-2 (AWS Sydney) for AU customers; eu-central-1 (AWS Frankfurt) for EU customers. Region locked at account creation. No cross-region read replicas for user data. Deletion pipeline: soft-delete on account close, hard purge + audit log at 30-day mark.
Bella never sees your card. Paddle handles it all.
Billing runs entirely through Paddle as Merchant of Record. Paddle (SGH WLL, Bahrain) processes your card, handles tax collection and remittance across 100+ jurisdictions, and issues your receipts. Bella's backend receives only a Paddle customer ID and webhook events — never card numbers, CVVs, or bank details.
Paddle entity: SGH WLL, CR 131095-1, Bahrain. PCI-DSS scope sits entirely with Paddle. Bella is outside PCI scope. Pricing is canonical USD — Essential $99/seat/mo, Professional $199/seat/mo, Enterprise $399/seat/mo, billed annually — matching the Paddle product catalog. No undocumented surcharges.