SECURITY
How we protect your account and data
This covers the technical practices behind the product. For who can see a given report, how long data is kept, and where things stand on hiring-related regulation, see /trust. For what data is collected and why, see /privacy.
Practices in place today
Authentication
Accounts are authenticated through Supabase Auth, not custom password storage. Email verification is required before an account can start an assessment. The frontend never sees the Anthropic key, the Supabase service-role key, or the email-provider key -- only a publishable Supabase key safe for client use.
Two independent authorization layers
Every request is checked twice: the backend verifies a caller's role and organization before returning data, and Postgres row-level security enforces the same boundaries again at the database level. A bug in one layer does not, by itself, expose another person's data.
Rate limiting and abuse prevention
Registration and password reset are rate-limited per IP. Starting a new assessment is capped per user, per day and per month. A global daily spend ceiling stops the AI-interview engine outright if usage spikes unexpectedly, rather than letting cost run unbounded. Registration is gated behind Cloudflare Turnstile.
Uploaded documents
A resume or other document you upload is restricted to PDF, DOCX, or plain text, capped in size, and stored in a private location scoped to your account only. Text is extracted from it to add context to your interview; the file itself is never executed or rendered as anything but text to read.
Secrets handling
API keys and service credentials live only in environment variables on the hosting platform, never committed to source control and never returned in any API response.
Input handling
Every request the backend accepts is validated against a strict schema at the boundary. Your answers are sent to the AI model as text, never interpolated into a database query, and are escaped before being rendered back to you or into a PDF.
Where we’re still maturing
We would rather tell you what isn’t done yet than let a polished page imply otherwise:
- We have not completed a formal third-party security audit or penetration test.
- Rate limiting currently runs in a single backend instance; a shared, multi-instance limiter is planned as usage grows.
- There is no audit log of administrator actions yet.
- Automated dependency and code-security scanning is not yet wired into our build process.
Found a security concern?
We don’t have a dedicated inbound channel set up yet. Tell us through the early access form on /for-organizations and mark it urgent, or book time directly -- either reaches the founder, who reads every message personally.