Security

Last updated: 15 August 2026

You are about to hand us your resume. This page is how we earn that: every protection described here is built and running today, and you can hold us to all of it.

For what we collect, why, who receives it and your legal rights over it, read the Privacy Policy. This page is about the mechanics.

1. What we hold, and where

The resume file you uploaded and the text extracted from it.
Your contact details, your links, and the answers you save for application forms.
Your applications: which job, when, what was submitted, and the exact answer given to every question on the form.
Your plan and your payment records.

It lives in one database on one server in the European Union. Card and UPI details are not on that list and never have been: those are entered on Razorpay's side and never reach us.

Who can read it: the server, to match and apply for you, and the AI providers listed in section 6 for the specific job being processed. Every user-facing query is scoped to the account that asked, on the server. The browser is never trusted to say who you are. No screen in the product shows another person's resume, saved answers or application contents, and that includes the operator's own admin screens, which list accounts, plans and counts. There is no recruiter-facing search of candidate profiles. Settings carries an opt-in for a future one, switched off by default, and nothing reads it yet.

2. Getting your data there and back

Served over HTTPS only, behind Cloudflare. Every response carries:

HSTS for one year, subdomains included. A browser that has seen the site once refuses to talk to it over plain HTTP again.
A refusal to be framed by any other site. Cancelling a subscription, approving an application and skipping a job are all one click, and without this any page anywhere could frame them and harvest those clicks.
An instruction never to guess a file's type. An uploaded resume served back with a guessable type is the classic route from "file upload" to "runs as code".
A trimmed referrer. Clicking through to an employer does not hand that employer the address of the page you came from.
Camera, microphone, location and the browser payment API switched off. Nothing here needs them, so nothing here may ask.

Only the web app is reachable from the internet. The engine that owns the database has no public route at all: it listens on the machine itself and the app forwards to it inside the box. The machine in turn accepts web traffic only from Cloudflare's published address ranges, so learning the server's address buys an attacker nothing. That was verified by connecting to it directly and getting no answer at all.

Administrative access to the server is by key only. Password login over SSH is off.

3. At rest

Provider API keys stored in the product are encrypted with AES-256-GCM under a key derived from a server-side secret that is not in the database, so a stolen database is not a stolen set of keys. The repository is private, and its full history has been scanned for committed secrets.

Your resume and profile sit in a database that has no route from the internet at all, reachable only by the application itself, on a machine that accepts web traffic from Cloudflare and administrative access by key. If you see a service our size advertising "bank-grade encryption" for a row in a database, they are describing the disk it sits on, which is a different claim than it sounds like.

4. Passwords and sessions

Passwords are hashed with scrypt using a fresh random salt for each one, and compared in constant time. We cannot read your password, and a database dump does not contain it.
Signing in with an address that has no account costs exactly as much time as signing in with one that does, because the comparison runs either way against a decoy. Response timing does not reveal who has an account here.
"Forgot password" returns the same answer whether or not the address is registered.
A session is a long random token stored on the server. Its cookie is HttpOnly, so page scripts cannot read it, SameSite, so another site cannot ride it, and Secure in production, so it never travels over plain HTTP. Sessions last 30 days and expired ones are deleted.
Reset links work once and expire in 30 minutes. Completing a reset destroys every existing session on the account, so a stolen session does not survive a password change.
Sign-in attempts, one-time codes, account actions and expensive reads each get their own rate budget, and exceeding one tells you how long to wait. They are separate on purpose: mistyping your password three times must never be what stops you cancelling a subscription.

There is no two-factor authentication yet. Section 11.

5. We never sign in as you

This is the one that decides whether a job tool is safe to use, so here it is plainly.

We never ask for your LinkedIn, Naukri or Indeed password. There is exactly one password field in the entire data model, the one for your AutoApply account. There is nowhere to put a job-site password because we built nowhere to put it.
Automatic submission happens only on the employer's own application form, hosted by Greenhouse, Lever, Ashby, Workable or Recruitee. No platform account is involved, so there is no account to restrict.
LinkedIn postings reach us through LinkedIn's public guest search, the same pages a signed-out visitor sees. No login, so no exposure.
LinkedIn Easy Apply and Workday are not automated here at all. Those forms need a browser already signed in as you, which a server does not have, and driving Easy Apply from your own session is against LinkedIn's terms. Those jobs open the posting in a new tab for you to finish. Every job card states its label before you click.

Tools that drive Easy Apply from your own browser put your LinkedIn account inside the automation, and account restriction is a real outcome of that, not a theoretical one. We left the feature out of the hosted product instead of shipping it and hoping. It costs us a headline number of "applications sent". It is still the right trade with somebody else's professional identity.

6. What reaches an AI provider

AI does three jobs here: ranking postings by meaning, re-wording your resume for a specific role, and drafting answers to open-ended screening questions. A request carries the job description, your resume text, and the answers you saved. Your resume carries your name and contact details, so read that plainly: the provider sees your resume. Our providers are named in the Privacy Policy.

