Security and data: what happens to your client conversations

Where it runs

You choose. Sealbook is one Docker image and a database.

On your own server or cloud account: transcripts never leave your network, and we have no access to them. This is how pilots run by default.
Hosted by us: we run it for you. Transcripts are on our server, isolated from every other firm. See "Who can read it" below for what that means today.

Who can read it

Your firm's people see your projects. Your client's people see only items shared with them; internal notes and internal meetings never appear on their side.
Another firm on the same server gets "not found" on every page and API route of your project. This is tested automatically on every change.
People sign in through your own identity provider (Microsoft Entra ID, Okta, Google or any OpenID Connect provider), and only people an administrator added can get in.
Clients confirm from email links that are signed, personal, tied to one wording, and expire. A link stops working the moment the wording changes, and opening it records nothing (email scanners open links).

Today, honestly: on a server we host, the transcripts are stored in the database as text. Someone with administrator access to that database could read them. We are adding encryption with a key only your firm holds, so that transcripts are unreadable to us even on our servers. Until that ships, if your client needs "the vendor cannot read it", run Sealbook on your own server.

Encryption

In transit: always HTTPS, with HSTS so browsers refuse plain connections.
At rest: the hosting disks and databases are encrypted by the provider. Field-level encryption of transcript text, with your key, is in progress (see above).
Webhooks you send to your own systems are signed, so you can verify they came from Sealbook. Webhooks are never sent to private network addresses.

The AI

Sealbook has two readers. The rule-based reader runs entirely inside Sealbook; nothing leaves the server.
The Claude reader is optional and off unless your administrator turns it on with your own API key. When it is on, transcript text is sent to Anthropic's API to be read. Under Anthropic's commercial terms, API inputs are not used to train models. If your client's policy says no third-party AI, leave it off.
Whichever reader runs, its output is checked by the server: quotes must match the transcript word for word, owners and dates nobody said are removed, and nothing can be marked approved. Instructions hidden in a transcript are flagged and ignored.

Tamper evidence

Every action is written to a hash-chained record. Each entry includes a fingerprint of the one before, so changing any past entry breaks the chain. Fingerprints of the record go out in receipts and exports both sides keep, so even someone with full database access cannot rewrite history unnoticed.

Protection against misuse

A strict content security policy: the app runs only its own scripts. A test fails the build if an inline script ever appears.
Rate limits on every request and lockout after repeated failed sign-ins.
Every dependency checked against public vulnerability databases; none known.

Keeping and deleting

Export a whole project at any time, in a documented format.
Delete a project with everything in it. Or archive it and set it to delete itself after a number of days.
Backups can be restored only if the record's chain still checks out, so an edited backup is refused.

What we don't have yet

A SOC 2 report or an independent penetration test. Both are planned before the first large contract. Until then, the security write-up lists every control with the automated test behind it, and we are happy to answer your security questionnaire.

Questions from your client's security team: hello@getsealbook.com.

What happens to your client's words