How Lunra is built to protect a raise

Lunra is a server-rendered web application. The application layer runs on Vercel; the data layer is Postgres, authentication, and object storage on Supabase, hosted on AWS in us-east-2 (Ohio). All customer data is stored and processed in the United States.

The browser never receives more than the signed-in workspace’s own data: pages are rendered on the server against a database session scoped to the requesting user. Privileged (service-role) database access exists only in server code, and every file that imports it must appear in a reviewed allowlist; a continuous-integration check fails any change that adds privileged access outside that list.

Isolation is enforced by the database, not by application code remembering to filter. Every table holding customer data carries row-level security keyed to workspace membership, so a query made with a user’s session can only ever return that workspace’s rows, whatever the application code asked for.

The policies are tested, not trusted: an automated isolation suite of more than 80 assertions runs on every code change against the live policy set, pairing each negative assertion (user B cannot read workspace A) with a positive control (user A can), so a passing run cannot be explained by the test being broken. Workspace membership and roles are granted exclusively by server-side records; invitation acceptance carries no client-writable authority.

Sign-in is by emailed magic link. There is no stored credential to phish or leak, and access to Lunra inherits the protections on the user’s email account. Authentication events are recorded with request attribution (IP addresses are stored as salted hashes, not raw).

Administrative actions are audit-logged, and the log includes cross-tenant reads by our own staff: if we ever look at customer data to provide support, that access is recorded the same way a change would be. Email addresses are masked centrally in log output.

All traffic between browsers, the application, and the data layer is encrypted in transit with TLS. Data at rest, including uploaded documents, is encrypted with AES-256 by the storage infrastructure. Application secrets and API keys live in the hosting platform’s environment configuration and are never committed to code.

The deck is the most sensitive object in the system, and it has exactly one AI processor: Anthropic. When a customer runs deck analysis or drafting, content is submitted to Anthropic’s API, whose commercial terms state that API content is not used to train models. No other AI vendor receives customer content, and we treat adding one as a security boundary change requiring documented review, not a feature decision.

Uploaded documents are stored in access-controlled object storage. Nothing is served from a public bucket.

Every document shared with an investor is served through a single controlled route. That route verifies the file is a genuine PDF by reading its bytes rather than trusting the declared type, applies a recipient watermark, and records each view in an access log the customer can see. Share links expire after 30 days and can be revoked at any time; data-room access can be revoked as a unit, which revokes the underlying file links with it. Rooms can additionally require NDA acceptance before any file is shown.

Version history is retained deliberately. When a document is superseded, the prior file is kept, because it is the evidence of what a recipient actually saw, and the access log points at it. A share link is never silently re-pointed at different content than it was issued for.

Return-or-delete is self-serve, not a support ticket. A workspace owner can export the full workspace from Settings (all structured data plus signed download links for every stored document, superseded versions included) and can permanently delete the workspace with a typed confirmation. Deletion is a hard delete across every workspace table and stored file, recorded by a minimal retained receipt, and both paths are driven by one table registry that continuous integration checks against the live schema, so a table added later cannot silently escape export or deletion. Beyond the receipt, we keep only records financial law requires. Our investor directory has its own published retention rule, documented in how Lunra handles investor information.

Stated plainly: Lunra does not hold a SOC 2 report today. Our Type II observation window opens January 2027, scoped to the Security and Confidentiality trust criteria, with the report expected Q2 2027. We are not pursuing a Type I.

What exists today is the control substrate that window will test, built and operating since August 2026: database-enforced tenant isolation with the CI suite described in section 02, the service-role allowlist check from section 01, audit and authentication event logging from section 03, and the document-serving controls from section 06. A reviewer who wants evidence ahead of the report can request our security questionnaire responses at hello@lunra.io.

Email hello@lunra.io with “Security” in the subject. Reports reach the founding team directly. We ask for a reasonable opportunity to fix an issue before public disclosure, and we will not pursue good-faith research conducted within these terms.