Security

How we protect your workspace

Your workspace holds your mailboxes and other people's contact details. This page lists what is in place today — and, just as plainly, what isn't.

Workspace isolation

Every table that holds workspace data carries the workspace id and is protected by PostgreSQL row-level security, forced for the application's database role. A query without the workspace context sees no rows.
An automated check runs against the migrated schema and fails the build if any workspace table lacks the policy, has a nullable workspace id or no workspace index.
Cross-workspace lookups that are unavoidable (which workspaces you belong to, which invitation a link is for, which workspace an API key belongs to) go through four narrow database functions that return only the matching rows.

Mailbox passwords, Microsoft OAuth tokens and the n8n engine's shared secret are encrypted in the database with AES-256-GCM using versioned keys; keys can be rotated and existing values re-encrypted. The database refuses anything that isn't ciphertext in those columns.
Two-factor secrets and backup codes are encrypted; passwords are hashed with scrypt; API keys and invitation tokens are stored only as SHA-256 hashes and shown once.
Mailbox connections require TLS or STARTTLS, so mailbox passwords never travel in clear text.

Two-factor authentication with authenticator-app codes and single-use backup codes; repeated wrong codes lock the second factor temporarily.
Email verification before the first sign-in; password resets sign you out everywhere; you can see and revoke your sessions.
Rate limits on sign-in, sign-up, password reset and two-factor endpoints.
Roles per workspace (owner, admin, editor, viewer) checked on the server for every page and action — hiding a button is never the only protection.

Security-relevant actions — sign-ins, MFA changes, member and role changes, invitations, API keys, billing events, settings changes — are written to the workspace's audit log in the same transaction as the change.
The application's database roles cannot update or delete audit entries.
Owners and admins can filter the log by member, action and date.

Server-side requests to customer-supplied addresses (website analysis, mailbox servers, n8n routers, webhooks) are checked against private and internal network ranges, including after DNS resolution.
Webhooks and engine dispatches are signed with HMAC-SHA256 and timestamped, so receivers can reject forged or replayed calls.
Click-tracking links are signed; unsubscribes work with one click and are suppressed across the workspace immediately.

We do not hold SOC 2, ISO 27001 or similar certifications today.
Single sign-on (SAML/OIDC) is not available yet.
The hosting region and the sub-processor list will be published with the final legal terms.