Security designed for privileged data

Every firm's records carry the firm they belong to. Every read or write of a firm-owned table must name a firm, or it is refused (in production, a read without one throws instead of returning anything), and the application takes that firm from the signed-in user's session. The check makes sure a firm is named; choosing the right one is the job of the code that builds each query. Hand-written SQL, and system paths that must work before anyone signs in or across firms (backups, webhooks, pages opened from a signed link, sign-in callbacks), sit outside that automatic check and scope their queries by firm themselves.

That check lives in the application. There is no second, database-level layer beneath it yet, so we treat it as the part of the system that must never regress: integration tests run on every change and confirm that firm A cannot read firm B's matters, time entries, invoices or trust records, and a second sweep checks that people inside a firm see only the matters they are entitled to.

• In transit: HTTPS only — TLS 1.2 or newer (TLS 1.3 whenever your browser supports it), with HSTS, terminated on our own server with Let's Encrypt certificates. The connection to the database also requires TLS.
• At rest (database): Microsoft Azure encrypts the Postgres instance at rest using AES-256.
• At rest (field-level): Fee agreement bodies, encrypted backups, and any field marked "privileged" are additionally encrypted at the application layer using AES-256-GCM with per-record random IVs and versioned keys for rotation. Even a full database dump does not reveal privileged communications without the application key.
• Backups: Per-firm encrypted backups stored in Cloudflare R2. SHA-256 checksum verification on every restore.

• Authentication handled by Clerk (SOC 2 Type II certified).
• Two-factor authentication is enforced for all active firms outside of trial accounts — paid plans and the free Starter plan alike — for every attorney and firm administrator. A firm administrator can require it for everyone else on the team as well.
• Session timeout and idle disconnect.
• Rate limiting on auth endpoints (5 attempts per 15 minutes per IP) to prevent credential stuffing.
• Firm-configured IP allowlist (IPv4 CIDR ranges) on the Enterprise tier, enforced in middleware on your firm's dashboard routes. Client-portal access is deliberately outside it, so your clients can still reach their own matter from anywhere.

• Seven roles (FIRM_ADMIN, ATTORNEY, ASSOCIATE, PARALEGAL, READ_ONLY, CLIENT, and EXTERNAL_COLLABORATOR for outside co-counsel and experts, each seat scoped to a single matter) with 60+ fine-grained permissions.
• Trust account disbursements restricted to ATTORNEY and FIRM_ADMIN. This is a Trial Commander control, not a Bar rule: Rule 5-1.2(c)(1) requires a multi-lawyer firm’s written trust plan to name each signatory, but the trust-account rules (RRTFB chapter 5) do not say which staff may record a withdrawal. Enforced at the action level, not just UI.
• Matter-level access: associates and paralegals see only matters they're assigned to.
• Client portal is strictly scoped: clients see only matters where they are the client, and only a restricted subset of fields (never privileged strategy, never time entry narratives, never internal mediation notes).

Every significant action (trust transactions, fee agreement changes, invoice void, user role changes, data exports) is logged with SHA-256 hash chaining per firm. Each event's hash includes the prior event's hash, creating a Merkle chain that can be verified for integrity.

Alter a record without recomputing every hash after it and the chain breaks, which nightly verification reports. Recompute them all and the chain looks clean — so every night we also publish a fingerprint of each firm’s log into the Bitcoin blockchain, where nobody can reach back and change it, including us. A rewrite of anything covered by one of those fingerprints can be proven against a public record.

What that is and is not: it is tamper-evident, not tamper-proof. It shows that a record was altered or removed; it does not prevent it, and it does not establish when an entry occurred — the clock is the application’s. Entries written since the last nightly fingerprint are not covered yet.

All AI features (fee petition generator, assistant, document generator) route through the Anthropic API, which never uses your data to train models. Retention is strictly limited — zero once our Zero-Data-Retention configuration is active, and never more than Anthropic's ~30-day operational window before then. The current mode is always stated in our AI disclosure. Firms can also require zero retention (which pauses the firm's cloud AI until it is active) or bring their own Anthropic key.

In the assistant, the fee petition and the analysis tools, text is passed through a filter that masks patterns that look like Social Security, card and long account numbers before it is sent. It is a pattern filter, not a guarantee, and features that must read a document as written — drafting, document review — send it as written. System prompts treat user input as data, not instructions. Every AI call is audit-logged with metadata (tokens, stop reason, feature), not content.

• Daily encrypted backups with 30-day retention. Every day each firm's latest backup is downloaded again, its checksum recomputed and its decryption tested automatically. Full restore rehearsals are run by hand, not on an automatic schedule.
• Nightly audit chain verification. Alert on any integrity break.
• Dependabot security alerts and weekly dependency updates, static analysis (ESLint and TypeScript), and an automated test suite on every change.
• Production secrets are held in Azure Key Vault and loaded onto the server at start-up — never in code.
• Strict Content Security Policy, HSTS, X-Frame-Options: DENY, and other security headers on every response.
• Rate limiting on all API endpoints, tighter limits on AI and export endpoints where costs are higher.

• The application runs on a single Microsoft Azure virtual machine in the United States, with the database on Azure Database for PostgreSQL and documents and backups in Cloudflare R2.
• There is no separate web application firewall, load balancer or automatic failover in front of it today. If the server goes down, the service is down until it is restarted or rebuilt; backups are what protect the data.
• An automated check outside our own server tests the site every hour and e-mails us when it fails. That is not round-the-clock staffing: we are a small team and respond as fast as we can.

We commit to notifying affected customers within 72 hours of confirming any security incident affecting their data. This exceeds the Fla. Stat. § 501.171 30-day requirement for consumer notification.

Report a security vulnerability: security.txt

• We don't sell or share your client data. Ever. Not to advertisers, not to AI training, not to "partners."
• We don't hold your data hostage. A firm administrator can download all of the firm's records — matters, clients, time, billing, trust and the audit log — at any time as one JSON file, and matters, time and trust records as CSV. Uploaded documents are not in that file: they are downloaded from each matter — and, once a firm has canceled, from its Billing page, read-only, until its data is deleted. When a firm cancels, we e-mail its administrators a reminder to download its records and documents, and its data — trust records and documents included — is deleted no sooner than 30 days after cancellation, and not while a matter is under litigation hold.
• We don't use your matter data to train AI models.
• We don't claim to be SOC 2 or HIPAA certified pre-launch — we'll report when we achieve these and what the scope is. No third-party security audit or penetration test has been performed yet either.