Skip to main content

Documentation

Security

Advisory work runs on sensitive client material, so security is built into how LithicBlue works rather than bolted on. Here's how your data is protected.

Encryption

All data is encrypted at rest with AES-256 and in transit with TLS 1.2+ (with certificate validation), so your material is protected at every step.

Your data and AI

  • Never used for training. Your data is not used to train AI models. We hold enterprise agreements with our AI providers that contractually prevent training on your data and limit retention to what's needed to process a request.
  • Project isolation. Each project is isolated, and access follows your existing permissions, including the permissions on connected SharePoint or Google Drive folders, so people only see what they could already open.

Compliance

Our security practices are designed to meet enterprise requirements from day one. We are actively pursuing SOC 2 Type II and ISO 27001. Current documentation, status and reports are available in our Trust Center.

Protected documents

Sensitivity labels. Where your organisation uses Microsoft Purview sensitivity labels, LithicBlue respects them. A label that only adds a visual marking — a header, footer or watermark — makes no difference; those documents are analysed as normal. A label that encrypts the document means LithicBlue cannot read it, so it is marked as protected rather than analysed. LithicBlue does not attempt to remove or work around that protection, and there is no password you can supply for it: the fix is a change to your Purview policy, made by whoever administers it.

Password-protected documents. These are not read unless someone supplies the password. Two separate things then happen, and LithicBlue keeps them apart deliberately.

  • Analysing the document. The password you enter on the file is stored encrypted so the document can be re-analysed whenever it changes — a synced file is re-read every time its contents are updated, and re-prompting each time would make the feature unusable. It is never displayed back to anyone. LithicBlue records who supplied it, because doing so makes that document's insights available to everyone on the project.
  • Reading the document itself. Opening the original file in the viewer asks the person reading it for the password, every session. The stored password is not used for this. That is the distinction: analysing a document produces insights your project agreed to share, but the document itself stays behind the protection your organisation put on it — LithicBlue does not become the way around it.

Removing a password. A stored password is deleted when you remove it or when the file is deleted. Removing it also removes everything read from the document, since it can no longer be re-read to check any of it. You can remove one if you run the project, if you can supply the password, or if it has stopped opening the file — that last case covers a document whose password has since been changed.

Your password is only ever sent when you supply it. Opening the document afterwards proves you know it without sending it again. Downloading always gives you the original protected file, which your reader program will ask you to unlock.

Hosting and data residency

LithicBlue runs on regional deployments, and for firms with specific requirements we offer dedicated tenancy, geographic / data-residency and embedded hosting options. If your organisation has compliance or residency constraints, talk to us at [email protected].

Access and authentication

  • Single sign-on. Sign in with Google or Microsoft SSO so your team uses existing corporate credentials; email and password (with verification and reset) is also available.
  • Guessing protection. Repeated failed email-and-password sign-ins on an account are limited, and once the limit is reached the account temporarily stops accepting email-and-password sign-in — Google and Microsoft SSO are unaffected. Resetting your password from the sign-in page restores access straight away.
  • Roles. Access is governed by organization and project roles, so each person only gets what their role allows.
  • Connectors act as you. When you connect an AI assistant over MCP, it authenticates as you via OAuth and can only reach projects you're a member of, never more.

Reporting a vulnerability

We run a Vulnerability Reward Program and welcome reports from the security community. See the program details, or email [email protected].

Questions about security?

For security reviews, questionnaires or enterprise requirements, reach out to [email protected] or your account contact.