Security and confidentiality

Your clients' matters stay your clients' matters.

Second Chair is built for work where a missed wall between two matters, or one unreviewed message, is a professional problem and not a product bug. This page says plainly what the system does, what it sends to an AI model, and what it will not do.

Isolation is enforced by the database, not by the application

Every firm's data lives behind Postgres row-level security that is switched on and forced for every table. Each request runs as an unprivileged database role scoped to one firm and one user. Even a defect in our own application code cannot read another firm's rows, because the database refuses before the application ever sees them.

Inside a firm, a matter wall applies the same way. A matter is visible to a person only if they are an administrator, the matter is open to the whole firm, or they have been granted access to it. Personal notes are invisible to administrators and to background jobs alike.

We prove this with automated tests on every change: a user at one firm and our own system worker both see zero rows from another firm across every table, and any attempt to write across a firm or matter boundary is rejected.

AI goes through one door, and every pass is logged

All model calls in Second Chair go through a single gateway. No feature can talk to a provider on its own. That one door records who asked, which matter it concerned, which model answered, the full response, tokens, cost and duration. Firm administrators can read that log, subject to the same matter wall as everything else. This is the monitoring that recent bar guidance on generative AI asks firms to have.

Only the record the asking person could already see is placed in a prompt. For a client update, that is the matter name, client, recent activity, upcoming dates and open commitments. Nothing is sent that the person asking could not read themselves in the app.

Clark, the assistant, must consult the firm's record before answering and marks any general knowledge separately from statements drawn from the record. Client-facing drafts may only restate the record. Clark does not give legal advice.

Bring your own API key

A firm can connect its own Anthropic API key in Settings. When it is set, every call for that firm uses the firm's key and the firm's own commercial agreement with the provider, never ours. The key is stored with envelope encryption and the application only ever reports whether it is set, never its value. Firms that use document search connect their own embedding provider key as well; there is no shared fallback for embeddings.

Without a key, every AI feature still works in a non-AI mode, such as plain full-text search and record-only summaries. No firm is forced to connect a provider to use Second Chair.

Dedicated model isolation through Amazon Bedrock

For firms whose policies require that prompts never leave a defined cloud boundary, we are building support for Anthropic's models served through Amazon Bedrock. On Bedrock, inference runs inside AWS, in the region the firm chooses, under the firm's own AWS account and private network endpoints, and AWS does not share prompts or completions with the model provider or use them for training. Second Chair's gateway design means switching a firm from the Anthropic API to Bedrock is a configuration change, not a rewrite. This option is planned for launch and is not available in the current pilot.

A person signs off before anything leaves the firm

Second Chair drafts; people send. A client update is a pending draft until a person approves the exact text, and the draft-to-approved-to-sent sequence is enforced in the database, not in the user interface. A deadline extracted by AI, or synced from a practice-management system, arrives unconfirmed and does not drive alerts until an attorney signs it off. Invoices are sent by administrators only, and sent content is frozen. Connected mail and document sources are read-only by construction.

An audit trail that cannot be edited

A database trigger records every change to a matter, field by field, with who made it and whether it came from a person, a background job or direct database access. The application can read the audit log but cannot write to it. Trust-account ledger entries, payments and reconciliations are append-only: updates and deletes are refused by the database itself, and a client or matter with trust history cannot be deleted.

Secrets and encryption

Firm API keys and integration credentials are protected with envelope encryption: a fresh AES-256-GCM key for each secret, wrapped by a master key that is read from the environment only when needed. Tampering with stored ciphertext is detected and refused. Sign-in uses Supabase Auth with optional two-factor authentication that a firm can require for all members. Data at rest is encrypted and all connections use TLS.

What we do not claim

We have not yet completed a SOC 2 or ISO 27001 audit of Second Chair itself, so we do not describe the product as certified. Prompts do go to an AI provider, and document text goes to an embedding provider, so we do not say that your data never leaves your systems; we say exactly what is sent and give you the choice of provider and key. The data sent is not anonymized. Our hosting providers hold their own attestations, which we are glad to share.

Questions

Security review requests, questionnaires and vulnerability reports: security@secondchairlaw.com