Security

How your data is separated, encrypted, scanned and access-controlled.

Your data is separated by account

Every record in the CRM belongs to exactly one account, and every lookup runs through the account you are signed in to. An identifier belonging to another account is simply not found — the check happens as the record is fetched, not after.

This is enforced through shared machinery rather than repeated by hand for each screen, and cross-account access is covered by an automated test contract that every part of the application is held to.

Access control

Four roles — member, admin, owner and account owner — with a single, shared definition of what each may do. Every action is checked against it. See Team & roles.

Underneath roles, individual fields can require a minimum role. Below that level the field is absent from forms, lists, filters and history, and the server refuses to accept a value for it. Because one rule decides all of those places at once, they cannot fall out of step.

Credentials and secrets

• Integration tokens — Gmail, Calendly and CAPTCHA keys are encrypted at rest.
• API keys — stored only as a keyed one-way digest. The key itself is shown once at creation and never again; revoking one stops it working immediately.
• Passwords — hashed, never recoverable, and required to include upper and lower case, a number and a symbol, with a minimum length of eight.

Accounts and sessions

• Email confirmation is required before an account can be used.
• Repeated failed sign-in attempts lock the account temporarily.
• Idle sessions time out.
• There is no open registration — access is by invitation only.
• Deactivating a member revokes their access on their next request.

Uploads

Files are checked against a content-type allowlist by inspecting their actual bytes, capped at 25 MB, and scanned for malware in the background. A detection quarantines the file for review and raises an alert rather than deleting it silently. Files are served through the application, so access is always checked.

Public endpoints

Public capture forms accept only the fields their own configuration defines. Post-submission redirects are restricted to ordinary web addresses. Optional CAPTCHA verification is performed on the server and fails closed. Incoming integration callbacks must originate from the provider's published address range and carry a valid signature, verified within a short replay window.

In the browser

The application ships a Content Security Policy restricting where scripts, styles, fonts, frames and network requests may come from. Values supplied by customers are escaped on output, and link fields are limited to http and https addresses so a form submission cannot plant a script URL.

Dependencies

The dependency set is checked against published security advisories on every build, and a build fails if a known vulnerable package is present.

What we do not claim

We describe controls that are implemented in the product today. We do not currently hold SOC 2, ISO 27001 or any comparable third-party audit, and we will not imply otherwise. If your review needs specific evidence, ask us and we will tell you plainly what exists.

Something inaccurate or missing? Tell us — we would rather fix the docs than have you guess.