Security model · v1.0 · May 2026
The firm holds the keys.
Lexware is built so that no vendor key, JWT, or client document ever transits a Lexware-controlled server. The architecture below is the rule, not the marketing copy, the same code runs in all three deployment modes.
§ 01
Data path
Every request follows the same trip: firm browser → firm Vercel app (or VPS) → firm backend → firm Supabase, firm Anthropic key, firm CourtListener key. Lexware as a vendor never sits on the path.
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
Key handling
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:
- Anthropic API key, drafter and verifier model calls.
- CourtListener API key, citation verification.
- Google OAuth client (and optionally Microsoft), sign-in.
- Supabase project URL + service key, data plane.
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
Drafter / verifier split
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 grades each cite as exact_quote, fair_paraphrase, loose_paraphrase, or unsupported. Anything below fair_paraphrase is stripped from the answer and the surrounding sentence is downgraded to amber.
This split is what makes the verifier’s grade trustworthy. The drafter cannot influence the verifier; the verifier cannot rationalize the draft.
§ 04
Audit log
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
Deployment modes
Platform
Vendor-hosted backend
We run the backend pool. Your Supabase, your Anthropic key, your CourtListener key, set in your environment. We have no production access to firm data.
Standard isolation
Cloud
Firm-hosted VPS
You run the backend on your own VPS, behind your TLS certificate. Point the Next.js app at your URL via /settings/backend. We have no production access.
Sovereign isolation
Self-host
Tailnet / on-prem
You run the backend on a tailnet or on-prem server. The Next.js app connects only through your private network. Air-gappable; no Lexware egress required.
Maximum isolation
§ 06
Subprocessors
By default Lexware has zero subprocessors of its own, the firm contracts directly with Anthropic, CourtListener, and Supabase. Lexware ships the orchestration code; the firm owns the contracts and the data.
| Provider | Purpose | Data exposed | Contracting party |
|---|---|---|---|
| Anthropic | Drafter + verifier inference | Prompt + retrieved passages | Firm |
| CourtListener | Citation verification | Citation strings only | Firm |
| Supabase | Postgres + auth + storage | Everything, encrypted at rest | Firm |
| Vercel (optional) | Frontend hosting (platform mode only) | Static assets + SSR | Firm or Lexware |
§ 07
Telemetry
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:
- Request bodies dropped (drafts, prompts, documents).
- Auth headers + API keys redacted.
- Query strings blanked (matter IDs, search terms).
- Transaction names use route patterns, never resolved IDs.
- No session replays; no DOM recording.
- No autocaptured clicks, inputs, or form submissions.
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
Incident posture
Because Lexware does not hold firm data or vendor credentials, a breach of Lexware infrastructure cannot, by itself, expose firm documents. The threat model treats Lexware code as untrusted third-party software running inside the firm’s perimeter.
Releases are signed, the changelog is public, and the firm controls the upgrade cadence. Self-host firms can pin a known-good version indefinitely.