What you control
| Control | Where | Notes |
|---|---|---|
| Two-factor authentication | Settings → Security | TOTP. Disabling requires a current code. |
| Active sessions | Settings → Security | Revoking one signs you out of every module. |
| Password | Settings → Security | Changing it does not revoke other sessions — do both. |
| Members and roles | Settings → Members | The most important control in the list. |
| Module access | Admin → Module access | Restrict-only, per person. |
| API keys | Settings → API keys | Organisation-scoped. Revoke rather than rotate in place. |
| Audit log | Admin → Audit log | Read it monthly. |
Tenancy isolation
Every record in every module carries an organisation, required, with no default. Modules mirror your organisation into their own storage keyed on the shell id, and a hand-off token names exactly one organisation and one module — a token minted for one module is refused by every other, and a token for an organisation a module is not willing to provision is refused outright.
A module that links an incoming person to an existing local user by matching their email address, rather than by the identity in the token, can attach somebody to the wrong tenant's record. That pattern has been found and removed where it existed, and it is the specific thing any new module integration is reviewed for. If you ever see data from a company that is not yours, stop and mail [email protected] immediately — it is the highest-severity report we take.
Sessions and sign-out
Because the suite shares one origin, one cookie authenticates you to the shell, and each module mints its own session after the hand-off. That has a practical consequence for offboarding: removing somebody's membership stops new hand-offs but does not necessarily end a module session already issued.
Settings → Members. This stops any new module entry.
The reliable half. Without it, an existing module session may run to its own expiry.
Keys are organisation-scoped, not personal, so a leaver who had one still knows it.
Confirm nothing happened after the departure date.
API keys
API keys are created per organisation in Settings → API keys, shown once at creation, and stored hashed. They act for the organisation, not for a person, which is why the audit trail for a key names the key rather than a human. Treat them as shared secrets: one key per integration, named for the integration, revoked when it is retired. See Authentication.
API keys
| Name | Prefix | Created | Last used | Status |
|---|---|---|---|---|
| Bank importer | erp_live_8f2c… | 12 Jan 2026 | 2 hours ago | Active |
| Data warehouse | erp_live_41ba… | 3 Feb 2026 | Yesterday | Active |
| Old Zapier | erp_live_c093… | 8 Nov 2025 | 4 months ago | Revoked |
What we control
- TLS on every origin, with certificates managed automatically.
- A web application firewall in front of the whole estate.
- Passwords stored hashed; API keys stored hashed; secrets held as deployment configuration rather than in the database.
- Per-module databases with no cross-module foreign keys, so a fault in one module cannot corrupt another's records.
- Backups of every module database, and restoration tested by actually restoring rather than by assuming.
Mail [email protected] with the URL and what you saw. Suspected cross-tenant data exposure is treated as the most severe class of report and is looked at immediately rather than triaged.
What this does not do
TOTP is the second factor. Hardware keys are not supported.
You cannot restrict sign-in to a network range.
You can turn MFA on for yourself; you cannot require it organisation-wide.
Session length is set by the platform, not by the workspace.
Encryption at rest is managed by us and is not customer-configurable.
Questions
Do you have SOC 2?
Ask [email protected] for the current position rather than trusting a page that may be stale.
Where is data stored?
One region today. Residency is not selectable — see Architecture.
Can we get a penetration test report?
Ask. It is handled under NDA.