Security review
Security and data handling.
What is enforced, where it is enforced, and how to check it. Written for the review a fund runs before a pilot. Every statement below describes a control that exists in the current build.
Access
Authentication and data access are separate controls.
A valid Supabase Auth session establishes identity. Database policies then decide which organisation, company and records that identity can access.
Every protected request validates the signed-in user.
Portal pages and private API routes resolve the user through Supabase Auth on the server. Missing or expired sessions are rejected before product data is loaded.
Roles come from controlled database memberships.
Organisation, fund-side role and company membership are read from protected PE tables. Browser-editable profile metadata is not used to grant access.
Postgres enforces the resulting scope.
Row-level security applies organisation, role and company checks to every product table. Application navigation is not the security boundary.
Tenant isolation
A portfolio company cannot see another company.
Funds and their portfolio companies work in the same product with hard boundaries between them.
Row-level security on every product table.
Access checks run inside Postgres on every query, keyed to the signed-in user, their organisation, their role and - for company-side users - their company.
Company users are scoped to their own company.
A portfolio CEO, CFO, transformation lead or company viewer can only read records for the company they belong to. Fund-side roles are checked against their organisation and role on every table.
Hiding a page is not the control.
Navigation, API routes and AI retrieval all sit above the same database policies. A request outside the user’s scope returns nothing, whatever path it takes.
Evidence files
Files are private and every download is checked.
Board packs, QoE extracts, contracts and monthly reporting files are records, and they are handled like records.
Private storage, no public URLs.
Evidence files live in a private storage bucket. The application never issues a public or shareable file URL.
Downloads go through a scoped route.
Every download checks the session and the organisation before serving the file, and responds with cache-control: private, no-store.
A SHA-256 checksum is recorded at upload.
Each file carries its checksum on the evidence record, so a file can be verified against the record that cites it.
Lighthouse and AI
AI answers are scoped, cited and kept.
Lighthouse answers questions by retrieving records, and its retrieval is subject to the same permissions as the user asking.
Retrieval uses the caller’s permissions.
Lighthouse can only retrieve records the signed-in user is already permitted to see. There is no elevated AI service account for retrieval.
Model calls go to Anthropic. Customer records are not used to train models.
Lighthouse runs on Anthropic’s API. Under Anthropic’s commercial terms, API inputs and outputs are not used to train Anthropic’s models.
Every answer is persisted.
Each answer is stored with the question, the model that produced it, the records it cited and the input and output token counts. Signed-in users cannot edit or delete this history.
History
Audit events and record versions cannot be rewritten.
What happened, who did it and what the record said before are kept out of reach of the people they describe.
Audit events are written by database triggers.
Signed-in users hold no insert, update or delete rights on the audit table. Changes to material records write their own audit rows.
Record versions are read-only.
Prior versions of a record can be read but not edited or removed through any signed-in session.
Deletion is controlled and archived.
Deleting a material record is limited to admin and managing partner roles, requires typed confirmation and a written reason, and archives the row before removal.
The public demo
The landing page demo holds no customer data.
The Ask Lighthouse demo answers questions about a fictional sample fund. Nothing a visitor types creates an account or touches customer records.
Fictional sample only.
The demo reads a fixed fictional evidence set. Harbour Ridge Capital and its portfolio do not exist.
Origin-checked and rate limited.
The demo endpoint rejects requests from other origins and rate limits by caller before any model call is made.
Hosting
Three sub-processors, all named.
The production service runs on the following providers. There are no other sub-processors in the request path.
Vercel
Application hosting and delivery.
Supabase
Postgres, authentication and evidence file storage. Hosted in the Sydney region.
Anthropic
Model calls for Lighthouse. See the AI section above for data handling.
Built for your review
Every control here can be demonstrated.
These are enforced in the database, not described in a policy document. That means your reviewer can watch them work rather than take our word for it.
Run the isolation test yourself.
Two portfolio companies in one workspace, one login each. The second company returns nothing, and the block happens in Postgres rather than in the interface.
We answer questionnaires and DDQs directly.
Send yours. We answer against the running product, and where an answer is a roadmap item rather than a control today, we say so in the response.
Hosting is Sydney, on Supabase and Vercel.
One region, named sub-processors, and an Anthropic API path that carries no training rights over your records.
Files are the ingestion path.
Use the packs companies already send. Nothing here should be read as a live connection into a fund or portfolio system.
Security questionnaires
Send us yours.
We answer security questionnaires and walk through any control on this page against the running product. Write to hello@uselighthouse.ai.