Security

Last updated: 15 August 2026

We are asking you to upload your resume and pay for a service. This page says what protects that, control by control, and what does not exist yet. Everything described here is built and running today. Everything missing is in the last section rather than left out, because a security page that only lists wins is a marketing page.

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.

The honest limit: your resume and profile are stored in the database without a second layer of per-row encryption. They are protected by the fact that the database has no public route, by operating-system permissions, and by the access rules above. Any service our size that advertises "bank grade encryption" for a row in a database is describing the disk, not the row.

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.

The honest limit: those copies sit on the same machine as the data. Off-site replication is not configured yet, so losing that disk means losing them. 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.

There is no paid bug bounty. We are too small to fund one honestly, and advertising rewards we cannot pay would be its own kind of dishonesty.

11. What we have not done

No third-party security audit and no penetration test. Nobody outside this project has reviewed the code or the deployment.
No certification of any kind. Not SOC 2, not ISO 27001, not anything. We hold none, so none appears on this page.
No two-factor authentication. Your account is a password and a session cookie.
No off-site backup replication. The copies exist and restore correctly, on one machine.
One server, one process. There is no second region and no automatic failover. If the box goes down, the service is down until it comes back. A public health check is polled by an external monitor so we find out from the monitor, not from you.
Your resume is not encrypted row by row inside the database. Section 3.
Your saved answers travel as one block with an AI request rather than being narrowed to the single question being asked. Equal-opportunity answers are held back entirely (section 6), but a link or a start date can still sit in the context for a question that did not need it. Scoping the rest per question is on the list.
Cross-account isolation is designed in and reviewed, not formally proven. Every user-scoped table carries an owner and every query filters on it, two independent review passes went looking for reads that cross accounts and found none, and a simulated attacker probing for exactly that found real authorization defects, which are fixed. A systematic two-account test across every table has not been run.
One person operates this. No on-call rotation, no security team, no separate reviewer. That is the real risk profile, and pretending otherwise would undo the point of this page.

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].