Security & data handling

Bookkeeping software runs on visible trust. Lawenots separates cloud workbook services (auth, books, billing) from optional Sovereign vault (encrypted sensitive documents and credentials on your own infrastructure). This page summarizes encryption, token storage, and authentication. It supplements our Privacy Policy.

Bank connectivity, payments, and core infrastructure are delivered through authorized third-party APIs. We display partner attribution where those integrations are active.

In transit: All production traffic is served over HTTPS/TLS. Content-Security-Policy headers restrict script and connect sources; mutation API requests require CSRF validation when a session is present.

Plaid access tokens (Books): After Link exchange, Plaid access tokens are encrypted with AES-256-GCM before persistence. Keys are derived from PLAID_ENCRYPTION_KEY (or AUTH_SECRET as fallback) via SHA-256 key derivation. Ciphertext includes a random IV and authentication tag.

Sensitive books fields: Account and routing numbers may be protected with field-level AES-256-GCM when FIELD_ENCRYPTION_KEY is configured (64 hex characters / 32 bytes).

Sovereign vault (optional): Sensitive documents and credentials stored in Sovereign vault mode use AES-256-GCM under MASTER_VAULT_KEY (minimum 16 characters). Decryption occurs only inside the vault plane when deployed locally — not on serverless cloud hosts.

Database: Supabase Postgres (auth, billing) and isolated Lawenots Books Postgres rely on provider encryption at rest. Application-layer encryption is applied to high-sensitivity tokens and fields as described above.

Two-factor authentication: Optional TOTP-based 2FA with single-use backup codes. Backup codes are stored as one-way hashes — Lawenots cannot recover an unused code.

Public API keys (Lawenots API): When you create a programmatic API key, we store only a SHA-256 hash and a short display prefix. The raw key is shown once at creation; we cannot recover it later.

Plaid tokens: Encrypted at rest as described above. Tokens are decrypted only server-side during sync jobs and webhook handling; they are never returned to the browser.

Market data keys: Tiingo tokens are used server-side for crypto/investment price refresh in the books workspace. These are read-only market data credentials, not trading keys — Lawenots does not connect to brokerages or exchanges for order placement.

Billing: Stripe handles card data end-to-end; Lawenots stores only subscription status metadata, never card numbers. Webhook events are verified against Stripe's signature before being processed.

Session & CSRF: Authentication sessions are managed by Supabase Auth (HTTP-only cookies). CSRF tokens are signed with a dedicated secret via Web Crypto HMAC — mutation requests fail closed (403) rather than falling back to a borrowed secret — and validated on mutation routes.

Cloud workbook (default): Books run on hosted Postgres (Lawenots Books) with app-layer encryption for Plaid tokens and sensitive fields. Auth and billing live on Supabase with row-level security.

Optional Sovereign vault: Sovereign vault is an optional Docker Compose mode for sensitive documents and credentials — not required for books, Plaid feeds, or tax exports.

Export rights: You can export GL, trial balance, activity logs, tax schedules, and evidence packages at any time. Close + Attest adds signed attestation metadata verifiable with MIT open tooling.

Lawenots does not ship a private-cloud Kubernetes ledger OS or offline-only workbook at launch. Positioning is exportability, evidence packages, and optional vault — not air-gapped local ledger unless you deploy vault mode yourself.

Lawenots runs on enterprise-grade cloud infrastructure with the controls below. We do not expose internal provider names in customer contracts — this summary reflects what the product enforces in code.

• Production traffic served over HTTPS/TLS with Content-Security-Policy on workspace routes
• Multi-tenant isolation via Supabase RLS and books Postgres deny-by-default API roles
• Plaid tokens and sensitive fields encrypted at rest (AES-256-GCM)
• Sentry monitoring with PII stripped; secrets managed via Infisical / Vercel env — never in git

See also product glossary for category positioning.

Lawenots publishes verification tooling for Close + Attest so operators, firms, and auditors can independently validate evidence packages without a Lawenots account. Ed25519 signature checks, Merkle root rebuilds, export-receipt hashes, and artifact schemas are MIT on GitHub.

See open verification for the three published surfaces, or Close + Attest for the product tier. Reconciliation matching and scoring implementations remain proprietary.

• Uptime target: 99.5% monthly availability for the cloud workbook (best effort; excludes scheduled maintenance windows announced in advance).
• Audit log retention: 90 days hot for Books activity and admin actions; 1 year archive for compliance export.
• Change management: Production deploys require GitHub PR review plus CI (typecheck, lint, tests, build). Secrets never committed to git.
• Live status: /status probes Supabase, Books Postgres, and optional vault planes, and reports upstream configuration for Stripe, Anthropic, Tiingo, and Redis.

Form 8949–compatible exports include export receipts (content hash + source revision). See the tax-ready methodology & limitations page for inputs, assumptions, and what “tax-ready” does not mean.

• Row-level security policies on Supabase tenant data
• Rate limiting on sensitive API routes (Supabase-backed limiter)
• Sentry error monitoring with PII stripped before export
• Secrets managed via Infisical in development; production env vars in Vercel/Infisical — never committed to git
• Optional TOTP two-factor authentication with single-use, hashed backup codes
• Stripe webhook events verified against Stripe's signature before processing

Security questions or responsible disclosure: contact@lawenots.com. Include "Security" in the subject line.