Every claim on this page is true today.

Nothing here describes something we intend to build. Every control below is running in the platform now, and every number is read from the configuration that runs it.

Where a reviewer would expect a document we do not have — an audit report, a data processing agreement, a sub-processor list, a written retention schedule — it is listed as an open item further down, marked as one. You should not have to discover a gap on a call.

If a control matters to your review and is not on this page, ask. We would rather write you a “not yet” than let you infer a yes.

A candidate is identified by an invitation token and a session token, nothing else. No password to reuse, no profile, no directory to appear in, no credential of theirs for an attacker to take.

The invitation link is single use and expires seven days after it is issued by default. The token appears in a URL exactly once — the emailed link. The first page captures it into browser session storage and redirects to an address that does not contain it, so it is not left in browser history or in a referrer header. Every page after that is guarded by the captured token.

Company accounts are separate and are never used by candidates. Reports, transcripts and code are scoped to the company that owns the assessment.

Each candidate works in their own Firecracker microVM. No candidate code runs in a container next to our services, and no two candidates share a machine. The candidate is not root inside it.

At provision time the firewall drops new outbound connections. Loopback and replies on established connections keep the editor and the command channel working; the public internet is not reachable from inside. Dependencies are baked into the image, so no package fetch is needed and the rules do not permit one. When a company enables the in-sandbox agent, exactly one destination is opened — our own model proxy, pinned by IP address, with no DNS permitted out of the machine.

Those rules are applied as root, and the candidate's unprivileged account cannot flush them. If a guest kernel ever refused the rules, provisioning would continue and the failure is logged rather than hidden.

The git snapshot repository that records how the work progressed is owned by root outside the workspace, so it cannot be rewritten from inside the session.

Hidden tests, the reference solution and the grading contracts never enter the candidate's machine. Hidden tests run after submission in a separate sandbox the candidate never touched, which is destroyed immediately afterwards. The candidate's own machine has a fixed lifetime and is destroyed at the end of the session; nothing installed or written inside it survives.

There is no self-serve sign-up. Accounts are created by Sphinque or by an invitation from a colleague at your company, and every member holds one role — admin, hiring manager, recruiter or viewer — that decides what they can do.

Sign-in issues a short-lived access token and a refresh token that rotates on use, with the previous refresh token blacklisted. Repeated failed sign-ins lock the account by username and by IP address. Passwords have a twelve-character minimum. Google sign-in is optional; the OAuth tokens it returns are encrypted at rest.

Significant actions are written to an append-only audit trail with the actor, the resource and the request context. The administrative interface is not served from a published path, and the paths an attacker would guess are honeypots.

In production every request is served over TLS, HTTP is redirected, and HSTS is sent with a one-year max-age, subdomains included and preload set. Cookies are marked secure and HTTP-only, the referrer policy is strict-origin, and content-type sniffing is off.

Browser access is limited to an explicit list of origins. The service refuses to start in production if that list is empty, so a misconfiguration fails loudly instead of opening the API to any origin.

During the interview the browser holds a room token scoped to that one room and nothing else. Every vendor credential lives on the interview worker, server side. No model or voice provider key is ever sent to a browser.