Trust and security

Vercel hosts the site and runs its server code in Sydney. Supabase holds the database and the stored files in Sydney (region ap-southeast-2). The privacy page lists what each one holds.

Resend, in the United States, delivers account emails and log-in links, and passes enquiries to the inbox.

These are the services the live site sends data to. Nothing is sold.

• Vercel: hosting, server code in Sydney, and page analytics.
• Supabase: accounts, saved records, enquiries and a firm’s files, in Sydney.
• Resend, United States: account and log-in emails, enquiries, and the change digest if you opt in.
• Have I Been Pwned: at sign-up, only the first five characters of a one-way code of the password are sent, to check it against known breaches. Nothing from the answer is kept.
• Clio: only when a person connects their own Clio login and files a record to a matter, the note and document go to Clio, in the region that person chose. Nothing is sent to Clio otherwise. See Clio on the privacy page.

The How we use AI page says that the public MCP server does not call an AI provider. The AI app you connect does that work, under its own provider’s terms.

Every page is served over HTTPS, and the site tells browsers to use only HTTPS for two years. Supabase states that all customer data is encrypted at rest with AES-256 and in transit via TLS (supabase.com/security).

The codes, tokens and keys that let an AI app reach a firm’s connector are stored only as SHA-256 hashes. The security record names a person only by a keyed one-way code, never an email address or a name.

Row-level security is switched on for every table in the database’s public schema. It means a signed-in person can read and change only the rows the rules allow, even if a request skips the site’s own code.

Two-step verification with an authenticator app is available to every account. A firm’s owner can require it for everyone in the firm. Once it is on for a person, their private rows are not readable from a session that has not passed it. An owner who has an authenticator app must enter a code to delete a firm.

The site keeps a security record of failed log-ins and codes, authenticator apps added or removed, changes to roles, members, invitations and firm settings, disconnected AI apps, downloads and firm deletions. A firm’s owners read their firm’s entries at Firm › Settings. The record is kept when a firm is deleted.

The firm connector also keeps an access log for one year. Request counts and availability checks are kept as operating history.

A firm’s owners and admins can download everything the firm keeps, at Firm › Settings. An owner can delete the firm there, after typing its name. Its policies, knowledge items, stored files and registers are deleted at once. Copies in the hosting services’ backups expire on those services’ own schedule.

To see, correct or delete other personal information, use Enquiries. The privacy page says how long each kind of record is kept.

Use Enquiries and start the message with “Security”. Say what you found, the address it affects and how to reproduce it. Do not include client or confidential information.

We aim to acknowledge a report within 5 business days (Australia/Sydney). We cannot offer a bounty. The full policy, including the rules for testing, is at /.well-known/security-policy.txt.

Three written security reviews were done on 17 October 2026: the firm workspace and knowledge base; the sign-in for AI apps and the firm connector; and firm approval, export and deletion, and two-step verification. Fixes followed, and findings that depend on settings at the hosting platform were recorded as open. A site review was written on 10 October 2026.

These are the project’s own reviews. They are not an independent audit or a certification.

It describes what the code and settings do on the date above. It is not a certification, an independent audit or legal advice. The privacy policy is the full statement of what is collected, and the AI due diligence page lists questions to put to any AI vendor.