Opening your workspace…
Security model · v1.0 · May 2026
In Platform mode Lexware runs the app, the backend and the database, with firms kept apart by row-level isolation. Answers are drafted and checked with the firm’s own model key; there is no shared Lexware key to fall back on. Cloud and Self-host mode move questions, research runs and matrix runs onto a backend the firm runs, but on the hosted app the rest still goes through Lexware. The same code runs in all three modes; the sections below say who operates each hop.
§ 01
In Platform mode every request takes the same trip: firm browser → Lexware-hosted app → Lexware-operated backend → Lexware-operated Supabase, the firm’s model key. Lexware runs the app, the backend and the database. Firms are kept apart by row-level isolation, and the backend’s service role, which Lexware operates, can read firm data in order to do its work.
In Cloud and Self-host mode, questions, research runs and matrix runs go to the firm’s own backend. Before each one, the app asks the Lexware platform which backend your firm uses, sending the user’s sign-in token. Documents, matters, drafts, memory and settings still go through the Lexware platform backend. If the check fails, nothing is sent: the request stops with an error rather than falling back to Lexware.
Lexware leaves the path entirely only when the firm also runs this app itself, pointed at its own backend and its own Supabase project.
The browser holds one credential: the Supabase JWT. It never sees the service-role key, the Anthropic key, or any other secret. All calls from the browser hit Next.js /api/* routes that proxy the JWT to the backend.
§ 02
Vendor keys live in the firm’s firm_settings row and are read by the backend service-role connection only. Keys are never echoed in API responses, never logged in plaintext, and never embedded in client JavaScript.
The keys we expect a firm to provide:
If any are missing at startup, the backend refuses to boot and prints a checklist. We’d rather fail loudly than ship a half-configured system that silently leaks later.
§ 03
The drafter writes the answer with every factual claim wrapped in a <cite> tag. A separate verifier call, with a fresh context, sees only the draft and the retrieved source passages, never the drafter’s reasoning, never the user prompt.
The verifier reads each cite against the passage it points at. A cite the passage actually carries — quoted or fairly paraphrased — is marked Verified. Anything weaker is taken out of the answer before it reaches you, and the sentence it was holding up is marked Check this one.
That happens only when the check runs. When it cannot (the checker is unavailable, or the answer runs out of time), nothing is taken out: the cites are marked Not checked instead of Verified, and the answer says the check did not run.
This split is what makes the verifier’s grade trustworthy. The drafter cannot influence the verifier; the verifier cannot rationalize the draft.
§ 04
The audit log is append-only, RLS-gated to the firm, and writable only by the service role. Every routing change, every document upload, every cite verification writes a row. Reads by firm admins are themselves audited.
The schema captures: firm_id, ts, actor, action, target, meta (JSONB), ip. Routing changes record old → new transitions so the network path that holds firm data is always traceable.
§ 05
Platform
Lexware runs the app, the backend and the database. Firms are kept apart by row-level isolation; the backend’s service role, which Lexware operates, can read firm data. Your own model key drafts and checks every answer.
Shared, row-isolated
Cloud
You run the backend on your own VPS, behind your TLS certificate, and point the app at it in /settings/backend. Questions, research runs and matrix runs go to your backend. On the hosted app, the routing check and everything else still go through Lexware.
Firm-run backend
Self-host
You run the backend on a tailnet or on-prem server, reached only through your private network. On the hosted app, the routing check and everything other than questions, research runs and matrix runs still go through Lexware. Run this app yourself as well, against your own Supabase project, and no request needs to reach Lexware.
Firm-run, private network
§ 06
On the hosted app Lexware holds the contracts for the servers that run the backend and document processing (AWS), the tunnel in front of them (Cloudflare), the database (Supabase) and app hosting (Vercel). Model calls run on the API key the firm supplies, so they fall under the account that owns that key. Any other provider key a firm adds in settings works the same way. A firm that runs the app and the backend itself can contract with each provider directly.
| Provider | Purpose | Data exposed | Contracting party |
|---|---|---|---|
| Anthropic | Drafter + verifier inference | Prompt + retrieved passages | Owner of the key the firm supplies |
| CourtListener | Case search + citation verification | Citation strings, case names and search terms drawn from the question | Owner of the key the firm supplies |
| AWS | Backend + document-processing servers | Every question, document and answer the backend handles | Lexware on the hosted app, or firm |
| Cloudflare | Tunnel in front of the backend | Every request to the backend | Lexware on the hosted app, or firm |
| Supabase | Postgres + auth + storage | Everything, encrypted at rest | Lexware on the hosted app, or firm |
| Vercel | App hosting | Every request that passes through the app | Lexware on the hosted app, or firm |
§ 07
Operational telemetry, error reporting and product analytics, is strictly opt-in. With no environment variables set, no telemetry traffic leaves the firm.
When a firm chooses to enable error reporting, the DSN points to a firm-controlled Sentry org. Lexware ships no central telemetry sink. The DSN is added to the Content-Security-Policy connect-src at build time, so a browser cannot reach any telemetry host that the firm did not explicitly approve.
The on-the-wire scrubber, applied before any event leaves:
Product analytics (PostHog) is configured even more conservatively: identify uses a hashed firm ID + role only, IP capture is off, session recording is off, and only a small whitelist of custom events fires. The same opt-in env-var gate applies.
§ 08
In Platform mode Lexware holds firm data and the firm’s vendor keys, so a breach of Lexware infrastructure could expose them. Keys are never returned by the API, and are encrypted at rest only when the deployment sets an encryption key. Members’ own requests are limited by row-level security; the backend’s service role, which Lexware operates, is not. A firm that runs both the app and the backend itself, against its own database, keeps its documents off Lexware infrastructure; there the threat model treats Lexware code as untrusted third-party software running inside the firm’s perimeter.
Releases are signed and the changelog is public. Platform firms run the version Lexware deploys. Firms that run the backend themselves control when it upgrades and can pin a known-good version indefinitely.