Security
Concrete controls, honestly stated
What's actually implemented in the architecture. We don't claim security certifications we haven't completed.
Per-user data isolation
Every student-owned record carries an enforceable owner relationship. Access is enforced by database row-level security and server-side ownership checks — not by trusting client-side filters.
No cross-user access
There is no shared content bank and no path to read another student's material. Cross-student retrieval is excluded by design.
Secure session handling
Authentication uses secure, HTTP-only sessions with CSRF-safe mutation patterns.
Verified webhooks
Inbound webhooks (billing, transcription completion) are signature-verified before they are processed.
Rate limiting & bot protection
Signup, authentication-adjacent endpoints, AI generation, and job creation are rate limited. The beta form also uses a honeypot and timing heuristic.
Input validation & safe rendering
All input is validated server-side with a typed schema, and output is rendered safely. Course documents are treated as untrusted data and cannot supply system instructions.
Security headers & CSP
A content security policy and standard security headers (HSTS, X-Content-Type-Options, frame denial, referrer policy) are applied to every response.
Redaction in logs & analytics
Secrets and student content are kept out of structured logs, analytics events, URLs, and search indexes.
Not yet claimed
We have not completed formal third-party security certifications (such as SOC 2 or ISO 27001) and we will not imply that we have. Export and account-deletion workflows are represented in the architecture and continue to be hardened ahead of launch.