BriefcaseEarly access

Security

The record that can’t be rewritten

Most vendors answer the security question with a certificate. Ours is a description of the architecture — because the properties a law firm actually needs are structural, and structure is checkable.

Your firm's data is isolated by the database itself

Every row in Briefcase belongs to a firm, and the database — not just the application — enforces that boundary on every query, using row-level security that fails closed. The client portal is a separate application with separate credentials entirely: the staff/client boundary is structural, not a checkbox.

History is append-only

Every change to a matter writes an event in the same transaction as the change itself, into a log that can only grow. Documents are versioned, never overwritten; an executed instrument is never edited. Your case record cannot be silently rewritten — by us, by a vendor, or by anyone in your firm.

Documents sit in write-locked storage, scanned before served

Files live in object storage with versioning and object lock, under per-environment encryption keys. Every upload is scanned for malware inside the cloud boundary — the file never leaves for a third-party scanner — and a file without a clean verdict cannot be opened. The application’s own credentials cannot delete a document; there is deliberately no deletion path.

AI with zero retention, and a human gate

AI features run through a gateway with zero data retention — your matters train nothing. Every output is held for a person’s approval, badged where it isn’t grounded in your record, and logged as the AI’s in the same append-only history as everything else. Each firm decides its own AI policy in its own settings; off means off.

Formal certifications will follow the usual course as we grow. The architecture above is true today, and we’ll walk any prospective firm through it in as much depth as they like.

Briefcase is in early access with a working firm on it today.

Request early access