Security
Who can get in, where the data lives, and how it leaves.
The answers a security review asks for, in the order it asks them, with the source of each answer named. Where a control is still being finished, this page says so rather than rounding up.
Access, and the record of it
Who got in,
and who was told.
Sign in with the identity people already have
SAML 2.0 against any identity provider, with a per-tenant entry point so a company's people land in their own tenant rather than in a shared front door. Passkeys for the device in somebody's hand, and a one-time email link for the people who have no work account at all.
Joiners and leavers come from the directory, not a spreadsheet
SCIM 2.0 provisioning creates the person, places them in a department, and deactivates them the moment the identity provider does. There is no separate offboarding step for somebody to forget on the day it matters.
Support access is a recorded act, not a shared password
An operator can open a support session as a named person, and that session is written down and then explicitly revoked. Nobody logs in as somebody else quietly, and there is no shared administrator account to rotate.
The administrative record is exportable
Every administrative action is written to an audit log that downloads as CSV, alongside a sign-out-everywhere control for the day that is needed. An emergency alert keeps its own delivery and acknowledgement records, so the question of who was reached has an answer.
- GET/auth/saml/meridian/login
the tenant's own front door - POST/auth/saml/meridian/callback
assertion verified, session minted ok - GET/auth/me
the person, and the tenant they are in ok - POST/scim/v2/Users
a joiner, created from the directory ok - PATCH/scim/v2/Users/41
active: false, access ends here ok - POST/admin/impersonate/12
support session opened, and recorded ok - POST/admin/impersonate/revoke
and explicitly ended ok - GET/admin/security/audit.csv
who did what, downloadable ok
Real endpoints, in the order they run. Tenant separation is enforced on the write paths and at sign-in; a number of list endpoints are still being brought behind it, and we do not claim it as finished until they are.
Where the data lives
In the United States,
with three named processors.
- Database and backups
- Supabase, in the United States.
- The application
- Fly.io, primary region sjc, in the United States. Both of its regions are in the United States, so a failover does not move personal data across a border.
- Sessions
- Upstash, in the United States.
- In transit and at rest
- Encrypted. Transfers from the United Kingdom and the EEA rest on the European Commission's Standard Contractual Clauses and the UK Addendum.
- Every processor
- Bound by contract to handle data only on our instructions. The full list is in the privacy policy, and it is the document that governs.
Source: the published privacy policy, and services/api/fly.toml for the region. Read the privacy policy.
Between customers
Separate front doors,
and one honest caveat.
- Sign-in
- Each organisation has its own SAML entry point, so its people land in their own tenant rather than in a shared front door. Passkeys for the device in somebody's hand, and a one-time email link for people with no work account.
- Tenant separation
- Enforced on the write paths and on sign-in. A number of list endpoints are still being brought behind it, and until that finishes we do not claim it as complete.
- Support access
- An operator can open a support session as a named person. That session is written down and then explicitly revoked, and an account can only be deleted by the person who holds it, never from inside a support session.
The second row is the same sentence the home page says under "things it would be easy to overclaim". It is repeated rather than improved.
Deletion and retention
A person deletes their own account,
and it cannot be undone.
- Deleting an account
- From inside the app, by the person who holds it, by typing DELETE. It takes effect at once and cannot be undone. The route is POST /auth/account/delete.
- Profile data
- Removed within 90 days of the account closing, unless the law requires it to be kept longer.
- Step totals
- The current and the previous calendar year, then deleted.
- Location
- Only the most recent position is stored.
- Diagnostic reports
- Kept for 90 days.
- Safety alert records
- Kept for three years, so the question of who was reached has an answer.
Retention periods are from the privacy policy. Where this table and the policy differ, the policy is right, and this table is wrong. Read the privacy policy.
What is not there
Four things a review
will not find.
- No advertising
- There is no advertising SDK in the app and it asks the phone for no advertising identifier. That is also the answer given to Google Play.
- No strangers
- Nothing in the service finds a person you are not already somewhere with. The one directory search belongs to organisations and returns only their own people.
- No public feed
- There is no global timeline to be on. A post belongs to one organisation or one circle and is read through it.
- No letting yourself in
- Accepting an invitation is the only thing that connects two people, and a test in the codebase goes red on the day anybody adds a second way.
Talk to us
Pick the world
you are in.
Tell us which of the four you are, roughly how many people, and what you use today. We will show you the product with your own vocabulary in it, and tell you plainly which parts of it are finished.