A client’s papers are privileged. We hold them that way.
What follows is what the product actually does. Where a control does not exist, it is not listed: a security page that promises something the code has not got is worse than no page at all.
Six of them, and all six are in the product today.
One workspace, checked in one place
Every record (a matter, a date, a clock, a note, a draft) carries the firm it belongs to, and the workspace is read from the session rather than from anything the browser sends. It is enforced by one module that every write goes through, so it cannot be forgotten on the eighth screen.
Row level security, with no policies
Every table has row level security on and no policy granting access, which means the anonymous and signed-in database roles read nothing at all. Reads and writes happen through our server with the service role, after the workspace check above. A leaked public key gets a stranger nothing.
A matter can be closed to the firm
By default everybody in a practice can reach its matters, which is how a practice works. A sensitive file can be set to named people only, and then it does not appear in lists, in search, or in anybody else’s answer. It returns "not found" rather than "forbidden", because the existence of the matter is itself the thing being kept.
Papers open through links that expire
Documents are stored in object storage that is not publicly readable. Opening one mints a short-lived link for that one file, so nothing is left lying around in a browser history or a shared address.
Two factors, and a way to shut the others out
An account can require a code from an authenticator app as well as a password, and every other signed-in device can be signed out in one press from Settings.
Everything that happened, written down
Who opened a matter, who moved a clock, who approved a draft, who invited whom, and what arrived by email and from where. An admin can read the log and download it. The question log, page views and the activity log are kept for 12 months unless the firm sets a different period, and anything older is deleted nightly. Database backups expire after 30 days.
Three things, plainly.
We do not train any model on your papers. A document is sent to Google when it is uploaded, to be read, indexed, embedded and summarised, and its passages are sent again when your own firm’s question needs them. That is the whole of their use. They are not used to answer another firm’s question, and under Google Cloud’s terms Google does not train its models on them.
We keep only the generated text you asked to keep. The question is logged, because that is what lets a firm see what it is spending on. The answer on the research and ask screens is not stored. What is stored is the generated text that a feature exists to keep: the questions and answers in a client space, the answers in a review table, and document summaries. They sit with the firm’s records and are deleted with them.
We do not read your messages. An admin can decide who in the firm may message whom. They still cannot read what was written.
Every processor, and what it sees.
Running this service means using other people’s infrastructure. This is all of it, and what each one handles, and where. Each one acts under its data processing terms; for Google that is the Google Cloud data processing addendum, under which customer data is not used for training. The privacy notice sets out the transfers out of Sri Lanka in full.
Taking your data out
Settings has an export of everything the firm holds (matters, notes, dates, clocks, drafts and the ledger) and a separate, final button that deletes the account. The export is offered before the deletion on purpose.
The rest in writing
The privacy notice says what we hold and why, and the terms say what we owe each other.