Security at AskCV

Security at AskCV is a layered responsibility: the platform we build, the vendors we rely on, and the account controls you choose to use. We design every new feature with the assumption that it will handle sensitive career data, and we harden the boundaries between tenants, between users and visitors, and between your data and the AI providers we route to.

This page is a living document. When we change a control, we update it. When we have not yet built something that the industry considers best practice, we say so.

2.1 In transit

All traffic to askcv.ai and every subdomain is served exclusively over TLS 1.3 with modern cipher suites. HSTS is enabled with a long max-age, so browsers refuse to downgrade to HTTP. API calls between our application layer and subprocessors (database, AI gateway, email, error monitoring) also run over TLS.

2.2 At rest

The primary database (Neon Postgres) and object storage (Vercel Blob) are encrypted at the provider layer. On top of that, we apply application-level AES-256-GCM encryption to sensitive fields that deserve extra protection — notably the OAuth access and refresh tokens we hold for connected integrations (Google Calendar, Gmail, etc.). The encryption key is unique per environment, scoped to the server-side runtime, and never written to logs.

2.3 Voice audio

Voice coaching and voice interview input stream directly to Google Gemini Live. We do not persist the raw audio after the session ends — only the resulting transcript is stored, linked to the session it belongs to.

3.1 Passwords

When you sign up with email and password, your password is hashed using bcrypt with a cost factor of 12 before it touches persistent storage. We never see your plaintext password at any point after login and cannot recover it — only reset it.

3.2 Passkeys and 2FA

AskCV supports WebAuthn passkeys for phishing-resistant sign-in and biometric second-factor authentication. You can register multiple passkeys (for example, one on your laptop and one on your phone) from your account settings. We also support TOTP two-factor authentication for users who prefer an authenticator app.

3.3 OAuth sign-in

You can sign in with Google, GitHub, LinkedIn, or Apple. OAuth sign-ins do not unlock additional integration scopes — if you later connect a service like Google Calendar, that grant is a separate, explicit consent flow with scoped permissions.

3.4 Sessions

Sessions are identified by random 64-byte tokens stored as SHA-256 hashes in our database (we never keep the raw token server-side). The corresponding cookies are HttpOnly, Secure, and SameSite=lax. Each session records the IP and user-agent it was created from, so you can review and revoke sessions from account settings.

3.5 Brute-force protection

We lock accounts after a configured number of failed login attempts, rate-limit authentication endpoints, and challenge high-risk sign-ins with the second factor you have registered.

3.6 Admin separation

Platform admins use a separate authentication system from tenant users, with mandatory MFA (TOTP and/or passkeys) and role-scoped permissions. A compromised tenant account cannot escalate to an admin account, and admin sessions cannot act on the public tenant surface.

AskCV is multi-tenant by design. Every tenant-scoped table carries a tenantId column, and every read and write is filtered through a centralised withTenant() helper that refuses to run without a tenant context. Code review and CI lint rules block any query that touches a tenant table without going through this helper.

Honest caveat: we do not yet use PostgreSQL Row-Level Security (RLS) as a second line of defence. RLS hardening is a planned Phase 2 control. Today, tenant isolation is enforced at the application layer only — which means a bug in the application could, in principle, expose cross-tenant data. We mitigate this with centralised query helpers, strict code review, and tests that exercise the tenant boundary. RLS remains on the roadmap as a defence-in-depth upgrade.

• Input validation — Every API route validates its payload with a Zod schema. Anything outside the schema is rejected before it reaches business logic.
• CSRF protection — Mutating endpoints use a double-submit cookie pattern to reject cross-origin forged requests.
• XSS prevention — JSON-LD blocks on public profile pages are escaped via a dedicated safeJsonLd() helper, so tenant-authored content cannot inject script tags. React's default escaping covers the rest of the UI.
• Prompt injection defence — User-authored content that feeds AI prompts (job descriptions, knowledge entries, cover letters) is escaped for delimiter characters before being wrapped in XML-style context tags, reducing the blast radius of injected instructions.
• Rate limiting — Distributed, database-backed rate limits protect authentication, AI endpoints, the public chat widget, the support chat, and sensitive writes.
• Dependency hygiene — We pin dependencies, run automated vulnerability scanning, and upgrade promptly when advisories land on packages we use.
• Secrets management — Secrets live in Vercel environment variables scoped per environment (development / staging / production). No secret is ever committed to the repository.

