Built for the data your clients trusted you with.

Isolation is enforced by the database, not by application code remembering to filter. Every tenant table carries PostgreSQL row-level security policies keyed to the firm and the signed-in user, so a query from one firm structurally cannot return another firm’s rows. The platform’s automated test suite creates two firms and proves, on every change, that neither can read or write the other’s data.

The one deliberate cross-firm surface, the referral network, is opt-in by publishing a directory profile, shares a sender-authored snapshot rather than the underlying matter, and gates client identity behind the referral’s state: withdrawn or rejected means access is revoked structurally, not by convention.

Before any text reaches an AI model, direct identifiers, names, companies, email addresses and phone numbers, are replaced with opaque tokens. Third-party names remain, because conflict screening needs them. Real values are restored only inside your workspace, for your team.

This is enforced twice. At compile time, the function that calls the model only accepts a de-identified type, so code that tries to pass a raw enquiry does not build. At run time, a tripwire scans the outgoing payload and refuses the request if a known identifier appears. AI output is stored append-only and versioned, marked as AI-generated, and drafted content is published by a person, never automatically.

Leads, matters, referrals and agent runs each carry an event timeline. Status history is written by database triggers in the same transaction as the change itself, and those history tables reject updates and deletes even from privileged roles. There is no authenticated hard delete anywhere in the schema; records are revoked or soft-deleted, so the trail survives.

Automated agents run with an allowlist of tools, make exactly one de-identified model call per execution, write every step to the record, and propose actions for a person to review rather than acting alone.

Access follows six organisation roles from owner to viewer, checked in database policy and again in application capability checks for sensitive actions. Machine access uses opaque random tokens, shown once and stored only as a hash: intake keys for enquiry ingestion and personal calendar feed tokens, both revocable at any time and never hard-deleted. Telephony webhooks are signature-verified.

Encrypted traffic can be recorded now and decrypted years later, once quantum computers arrive. The platform treats that as a present risk, not a future one. Client documents are sealed to the NIST post-quantum standards at every step of their path: in the browser before upload, at rest per firm after a clean malware verdict, and again on the way back out to a reader.

Each document receives a fresh AES-256-GCM content key, wrapped under a secret derived from two encapsulations to the firm’s stored keypair, X25519 and ML-KEM-1024, combined through one HKDF. Breaking the seal means breaking both. Downloads are sealed to one-shot keys generated in the reader’s tab and never sent to the server, so a recording of the wire is useless even to someone who later obtains every key the server holds. The three envelope contexts, at rest, upload and response, are domain separated so material from one can never be replayed in another.

Audit checkpoints are signed three times, with ML-DSA-87, SLH-DSA and Ed25519, so the record stands even if one family of mathematics falls. And because every copy of a firm’s ciphertext depends on that firm’s keys, destroying those keys on departure makes the data permanently unreadable, backups included.

All traffic is served over TLS, with the sealed envelopes above running inside it. Data is encrypted at rest by the database provider, which also manages backups, and client documents carry their own per-document seal on top. The hosting region is fixed per deployment and recorded in the data processing agreement we sign with each firm, alongside recovery commitments.

Where configured, Upstash provides shared rate limiting and sees request keys only. Firms are notified of sub-processor changes under the data processing agreement.

A data processing agreement template aligned to UK GDPR Article 28, including the sub-processor list above and the technical measures on this page as schedules, is available on request and lives in the platform’s documentation. Questions from a compliance review are welcome: security@lornevale.com.