Crux Security Overview

Version 1.0, effective September 16, 2026. An honest description of how Crux is built and run today, for professors and the people who review tools on their behalf. Crux is a prototype operated by one person; this document says so where it matters.

Architecture

• A single web application (Node.js) on one virtual machine at Google Cloud (us-central1, Iowa), behind a reverse proxy (Caddy) that terminates HTTPS.
• Data is stored on the machine's encrypted disk as files: assignments, interview sessions, uploaded PDFs, exhibit images, audio clips.
• AI calls go to Anthropic (interviewer, evaluator) and ElevenLabs (voice, transcription) over HTTPS. See the Privacy Notice for what each receives.
• Domain, DNS and email routing are on Cloudflare. No content is proxied or cached by Cloudflare at this time.

Encryption

• In transit: HTTPS everywhere with certificates from Let's Encrypt, automatically renewed. Plain HTTP redirects to HTTPS. HSTS is set.
• At rest: Google Cloud persistent disks are encrypted by default. Backups are copied over SSH to an encrypted disk controlled by the operator.
• Secrets (API keys, passcodes) live in a file readable only by the service user on the server; they are never in source control and never shown in the interface.

Access control

• Students need no account. They reach an assignment through its link and identify themselves by typed name. Student-facing routes expose only what a student needs: the case, their own result, their own audio.
• Professors sign in with a per-professor passcode and see only their own assignments and interviews; the server enforces this on every request, not just in the interface.
• Administrator (the operator) has a separate passcode that sees all assignments, and can change installation settings such as the interviewer voice.
• Server access is by SSH key only, from the operator's machine; password login is disabled; a host firewall allows only SSH, HTTP and HTTPS.
• Search engines are told not to index any page.

Abuse limits

• Caps on interviews per hour and per day, and on speech-synthesis characters per day, so a leaked link cannot run up costs or block the class.
• Uploads are limited to PDFs and images of bounded size.

Logging and monitoring

• The service logs requests, errors, interview lifecycle events and AI usage counts (tokens, characters), not transcript content. Logs are kept 30 days.
• The application reports its health at a public endpoint used by the student interface to show connection status.

Backups and recovery

• Nightly copy of all data to the operator's encrypted disk, 14 days retained.
• The machine can be rebuilt from a scripted setup in under an hour; the service restarts automatically on crash or reboot.

Vulnerability reporting

Report security problems to jon@cruxcall.com. You will get an acknowledgment within two business days. Please do not test against other people's interviews.

Incident response

If we confirm a breach affecting personal data, we will contain it, assess what was affected, and notify the affected professor or institution without undue delay and within 72 hours of confirmation, with what happened, what data was involved, and what we are doing. Students are notified through their institution unless the institution asks otherwise.

What is not in place yet

Said plainly, because reviewers will ask:

• No single sign-on. Passcodes only.
• No SOC 2 report or third-party penetration test.
• One operator, one machine, one region. No formal on-call.
• No student identity verification beyond a typed name.
• No accessibility conformance report (VPAT) yet; accommodations exist in the product.

These are the items on the roadmap before Crux is used for graded work at institutional scale.