We route all text AI calls through the Vercel AI Gateway, which gives us a single authenticated egress point to the underlying model providers (OpenAI, Google Gemini, Anthropic Claude). The gateway enforces our OIDC authentication and does not retain prompts or completions for training.

• We do not use your content to train AI models, and we require providers to honour API-tier terms (which forbid training on inputs by default) rather than consumer terms.
• We never send your full knowledge base in a single prompt. Only the specific snippets retrieved by vector search for the current request are included in context.
• The AI support assistant's Account agent — the only agent that can perform mutations on your behalf — always asks for an explicit confirmation from you before it writes anything.
• Voice sessions stream directly to Gemini Live. Raw audio is not persisted; transcripts are.

For the full list of AI providers and their privacy policies, see §4.2 of the Privacy Policy.

• Hosting — Vercel Fluid Compute, with automatic platform patching and region failover.
• Database — Neon Postgres with pgvector, point-in-time recovery, and daily backups.
• Object storage — Vercel Blob for resume PDFs, profile photos, and document uploads, scoped per environment.
• Cache — Upstash Redis for rate-limit counters and ephemeral state.
• Environment separation — Development, staging, and production are fully separated Vercel projects with unique secrets, databases, and Stripe keys. A compromise in staging cannot touch production.
• Deployment — Every change ships through pull request review, typecheck, lint, build, automated tests, and three independent code reviewers (Opus, Codex, Gemini) before merge.

A full, versioned subprocessor list lives in §5 of the Privacy Policy. We use established US-based vendors: Vercel, Neon, Stripe, Resend, Upstash, Sentry, and the AI providers routed through the Vercel AI Gateway. We will provide 30 days' notice before adding a new subprocessor that materially changes how your data is processed.

• Admin audit log — Every admin action is recorded with actor, target, timestamp, IP, and before/after state.
• Tenant audit log — Security-relevant tenant actions (login, password change, email change, subscription changes, API key actions, data export, account deletion) are recorded and visible to you in account settings.
• Error monitoring — Sentry captures application errors with a default PII scrubbing profile. We use these to fix bugs, not to profile users.
• Support telemetry — Support conversations are rated via CSAT and aggregated into an internal dashboard so we can catch regressions in the AI support assistant quickly.

We maintain a public status page at /status where active incidents are tracked in one of four states: investigating, identified, monitoring, or resolved. Recently fixed incidents remain visible for 14 days.

If we discover a security incident that affects your personal data, we will notify affected users within the timeframes required by applicable law (generally without undue delay and, where required, within 72 hours of confirmation) and describe what happened, what data was affected, and what we are doing about it.

AskCV is an early-stage, self-funded company. We have not pursued formal SOC 2, ISO 27001, or HIPAA certification and we do not claim them. We design our controls to align with industry best practices, and we plan to pursue formal attestation as the business scales and our customer base demands it.

We honour CCPA and GDPR rights (access, deletion, correction, export, objection) for all users regardless of residency — see §9 of the Privacy Policy.

We welcome reports from security researchers. If you believe you have found a vulnerability in AskCV, please email us at security@askcv.ai with a description of the issue, steps to reproduce, and your contact information.

We ask that you:

• Give us a reasonable window to investigate and remediate before publishing details.
• Avoid testing that could degrade the service for other users (no brute force, no denial of service, no social engineering of staff).
• Do not access, modify, or exfiltrate any data beyond what is necessary to demonstrate the vulnerability, and never intentionally access another user's account.

We do not currently run a paid bug bounty, but we will acknowledge valid reports publicly (with your permission) and fix confirmed issues quickly.

Security reports: security@askcv.ai

Privacy questions: privacy@askcv.ai

General support: support@askcv.ai or in-app at /support

AskCV LLC
Los Angeles, CA