Security

Last updated 20 September 2026

We hold people’s résumés, applications and, if they choose, access to their mailbox. This page says plainly how that is protected and how to tell us when something is wrong.

How your data is protected

Separation by default. Every request to the database runs as a restricted role with row-level security scoped to the signed-in user; the application cannot read another account’s rows even if a query is wrong.
Least privilege on columns. Users can update only the fields a feature needs — they cannot write their own match scores, mark an approval as sent, or create their own notifications.
Third-party credentials in a vault. Mailbox refresh tokens are encrypted with a per-secret data key wrapped by a master key held in a key management service. The application role has no access to the vault table at all, and the checks that prove it run on every deploy.
Encryption in transit (TLS) and at rest, with backups encrypted too.
Minimal email data. We never store the body of your email; only sender, subject and a short snippet of job-related messages.
Audit trail. Sign-ins, account changes, approvals and data requests are recorded, with tokens, cookies and personal identifiers redacted from logs.
No training on your data. Model providers process your content to answer a request and do not train on it.
Approval before anything leaves. Emails and applications are recorded as approvals and wait for your explicit click, and every send happens exactly once.

How we build

Every change is reviewed, type-checked, linted and tested in continuous integration, with static analysis and dependency scanning on each commit.
Secrets live in environment configuration or a key management service, never in the repository or the browser bundle.
Access to production data is limited, logged, and used only to operate the service or support you when you ask.

Reporting a vulnerability

Email security@findmycareer.ai with enough detail to reproduce the issue. We aim to acknowledge within 2 working days and to keep you updated until it is fixed. Please give us a reasonable window — 90 days is our default — before disclosing publicly.

In scope: our web application, API and background workers. Out of scope: denial of service, social engineering, physical attacks, spam or best-practice reports without impact, and anything against third-party providers.

If you act in good faith, stay within scope, avoid privacy violations and data destruction, and give us time to fix the issue, we will not pursue legal action and will credit you if you’d like.

What we’re still working on

We would rather be specific than vague: an independent penetration test and a SOC 2 Type II report are planned before enterprise availability, and Google’s restricted-scope security assessment is required before mailbox sync is generally available. We’ll update this page as each lands.