Perlance security

How Perlance keeps an organisation's work safe. The public page at https://docs.perlanceai.com/security is built from this file, and the facts in section 8 are checked against the service's settings by npm test and by every deploy (tests/security-doc.test.ts, scripts/deploy.ts). Change the settings and this file together.

1. How people sign in

Everyone signs in with their work Google account, through WorkOS AuthKit. Perlance never sees or holds a password.

• In Claude, the connector sends people to the AuthKit sign-in page the first time. Claude then holds a short-lived token and renews it itself.
• In the app at app.perlanceai.com, the same sign-in. The tokens are kept in the page's memory only and are gone when the page closes; nothing is written to the browser's storage except a one-time value that lives for the length of the sign-in redirect.
• On every request the service checks the token before anything else: its signature (AuthKit's published keys), its issuer, its audience (the connector's address) and the email in it (the claim named in section 8). A request without a valid token is refused with 401.
• Then the person: the email must belong to an organisation, be in one of its allowed email domains, and belong to an active person in it. Removing a person takes effect on their next request.

2. What Perlance stores, and what it never stores

Stored, in the organisation's own database: the people (name, work email, who they report to, title, team, admin or not); the structure (nodes, roles, who holds which role); each role's brief and the links in it; the working context and node contexts that Claude saves; session logs (what was done and what is next); items between roles (a one-line summary and the full text); a record of every change (who, when, what); and usage events for billing.

Never stored: chat transcripts; files (working documents stay in Google Drive, and Perlance keeps only the links people put in a brief or an item); anything Claude reads or writes elsewhere; passwords; Google or Claude account tokens.

There is no AI inside Perlance. Each person's own Claude does the work and decides, with the person, what to save; Perlance stores what it is given and enforces the rules.

3. One database per organisation

Every client organisation has its own Firestore database. A small shared directory only maps a person's email to their organisation. Only the service reads or writes any database: the databases' own access rules refuse every request from anywhere else, and tests that try to reach one organisation's data from another must fail on every change.

Inside an organisation, a role's private working context is read only by that role's own sessions in Claude and, in the app, by the people who hold the role. Leads and managers see states and counts, never another role's private context.

4. Records that are only added to, and saves that are checked

The record, session logs, item events, earlier versions of contexts and briefs, and usage events are only ever added to; nothing in them is changed or removed. Every change is written together with its record entry, in one step: if one fails, neither is written. Saves to a context are version-checked, so two people saving at once cannot silently overwrite each other; the later save is refused and handed the latest. The service, not Claude, writes who did something and when.

5. The operator console

Threadwell operators run Perlance from a separate console at admin.perlanceai.com. Operators sign in with Google, must have a verified email, and must carry the operator mark, which the service reads fresh on every request, so a removed operator is refused at once.

Operators see the directory (each organisation's name, status, allowed domains, tier and first admin's email) and figures: how many active people, when the organisation was last active, and its usage events. They never see an organisation's working data: no briefs, contexts, logs, items or people's details. Every operator change is recorded.

6. Where things run

The service runs on Google Cloud Functions in the region in section 8. The databases are Google Firestore, in the location in section 8. The app, the console and these pages are served by Firebase Hosting. Google encrypts the data at rest and every connection is HTTPS. Sign-in is run by WorkOS.

7. How to report a problem

Write to security@perlanceai.com. Say what you found and how to see it; please do not test against another organisation's data.

8. The facts, as the service holds them