Last updated 30 August 2026
What Olilo does to keep your workspace separate, what it records, and the things it does not do. The uncomfortable parts are on this page too, because you would find them anyway.
Separation is enforced by the database, not by application code. Every table that holds your content carries a row-level security policy that denies by default, and the application connects as a role that has no power to bypass it.
Every request opens a transaction, sets the workspace it is acting for, reads that setting back, and refuses to run if it did not take effect.
A query written without the workspace scope fails the build rather than shipping, and the list of protected tables is re-derived from the schema on every test run so it cannot fall behind.
In Australia. The database and the application run in Amazon Web Services in Sydney. Model requests are served by Amazon Bedrock in Australian regions.
A request naming a model outside an Australian region raises an error and is refused. It is not rewritten into an Australian one, because a silent correction would hide an operator mistake instead of surfacing it.
Matter notes and audit entries are chained: each entry carries a fingerprint of the one before it, and the sequence has no gaps.
Triggers in the database enforce that, so it does not depend on the application behaving correctly. On the audit trail every update and every delete is refused. On matter notes every delete is refused, and the only update allowed is the one that marks a note as corrected by a later note, which the trigger accepts once and only while every part of the note it points at is unchanged.
So a note recorded in error is neither edited nor removed. You record a correction, the correction is appended, and the earlier note stays on the file marked as superseded.
Olilo platform staff can enter any workspace and read any matter, any document and any chat transcript in it.
There is no break-glass approval step, no notification to you when it happens, and no way to opt out. We are telling you this because your security reviewer would find it, and because a control we have not built should not be described as one we have.
The audit trail records changes only. There is no sign-in log and no read log, so the trail will not show you that a record was read, only that it was altered. Reading leaves no trace anywhere in the system today.
Deletion is impossible by construction, and it is the direct cost of the thing that makes the record worth having.
Every matter note and every audit entry is written into an append-only chain. Database triggers physically refuse a delete on both tables, refuse every update to an audit entry, and refuse any update to a matter note beyond the single write-once mark that records it as corrected by a later note. Foreign keys refuse to remove a row anything else refers to. That is what makes a matter file evidence rather than a document someone could have edited afterwards.
The consequence is blunt: a standard data return and destruction request cannot be performed against a matter's records today. If you need a contractual destruction commitment, tell us before you start, because it is not something we can quietly work around after the fact.
What we commit to instead: on request at any time, and on thirty days notice, you receive a verified export of each matter file in your workspace.
It is produced by the same mechanism the product already uses. Before a single byte is written, every note on the matter is re-derived link by link against its recorded chain, and every generated draft that carries a recorded fingerprint is recomputed and compared with the fingerprint taken when it was created. If a record does not match, the export is refused rather than produced. If a record has no fingerprint to check against, the refusal says that instead, because claiming a comparison that never happened would be its own kind of dishonesty.
What the verification covers: the matter's own note chain, and five kinds of generated record, being the investigation plan, the findings report, the show cause letter, the outcome record and the appeal outcome.
What it does not cover, stated so you do not have to discover it: the workspace-wide audit chain is reproduced as recorded rather than verified in the export, because that chain runs across every matter in the workspace and cannot honestly be verified one matter at a time. The evidence synthesis carries no recorded fingerprint, so it is reproduced as stored and is never presented as verified.
Files you uploaded to a matter are not inside the export document. Neither are workspace documents, chat transcripts or your knowledge base. If you need those as well, ask, and we will agree what a full handover contains before you rely on it.
A chain walk catches any alteration to a note that has a later note after it, because the later note no longer points at the right place. It cannot catch an alteration to the very last note if its fingerprint were recomputed at the same moment, because nothing points forward to it. That case is what the database trigger is for, and no check running over the same rows could detect it. We would rather say so than let the word verified do work it has not earned.
Anything Olilo reads from an uploaded document, a search result or a tool is wrapped and treated as data, never as instructions. If that text tries to change what Olilo is doing, it is noted as suspicious and ignored.
A workspace admin manages their own people from the settings page: change somebody's role, suspend them, or remove them from the workspace. None of it goes through us.
Suspending or removing somebody ends their access on their very next request and revokes their sessions in the same step, so access stops when you press the button rather than when a cookie expires. The one thing a workspace cannot do is remove its own last admin, because that would leave nobody who could let anybody back in.
Signing in creates a session that expires after thirty days. The settings page lists the sessions on your account and can end all of them except the one you are using. Ending a single named session on its own is not built.
Password reset is self-service from the sign-in page. The link is emailed and is never shown to whoever asked for it, it expires in an hour, it can be used once, and completing a reset revokes every session on that account including the one that asked.
Adding somebody is the half that is not finished. An admin can create an invitation and the person cannot act on it: the link is not emailed and is not shown to the admin who created it, so accounts are still provisioned by us. The settings page says so where the invitation is created, rather than leaving you waiting for an email that is not coming.
There is no two-factor authentication and no single sign-on. A password is the only credential.
There is no field-level encryption. Files you attach are stored in the database rather than in separate object storage.
There is no independent security certification. No audit under SOC 2 or ISO 27001 has been started, and we will not imply otherwise.
There is no status page, no published service level commitment, and no formal vulnerability disclosure channel.
If you think you have found a security problem, email your Olilo contact and say so in the subject line. We would rather hear it early and badly worded than late.