What never goes: your password, which we do not have, your payment details, which never reach us either, and any other user's anything.

Your equal-opportunity answers never go either. Gender, race or ethnicity, disability status, veteran status and pronouns are withheld from every AI request, including ones about something else entirely. Those five are answered from what you saved, in code, so no model ever needs them, and a form that asks one we do not recognise is handed to you rather than guessed at.

Two rules bound what the model is allowed to do, and both are enforced in code:

Personal facts are resolved in code, never by the model. Notice period, expected salary, work authorization, visa status, start date and the equal-opportunity answers are read from what you saved and inserted literally. A missing fact leaves the field blank and stops the application to ask you, rather than being filled in with a guess. This rule exists because a model asked for an expected salary once lifted a figure straight out of the posting's own pay band.
A job posting is data, never instructions. Descriptions and scraped form questions are fenced as untrusted in every prompt, so text inside them addressed at an AI cannot add a claim about you or change a rule. Tailored resumes are then re-checked against your original, and any line claiming a skill your real resume does not contain is dropped before an employer sees it. Gaps get reported to you, never papered over.

We do not train any model on your data. What the providers do with API traffic is governed by their own terms, and we do not hold a zero-retention agreement with either of them. We would rather write that sentence than imply otherwise.

7. Payments

Razorpay is the payment processor of record. Card and UPI details are entered on their side and never touch our servers, so there is no card data here to lose.

The price is decided by the server. The browser names a plan, not an amount, so nothing sent from a page can change what you are charged. Every message we accept back from Razorpay, including the automated ones, is verified with a signature checked in constant time against the untouched original message. An unsigned or altered one is rejected and raises an alert.

8. Backups

A nightly job backs up the database, your uploaded files, and the key material without which neither can be read. The backup directory and everything in it is restricted to the server's administrative account. A dump that fails, returns unreadable, or comes back implausibly small is deleted rather than left sitting there looking like a healthy backup, and the job exits with an error so the failure is noticed. Copies older than seven days are removed.

We have actually restored one. A full dump and restore into a scratch database was rehearsed on the production box in August 2026: row counts and index counts matched, and the only difference was the handful of job postings that arrived while the dump was running, which is the recovery window made visible rather than a defect.

Since 15 August 2026 every nightly backup is also copied to separate object storage in a different place from the server, and the copy is compared against the original before the run is allowed to report success. Losing the server no longer means losing the backups. That storage is private, and its access key can reach nothing else.

Recovery is a person restoring from a verified copy rather than an automatic failover, so an outage lasts as long as that takes. Section 11.

9. Taking your data out, or deleting it

Both live in Settings, under Privacy. Neither needs an email to us or our permission.

Export hands you one file containing your account, profile, preferences, saved answers, applications, alerts, saved searches and payment records.

Delete removes, immediately and from the live database: your profile and resume text, the uploaded file and every generated PDF from the server's disk, tailored resumes, cover letters, screening answers, saved facts, preferences, applications, alerts, saved searches, every session, every pending email link, and any provider keys you added. A live subscription is cancelled first, so nothing can keep charging an account that no longer exists. Usage counters are detached from you rather than deleted, so aggregate numbers stay correct while pointing at nobody.

Two things survive on purpose and the Privacy Policy explains both: payment records, which are financial records we are required to keep, and a one-way keyed hash of your email address carrying a single number, how much of the free application allowance that address used. It cannot be turned back into an address.

Applications already delivered to an employer live in that employer's systems under their policies. We cannot recall them.

10. Reporting a security problem

Email [email protected] with "Security" in the subject. Tell us what you found, how to reproduce it, and how you would like to be credited.

What you get: an acknowledgement within 72 hours, a straight answer on whether it is real, and either a fix or a stated reason why not. If you report in good faith we will not pursue you legally, will not contact your employer or your hosting provider about it, and will not treat the report as a breach of our terms.

What we ask: test against your own account only, never access or change anyone else's data, no denial of service and no high-volume automated scanning against a live service with real people using it, and give us a reasonable window before publishing.

We do not run a paid bounty programme, and we will not advertise rewards we are not set up to pay. Report something real and you will get a fast, human reply and public credit if you want it.

11. Two things worth knowing before you sign up

We would rather you hear these from us than discover them later.

Your account is protected by a password, not a second factor. Two-factor authentication is on our list. Until it ships, use a password you do not use anywhere else, and a password manager if you have one.
Recovery from a serious outage is a person, not a switch. Backups are off-site, nightly and verified, and we have restored from one. But if the service goes down hard, it comes back when someone brings it back, not automatically. An external monitor watches it around the clock, so we find out immediately rather than waiting for you to tell us.

Neither of these puts your data at risk. They are about convenience and uptime, and we would rather name them than let you assume otherwise.

This page changes when the product does. If something here stops being true, it is corrected here in the same change that made it untrue. Questions: [email protected].