Security and privacy by design
Every deployment is isolated at the database layer via Postgres Row-Level Security, CI-gated on every merge. Your data never touches another tenant's row — by architecture, not by convention.
Multi-tenant RLS isolation · Per-tenant DEK encryption · Cryptographic audit log
What we ship vs. what's on the roadmap
Honest status for every control. We distinguish between implemented, oriented (controls in place, counsel review pending), and roadmap (planned, not yet audited).
| Control / Feature | Status | Note |
|---|---|---|
| Multi-tenant RLS isolation | Done | Postgres Row-Level Security, CI-gated |
| AES-256 at rest, per-tenant DEK | Done | Per-tenant DEK + KMS |
| BYOK (Bring Your Own Key) | Done | Enterprise tier |
| JWT HttpOnly cookies | Done | No localStorage tokens |
| MFA (TOTP) | Done | |
| Cryptographic audit log | Done | Tamper-evident chain |
| DSAR / GDPR export tooling | Done | Automated per-tenant data export |
| EU / MENA data residency | Done | Enterprise, infra-provisioned |
| GDPR-oriented controls | Oriented | Counsel review pending |
| HIPAA-ready (BAA available) | Oriented | Enterprise only |
| SOC 2 audit | Roadmap | Planned — not yet audited |
| ISO 27001 | Roadmap | Planned |
oriented = controls implemented, counsel review pending; roadmap = planned, not yet audited
How the security architecture works
RLS Architecture
Every tenant table is protected by Postgres Row-Level Security policies enforced at the database engine, not the application layer. A CI gate (`make ci-check-rls`) blocks any migration that introduces an unprotected tenant table.
- Per-request GUC `SET LOCAL app.tenant_id` wired in middleware
- FORCE RLS even for table owners
- CI-gated: zero RLS-missing tables merge to main
Encryption at rest
Data is encrypted at rest using AES-256. Each tenant gets a unique Data Encryption Key (DEK). DEKs are managed via a KMS (AWS KMS in production) and never stored alongside the data they protect.
- Per-tenant DEK — one tenant's key never touches another's data
- KMS-managed key lifecycle and rotation
- BYOK available on Enterprise: bring your own CMK
JWT / Cookie security
Authentication tokens are stored exclusively in HttpOnly, SameSite=Strict cookies, which are inaccessible to JavaScript. This eliminates the entire class of XSS token-theft attacks that affect localStorage-based auth.
- __Host- prefix cookies: no subdomain leakage
- Short-lived access tokens + rotating refresh tokens
- MFA (TOTP) required on sensitive account actions
Cryptographic audit chain
Every security-sensitive operation is written to a tamper-evident audit log. Each entry is chained to its predecessor via a cryptographic hash, making silent deletion or modification detectable.
- Immutable append-only log with hash chaining
- Per-tenant DSAR export includes full audit trail
- Compliance export available in JSON and CSV
Found a vulnerability?
We take security reports seriously. If you discover an issue, please contact us before public disclosure so we can investigate and patch promptly.
We aim to acknowledge reports within 48 hours and provide a fix timeline within 5 business days for critical issues.
Enterprise-grade security from day one
BYOK, dedicated infrastructure, BAA, and a full compliance export toolkit — available on Enterprise.