Security & sandbox
Candidate code never touches your machine.
Every review runs in a single-use sandbox, destroyed when the report is done.
Single-use E2B sandboxes
Every repo runs in an isolated, single-tenant VM. Destroyed immediately after the report. No shared state, no neighbour escape surface.
No persistent candidate code
Repos are cloned into the sandbox at run time and never stored after tear-down. Only the structured report and reviewer logs are retained.
Scoped GitHub tokens
Private repos use fine-grained, read-only tokens scoped to a single repository. Encrypted at rest. Used only for the clone step.
Encrypted at rest
Reports and uploaded briefs sit in S3 with SSE-KMS, served via signed short-lived URLs. Never a public bucket.
Data handling
What we store. What we don't.
Where does candidate code run?
Inside E2B — sandboxed micro-VMs built for executing untrusted code. Fresh VM per review, no network access to your infra, no inbound ports.
What does CodeVerdict store?
The generated report (scores, findings, requirements mapping, interview questions), reviewer notes, and uploaded briefs. Candidate source is not persisted past sandbox tear-down.
Who can see a report?
You and teammates you explicitly add. Public share-links are HMAC-signed with a TTL (default 1h); revocable by deleting the submission.
What about logging?
Structured operational events only (start, finish, errors). No candidate source. No PII beyond what you add (name + email).
Compliance posture
Beta. Formal certifications (SOC 2 Type II, GDPR DPA) on the roadmap before team tier. We follow SOC 2 controls today; the audit is what's outstanding.
Found a security issue?
Responsible disclosure please — email instead of filing a public issue.
Try a sandboxed review.
Drop a GitHub URL. See the full setup, test, and execution trace inside the VM.