Security at Lobbyee

This page is for the person at a hotel group who has to sign off on new software before it ever touches guest or candidate data. It is a plain description of what Lobbyee actually does today, not what we hope to do. Every claim below is grounded in code, configuration or an automated test in this repository, and we would rather list a shorter set of true things than a longer set of aspirational ones.

What we do not claim

We are a small team and we are honest about that. Lobbyee does not hold SOC 2, ISO 27001 or any other third-party certification. We do not run a paid penetration test or a public bug-bounty programme yet. We do not use phrases like “bank-level” or “military-grade” because they mean nothing verifiable. If a certification we do not have is a hard requirement for you, please tell us and we will say so directly rather than dance around it.

Tenant isolation

Every hotel workspace is isolated at the database layer, not just in application code. Lobbyee runs on Postgres with row-level security policies attached to every user-scoped table. Application queries go through a scoped client that authenticates as the requesting user, so the database itself refuses to return rows that belong to another workspace, even if a bug in application code asked for them.

The isolation is proven by an automated attack test that runs in CI on every commit. It creates two workspaces on the same database, then tries every cross-tenant read and write we could think of: reading another workspace's sessions, personas, evaluations, candidate invites and dashboard data through the pages, the server actions and direct queries. If any of those attempts succeeds, the build fails and the change cannot ship. A separate live attack sweep against production, run before the first paying customer, is logged in our internal records for July 26, 2026.

Encryption

All traffic to Lobbyee is served over HTTPS. The database is hosted on Supabase, which provides encryption at rest for the underlying Postgres storage and encrypted connections between the application and the database.

Secrets and source code

Secrets like API keys and database credentials live in the deployment platform's environment variables, never in the repository. Our continuous-integration pipeline has a hard gate, pinned by version and checksum, that scans the working tree AND the full git history on every commit for anything that looks like a secret. A leaked secret fails the build; there is no override. The scanner is gitleaks, configured in the repository's CI workflow.

Environment variables are validated at boot with a schema, so a misconfigured production environment fails fast and loudly instead of running with a silent hole.

Data retention and deletion

Workspace data is kept while the workspace is active. Deleting a workspace deletes its sessions, transcripts and assessments in the same transaction.

Candidate assessment data is on an automatic clock. A scheduled job deletes each closed assessment invite, along with its transcripts, evaluations, evidence quotes and comments, twelve months after the assessment closes. The deletion is enforced by the database's own cascade rules, so nothing lingers in a child table. If a candidate or an employer asks us to delete sooner, we do; write to the address at the bottom of this page.

Voice

Voice sessions stream a trainee's microphone audio to our speech-to-text and text-to-speech providers in real time so the conversation can flow. We store the resulting text transcript on the session record. We do not retain the raw audio recording. Hiring assessments are typed by default; candidate voice is a separately gated feature and, even when enabled, follows the same rule of storing text rather than audio.

Analytics and cookies

Our product analytics run server-side only. Lobbyee never loads an analytics script in the visitor's browser, so we set no tracking cookies and no advertising cookies. The only cookies we set are the ones strictly required to keep a signed-in user signed in. The events we do record are workspace-level and event-count-shaped: they include anonymous user and workspace identifiers and simple event names, never names, email addresses, conversation transcripts or scores.

Error monitoring

When error monitoring is enabled, we send server-side errors to Sentry with personally identifying information turned off at the SDK level (sendDefaultPii is set to false) and an additional scrubbing layer that strips known-sensitive fields from event payloads before they leave our servers. There is no browser-side Sentry SDK, so nothing about a visitor's device or session goes to Sentry from the client.

AI-assisted hiring

The hiring product uses AI to score candidate conversations, and we treat that as a decision-support tool for a human reviewer, never as an automatic decision. Lobbyee cannot reject a candidate; the employer makes every call. Where a jurisdiction requires more than that (New York City, the United Kingdom, the European Union and the European Economic Area, and Quebec today) candidate invites are switched off entirely rather than shipped with a caveat.

Independent review

On August 9, 2026 an independent security review of the production code and configuration returned zero critical and zero high findings. The review was scoped to the web application, its authentication, tenant isolation, secret handling and the assessment flow. This is a point-in-time review, not a certification, and we will refresh it as the product changes.

Sub-processors

Lobbyee runs on Vercel (hosting), Supabase (database and authentication), Google Gemini, Deepgram and Cartesia (AI processing), Hugging Face (voice session infrastructure), Resend (email), Dodo Payments (billing), PostHog (product analytics), and Sentry (error monitoring, when enabled). Each receives only what it needs. A current list of sub-processors is available on request.

Reporting a vulnerability

If you find something that looks like a security issue, please write to support@lobbyee.comwith enough detail to reproduce it. We will acknowledge within three business days, agree a coordinated timeline with you, and credit you in our release notes if you would like. Please do not test against another customer's workspace or against real candidate data.

Related

Read the Privacy Policy for what we collect and why, and the hiring product page for how the candidate assessment flow works in practice.