Security & data protection
Security
How we are built, what we protect, and an honest account of what proctoring can and cannot do.
Last updated: 10 June 2026
On this page
Eigen-Rho runs live, one-to-one, human-proctored data interviews. A candidate solves a real business case in SQL against seeded data in the browser, and a trained interviewer watches over a video call and conducts the conversation. This page explains how the platform is built to keep that interview data safe, and it is candid about the limits of what any browser-based tool can do.
How the interview runs
The interview is designed so that the parts that matter for fairness and security never sit in the candidate's browser, where they could be read or altered.
- SQL runs server-side. When a candidate runs a query, it executes on our servers, not in the browser. The browser only sends the query text and receives the result rows.
- Read-only, per-session database. Each interview gets its own isolated database, seeded for that session. Queries run with read-only access, so a candidate cannot modify the data, reach another session's data, or affect the underlying system.
- The answer key never reaches the browser. Grading compares a candidate's result set to a golden answer that is held server-side only. The expected answer is never sent to the browser, so it cannot be inspected or extracted from the page.
- The question can change live. The interviewer can introduce a change to the problem during the session, known as a twist. This is a deliberate design choice for integrity, described in the threat model below.
- Two scores, never blended. The platform produces two separate scores, one for skill and one for integrity. They are kept distinct and are never combined into a single number.
The no-recording design
The proctoring features are built so that the most sensitive signals stay on the candidate's device by design, not by policy alone.
The live camera is relayed to the interviewer only and is never recorded or stored by us. Microphone audio stays on the candidate's device; only a coarse voice-activity flag (quiet or voice) is transmitted.
- Face-presence detection. To check that a person is present at the screen, the platform uses face-presence detection. The analysis runs in the candidate's browser. There is no identity matching, and no face templates are stored.
- Camera frames are not persisted. Frames used for face-presence detection are deliberately not saved on our servers. Live video travels peer-to-peer over LiveKit and is not recorded by us.
- Audio never leaves the browser. The microphone signal is processed on the candidate's device. We do not receive the audio. The only thing transmitted is a coarse voice-activity flag indicating quiet or voice.
Encryption in transit
All traffic between the browser, our servers, and the live video service is encrypted in transit using TLS. This covers queries and results, chat, interviewer actions, and the signaling that sets up the peer-to-peer video connection.
Access control
Access to interview data is scoped so that people and sessions only see what they are entitled to.
- Interviewer login. Interviewers and hiring-company staff authenticate before they can view or run any interview.
- Session-scoped tokens. A candidate joins through a token that is scoped to a single interview session. It does not grant access to other sessions or to administrative functions.
- Ownership-scoped data. Interview content, query history, chat, notes, and integrity events are scoped to the hiring company that owns the interview. One customer's data is not visible to another.
What we do and never do
What we do
- Run SQL server-side against an isolated, read-only, per-session database.
- Keep the answer key on the server and grade by comparing result sets to it.
- Relay live camera to the interviewer and run face-presence analysis in the browser.
- Encrypt all traffic in transit with TLS.
- Scope data to the hiring company that owns the interview.
- Treat scores and integrity signals as advisory inputs to a human decision.
What we never do
- Record or store the live camera, or save proctoring camera frames.
- Receive microphone audio; only a quiet-or-voice flag is sent.
- Store face templates or perform any identity matching.
- Send the answer key to the browser.
- Blend the skill and integrity scores into one number.
- Sell candidate or interview data.
What proctoring can and cannot do
We would rather tell you the truth than oversell the technology. A browser-based proctor has real limits, and pretending otherwise would set the wrong expectations for everyone.
The signals the platform can observe from within the session are tab and focus loss, the presence of a second monitor, paste events, the camera being on or off, face presence or absence, and typing rhythm. Typing rhythm is treated as forensics about the act of typing, not as a reading of what is being typed. Every one of these is an input to a human's judgment, not a verdict on its own.
What no browser tool can do, including ours:
- It cannot see a phone or a second camera pointed at the screen.
- It cannot detect external screen sharing through tools such as Zoom or OBS.
- It cannot prevent someone from reading or copying what is on their own screen.
The real safeguard is not surveillance. It is the live human interviewer, who is in the conversation in real time, combined with a question that can change during the session. A candidate who is not actually doing the work struggles to keep up when the interviewer probes their reasoning or introduces a twist. The integrity signals exist to draw the interviewer's attention; they never replace the interviewer's judgment.
Scores and integrity signals are advisory inputs. A trained human interviewer conducts the interview and makes the decision. The platform does not make automated hiring decisions.
Compliance posture
We aim to be accurate about where we stand, including where we are not yet.
- SOC 2. SOC 2 is on our roadmap. We are not certified yet, and we will say so plainly until that changes.
- GDPR and CCPA aware. We design with these frameworks in mind, including data minimization, scoped access, and the no-recording choices described above. The data we hold for an interview is the interview content, query history, chat, notes, and integrity events.
- Retention. By default, completed interviews are kept for 12 months after the interview, after which they are deleted, unless your pilot agreement specifies otherwise. This default is something the customer can change in their agreement.
- Ownership. The hiring company owns the verdicts and the interview data. We do not sell data.
Contact
For security questions, vulnerability reports, or to ask how this applies to your pilot, write to security@eigen-rho.com.