The one-paragraph version
Every customer's data is isolated by row-level security enforced inside PostgreSQL — forced on every table, with no application role able to bypass it, and re-verified by automated cross-tenant probes on every schema change. Candidate code runs in disposable micro-VMs that are created for one attempt and destroyed after it; the machine that grades a submission has no outbound network access. Your recruiters structurally cannot read candidate code — that is a database policy, not a hidden button. No model makes or recommends a hiring decision anywhere in the product.
Tenant isolation is a database property, not an application promise
Most SaaS isolates tenants with a WHERE clause the application remembers to add. We do not trust ourselves that far. Every table carries PostgreSQL row-level security, enabled and forced — forced means even the table owner cannot skip it — and the application connects through roles that hold no bypass. A query that forgets to scope itself returns zero rows, not another customer's rows.
This is not a launch-day claim that quietly rotted. Our migration runner re-verifies the invariants on every schema change: RLS enabled and forced on every table, no bypass-capable application role, at least one policy on every table, and live cross-tenant probes — a real connection scoped to one workspace attempting to read another's data, expected to come back empty. A schema change that would weaken isolation fails the deployment instead of shipping.
Candidate code runs in machines built to be thrown away
Each assessment attempt boots a dedicated Firecracker micro-VM (via E2B) that exists for that attempt and is destroyed afterwards. Nothing persists between candidates; nothing is shared between customers. Two properties matter beyond the isolation itself:
- The grading sandbox has no outbound network. A submission cannot exfiltrate anything during grading, and a grading run cannot be influenced by anything outside the sealed inputs it was handed.
- The answer key never enters the candidate's machine. Hidden test suites, rubrics and scoring manifests are not present on the sandbox a candidate can shell into — not permission-protected there; *absent*. They are injected only into the separate, network-less grader, and the material is additionally held behind database policies the application's ordinary role cannot read.
Grader results are cryptographically signed, and every score is reconciled against a manifest of expected test identities recorded before the candidate ever saw the challenge — a forged or truncated report is rejected rather than scored.
Least privilege is the org chart, enforced
Access inside a workspace follows seats, and the boundaries are row-level policies rather than hidden UI:
- Recruiters operate the pipeline — positions, candidates, dispatch — and see pass/fail. They cannot read submitted code, behavioural telemetry, or CV analysis: the database returns nothing to their role, however the request is made.
- Tech leads (the interviewer seat) read code, grader evidence and rubric detail, and are the only seats that can overrule a grade.
- Admins manage the workspace and members.
External collaborators — an agency recruiter, a consultant — can hold seats and are labelled as external in the team view; their role governs their access exactly as it does for employees. A person with seats at more than one customer holds one seat per workspace, and a session is always scoped to exactly one workspace: there is no token in this system that can read two customers' data.
Credentials and secrets
- Candidate assessment links carry high-entropy tokens stored only as SHA-256 hashes; a database dump does not contain a working link.
- Sign-in is one-time codes, rate-limited per address and per network, with codes hashed at rest (Argon2id). There are no passwords to breach.
- Sessions are short-lived signed tokens with a revocation kill-switch.
- We never touch card data: billing is by invoice, and payment details do not pass through or rest in our systems.
What we deliberately do not collect
No webcam, no microphone, no screen recording, no keystroke logging, no browser lockdown, no monitoring of other tabs or applications — for any candidate, ever. The behavioural record that does exist (commands run, autosaves and the saved workspace history they form, tab focus, the prompts typed to the in-workspace navigator and its replies, the size of pasted text and each refusal by the clipboard limit — never the pasted text) is disclosed to the candidate before they start, is shown to reviewers as context, and is never used to score. That detailed record is deleted on an event-driven schedule — 7 days after a rejection or a position's archive, and in any case 30 days after the attempt ends — leaving the score, the final diff, the decision record and a content-free activity digest.
Where things run
The API and workers run on Render; the database is PostgreSQL and the queue Redis; candidate sandboxes are E2B Firecracker micro-VMs; the web surfaces are served from Vercel; transactional email is Resend; model calls for routing, task wording, interview-question drafting and the in-workspace navigator's replies (Arbiter Pair) go to Anthropic. The full sub-processor list, with exactly which data each receives, is in the Data Processing Agreement.
The audit question, answered honestly
Our controls are engineered against the failure modes SOC 2's trust criteria describe — enforced isolation, least privilege, verifiable change control, evidence that survives its authors. We have not yet completed a formal SOC 2 audit, and this page will say so until the day that changes rather than imply otherwise. Enterprise agreements include our security documentation and a review call with the engineers who built the controls — ask for whatever detail your process requires.
Reporting a vulnerability
Write to support@getarbiter.io with "security" in the subject. Reports are read by engineers, acknowledged promptly, and never met with legal threats for good-faith research.