Isolation by
construction.
You're about to run strangers' code and hand us your candidates' work. Both of those deserve more than a badge on a page. Here is the actual shape of it — including the parts we haven't finished.
Each one is a mechanism, not a policy
The distinction matters. A policy is a rule someone can forget to apply. A mechanism is something the system cannot do even if the code asks it to.
Candidate code runs nowhere near us
Every attempt gets its own container, created for that attempt and destroyed when it ends. Code runs as an unprivileged user, with no credentials of ours in its environment and no path to another attempt's container or to your account data.
Tenants are separated at the database
Application code filters by organization, and beneath it every query runs inside a transaction carrying a tenant context that row-level security enforces. A query that somehow reaches the database without one returns nothing — it fails closed, rather than returning everything.
Our operators cannot read candidate work
Platform administration runs as a separate service with its own database role, and that role has no read privilege on submitted artifacts or scorecards. Support can help you with your account without being able to open your candidates' code. That's a grant, not a promise.
Grading is a separate box again
The grading run is where a submission is actually executed, so it holds no database credential and no storage credential at all. It bootstraps from a single-use, per-run token, does its work, posts the result back, and exits.
Access
- Candidates never create an account. An invite is a single-use token with an expiry
- Accepting an invite establishes a session bound to that one attempt, revocable, and revalidated continuously — including on the live workspace connection
- Console access is per-organization with roles; every seat is free, so nobody shares a login
- Passwords are stored with a memory-hard hash; platform operators additionally require TOTP
- State-changing requests carry CSRF protection, with separate tokens per realm
Auditability
- The audit log and the billing ledger are append-only by privilege — update and delete are revoked from the runtime roles. A mistake is corrected with a compensating entry, because the database will not accept anything else
- Access to a submitted artifact is audited, and the audit is fail-closed
- Artifact downloads are short-lived signed links, individually revocable
- Score overrides are an append-only ledger, so the original machine score never disappears
What we hold, and for how long
What is stored
The submitted code, the assistant transcript, and the scorecard built from them. Nothing from outside the interview tab.
What is never stored
No video, no audio, no screen capture, no keystrokes, and we never read the clipboard. Text a candidate pastes into a file or into a message to the assistant is stored like anything else they type there.
Retention
Artifacts are deleted on a retention schedule, and a specific attempt's artifacts can be deleted on request. Talk to us about the window your jurisdiction needs.
The part most vendors leave out
A security page that only lists strengths is a marketing document. We'd rather you find the edges here than in a questionnaire three weeks into an evaluation.
- We do not hold SOC 2, ISO 27001 or any third-party certification today. If a certification is a hard requirement for you, say so early and we'll tell you honestly where we are rather than selling you a roadmap.
- We keep an internal register of open architectural gaps with the reasoning and the fix for each one. Ask, and we'll walk you through the ones relevant to your deployment.
- AI evaluation is not infallible, and we don't design as if it were. Every score is reviewable, overridable, and cites the evidence it rests on precisely so a human can disagree with it.