Isolated by default. Auditable by design.
Every workspace is sealed off at the database level with Postgres row-level security — FORCE + WITH CHECK on every tenant-scoped table — so one tenant can never read, write, or even count another's data. Roles, secrets, MFA, and a full audit trail are properties of that engine, not line items on a quote — they're identical on a trial workspace and on Enterprise.
Row-level security, not app-layer promises
Multi-tenancy done right: isolation is a database guarantee, not a filter your code has to remember to apply. Every tenant-scoped table carries a FORCE + WITH CHECK policy keyed to the current tenant — so the boundary holds even when application code doesn't.
- FORCE ROW LEVEL SECURITY + WITH CHECK on every tenant-scoped table — not an opt-in flag a developer can forget.
- 58 tables carry the isolation boundary at the database engine, not in application middleware.
- A missing WHERE clause, a leaked query, or a bug in app code still can't return another tenant's rows.
- Service accounts and background jobs run inside the same policy set — there is no privileged bypass path.
Secrets sealed at rest, keys you can rotate
No credential sits on disk in a readable form. API keys are stored only as a one-way SHA-256 hash, so there is nothing to steal; OAuth tokens and connector credentials are Fernet-encrypted before they're written, decrypted only in memory by the service that needs them, and scoped so a single leaked credential doesn't compromise the workspace.
- API keys are stored as a one-way SHA-256 hash — shown once at creation, never recoverable from the database.
- Secrets are decrypted only in memory, on demand, by the service that needs them — never logged in plaintext.
- Keys are scoped and rotatable, so a compromised credential can be revoked without touching the rest of your workspace.
- OAuth tokens and connector secrets (Mailjet, webhooks) are Fernet-encrypted at rest with a rotatable key.
What your security team will ask for
The controls that turn a pilot into a rollout — properties of the engine every workspace runs on, not a security package you negotiate separately.
TOTP two-factor for users, email-OTP for operators, plus mandatory email verification on signup.
Every meaningful change is recorded — who did what, when, and to which record — exportable for review.
Owner, admin, manager, member, and viewer roles gate every action, with a dedicated admin console for users and permissions.
Accounts and offboarding stay governed by your IdP through SCIM. SAML / OIDC single sign-on is on request — talk to us about timelines.
Export and deletion workflows make data-subject requests a button, not a project.
Consent is recorded per contact and per channel, so your team can see opt-in state on the record before any outreach goes out.
TLS covers every hop — browser to API to background worker — with no unencrypted leg.
Configurable session lifetimes keep access tokens short-lived, so the blast radius of a leaked session is bounded by the clock.
The product interface — navigation, screens, forms, and transactional emails — is localized in English, French, Spanish, and Japanese. Each person picks their language and it's saved to their profile, so it follows them across devices; new users start in your workspace's default.
One engine, many tenants, zero crossover. Your data is yours, separated at the row level, sealed at rest, provisioned from your identity provider, and logged end to end.
Questions your team will ask.
Every tenant-scoped table enforces Postgres row-level security with FORCE + WITH CHECK — isolation is enforced at the database, not the application layer. A bug in app code, a missing WHERE clause, or a leaked query still can't cross tenants.
Two different ways, deliberately. An API key is never stored in a recoverable form at all — we keep only a one-way SHA-256 hash, so a leaked database yields no working key. OAuth tokens and connector credentials do need to be replayed, so they're Fernet-encrypted at rest and decrypted only in memory, on demand, by the service that needs them.
Yes — TOTP two-factor for users, email-OTP for operators, plus mandatory email verification on signup and full audit trails on every authentication event.
Every meaningful change — record creation, edits, deletions, permission changes, logins — with who, when, and what changed, exportable for your own review or a compliance request.
Role-based access (owner, admin, manager, member, viewer) gates every action, with an admin panel for users, security settings, MFA enforcement, and audit logs.
Provisioning, yes — SCIM keeps joiners, movers, and leavers in step with your identity provider instead of a spreadsheet, so offboarding is one action in the system you already trust. SAML / OIDC single sign-on is available on request; tell us your timeline and we'll scope it with you.
GDPR export and deletion workflows make a data-subject request a button rather than a project, and consent is recorded per contact and per channel so your team can see opt-in state on the record before any outreach goes out.
Yes — TLS covers every hop, from the browser to the API to background workers, alongside encryption at rest for stored data and secrets.