Each control below is shipped and running today, not a policy we intend to adopt. The database scopes every firm’s rows, the server decides what a role may do on each request, provider keys never reach the browser, and a change to a role or an ethical wall is written to an audit trail with the person who made it.
Row-level security
Firm-owned records are scoped by tenant-scoped policies enforced in Postgres. The check runs in the database, on every read and write.
Roles checked on the server
Firm roles, from owner down to paralegal, carry per-module permissions. Authenticated server routes enforce them; the browser does not decide.
Secrets stay server-side
Provider keys and internal secrets are read on the server only. Provider-managed encryption at rest and encrypted transport cover the data path.
Role and wall changes are logged
Changing a member's role, raising or lifting an ethical wall, and exporting firm data each write an audit entry with the time and the person who did it.
Every record carries the firm it belongs to, and the database checks that firm before a row is ever returned, so a leak has to get past the engine rather than a forgotten filter in application code. The client portal is that same rule seen from outside: a client is shown the records the firm shared with them, and nothing else in the workspace.
Conflict screening raises a review event; it never changes access on its own. When an administrator applies a wall to a matter, the walled attorneys and staff cannot open it, search it, or confirm it exists at all. The check is row-level security in the database, so a walled person receives no rows rather than a greyed-out link that admits the matter is there.
- Applied per matter by an authorised administrator
- Walled people get no rows back, not a greyed-out link
- Raising or lifting a wall is itself an audited event
AI requests go server-side to the provider the firm configured, on the firm’s own key if it has one. LawAOS does not use firm content to train its own models. Each provider has its own retention, region and contractual terms, and the firm reviews them before client-confidential material is sent.
- Multiple providers supported, including firm-provided keys
- Using an AI feature does not by itself establish or preserve privilege
What leaves the firm's workspace, what never does, and the terms attached to each. Firm content is not used to train our models, and a firm administrator can export the records they are entitled to at any time.
- Firm data is not used to train LawAOS models
- Provider-managed encryption at rest and encrypted transport
- Service providers receive only the data needed for the configured service
- Supported record exports for authorised firm administrators
- Postgres row-level security scopes tenant-owned records
Live means shipped and enforced today. Roadmap means not yet built. Nothing on this list is implied, and every certification we do not hold says so in as many words rather than hiding behind a logo.
Applied per matter by an authorised administrator and enforced by row-level security. A walled person cannot open the matter or confirm it exists.
Role changes, ethical-wall changes and firm data exports are logged with the actor and time. Per-module permission toggles are not yet audited; a compliance review should know that.
Supported record exports are available to authorised firm administrators. Firm data is the firm's to take.
We do not hold a SOC 2 attestation. It is on the roadmap, and we would rather say so than imply otherwise.
Our practices draw on ISO/IEC 27001. We do not hold the certification.
SCIM v2 lets a firm's identity provider invite, update and deactivate members, with a bearer token issued in Settings, Provisioning. Firm roles are exposed as read-only groups.
Not yet available. Sign-in today is email and password or a magic link. Google is available only when creating a new firm. The client portal has its own links.
Each member can turn on two-factor sign-in with an authenticator app (TOTP); once on, every sign-in requires the code. A firm administrator can require two-factor for every member, with a grace period; after it, a member without a verified authenticator is refused data access until they enrol. Hardware keys are not yet available.
Not yet available. Planned as firm-set ranges for offices and VPN exits.
The shared deployment runs one configured database region (Asia-Pacific, Sydney). Residency, processing terms, retention and data-subject workflows are reviewed and documented per regulated deployment.
Firms holding protected health information complete a security, provider and contractual review before storing it. The public application does not claim HIPAA compliance by default.
Access and deletion requests from California residents are handled through support. Broader workflows are documented per regulated deployment.
Each control names the code or database migration that implements it. Reviewers can inspect those references under NDA. Partial means the tooling exists but a published commitment does not.
Firm-owned tables carry a firm_id and row-level security policies scoped to the caller's visible firms. The check runs in Postgres on every read and write, not in application code.
Evidence reference
supabase/migrations/20260803000010_scope_rls_to_the_active_firm.sqlsupabase/migrations/20260801910000_rls_static_audit_and_the_is_admin_self_grant.sqlapps/web/lib/rls-once-per-statement.contract.test.ts
Members can enrol an authenticator app (TOTP). A firm can require two-factor for every member after a grace period. Enforcement is a database boundary: a pre-request hook and a restrictive policy on every row-level-secured table refuse an unassured session.
Limits: Hardware security keys and SAML single sign-on are not available.
Evidence reference
supabase/migrations/20260930100100_session_assurance_boundary.sqlsupabase/migrations/20261014110000_two_factor_required_after_thirty_days.sqlapps/web/lib/auth/session-assurance.ts
An administrator can bar named people from a matter. Row-level security returns no rows to a barred person, so the matter is not shown to them at all.
Evidence reference
supabase/migrations/20260621000024_audit_w3_ethical_walls_privilege.sqlsupabase/migrations/20260726000041_matter_visibility_rls_leaks.sql
The record-level and security audit trails are sealed every minute: each batch of rows is hashed into a Merkle tree and the seal is chained to the previous seal, so an edited or removed row is detectable.
Limits: Sealing proves tampering after the fact; it does not prevent a database owner from altering rows.
Evidence reference
supabase/migrations/20261018110000_audit_seals_tamper_evident.sqlapps/web/app/api/cron/audit-seal/route.tsapps/web/lib/audit-integrity/proof.ts
Data at rest is encrypted by our hosting provider (Supabase, on AWS). Traffic is served over TLS. Stored third-party credentials (firm AI keys, integration tokens) are additionally encrypted by the application before they are written.
Limits: Customer-managed keys (BYOK) are not available.
Evidence reference
apps/web/lib/ai/key-crypto.tsapps/web/lib/integrations/credential-crypto.tssupabase/migrations/20260812202100_vault_wrap_legacy_smtp_credentials.sql
Scripted database and file-storage backup, restore and recovery-drill tooling exists, with a written runbook that measures recovery time only after restored data is verified.
Limits: We do not publish a recovery-time or recovery-point commitment yet; drill results are shared under NDA when available.
Evidence reference
scripts/recovery/backup-database.shscripts/recovery/restore-database.shscripts/recovery/run-recovery-drill.shdocs/RECOVERY-DRILL-RUNBOOK.md
Sign-up, invitation acceptance, password reset, client-portal sign-in links, public forms, SCIM and AI routes are rate-limited in the database. For those routes a limiter that cannot answer refuses the request rather than allowing it.
Evidence reference
supabase/migrations/20260614000010_db_backed_rate_limiter.sqlapps/web/lib/ratelimit.ts
A firm's identity provider can create, update and deactivate members through SCIM v2 with a firm-issued bearer token.
Limits: SAML / OIDC single sign-on is not available yet.
Evidence reference
supabase/migrations/20260621000034_scim_provisioning.sqlapps/web/lib/scim/scim.tsapps/web/app/api/scim/v2
Authorised firm administrators can export the firm's records; exports are logged.
Evidence reference
apps/web/lib/exit-kit/exporter.tsapps/web/lib/exit-kit/audit.ts
Firms accept a versioned DPA in the product. The acceptance records the exact text hash, signer and time, and cannot be edited afterwards.
Evidence reference
supabase/migrations/20261017160000_gdpr_dpa_acceptance_and_consent.sql
Sub-processors are listed per region cell with purpose, data categories and region, with a dated change log and a way to ask to be told about changes.
Evidence reference
apps/web/lib/trust-center/subprocessors.tssupabase/migrations/20261026090000_w52_trust_center.sql
In progress means planned, with no date promised. Our sub-processors are listed per region with a dated change log, and the data processing agreement page shows its current version.
An annual third-party test is planned. No report exists yet.
Not available.