Security
Last updated: 2 August 2026
Draft. Items marked
[[ LIKE THIS ]] are filled in once the company is
registered.
JobAgent holds your CV, your job pipeline and, if you connect them, tokens
for your own AI and data accounts. This page describes how that is protected —
and, at the end, what is not in place yet, because a security page
that only lists strengths is not much use to you.
Keeping accounts apart
This is the property everything else rests on. The database is shared, so
isolation is enforced in code rather than by separate instances:
- Every user-owned row carries an owner id, and every query filters on it.
Uniqueness is per user too, so two people can hold the same job posting
without colliding.
- A request that names a record belonging to someone else is
refused — it is not silently filtered into an empty
result, which is how such bugs hide.
- The MCP connector fails closed: if a request's identity
cannot be established, its tools return an error rather than falling back
to unscoped data.
- Infrastructure credentials (the ones our scheduled jobs use) map to an
identity that owns no rows, so they cannot be turned into a way to read
users' data.
Authentication
- Sign-in is handled by Clerk. We never see or store your
password, and Clerk provides MFA and social login.
- The browser extension and the MCP connector each use a
personal token that acts as you. Tokens are stored as
hashes — the raw value is never what looks you up — and you can revoke
and reissue either one from Settings at any time.
- The MCP surface also supports OAuth 2.1 with PKCE, with
Clerk as the authorization server, so a client can connect without any
token being pasted around.
- Revoking a credential takes effect immediately, not at the next
expiry.
Encryption
- All traffic is over HTTPS.
- The database is encrypted at rest by the provider, and on top of that the
sensitive fields — your connected Claude token and any API keys you add —
are encrypted by the application before they are stored,
with a key held only in the server environment.
- Access tokens are stored hashed (SHA-256).
- We never receive card details; payments go directly to Stripe.
Where it runs
- Backend and database: Railway, EU region (Frankfurt).
The database is reached over the provider's private network, not the
public internet.
- Frontend: Vercel. It holds no application data.
- The browser extension and the optional local runner execute on
your machine, under your own browser session. The runner
binds to localhost only and accepts requests solely from the JobAgent
app's origins.
Outbound requests
The Service follows links that come from job postings — untrusted input. A
guard resolves every such URL first and refuses private, loopback, link-local
and cloud-metadata addresses, re-checking after each redirect, so a crafted
posting cannot make our servers reach something internal.
Abuse and cost controls
- Per-user and per-IP rate limits on the endpoints that spend money.
- Daily per-account caps on AI actions, so a runaway loop cannot drain your
own AI quota.
- Where you connect your own AI or data keys, the platform's keys are never
substituted silently — an account without a key is told, not billed to
someone else.
Logging and auditing
- Access-log query strings are scrubbed, so tokens that
must travel in a URL never land in logs.
- Operational logs are kept for 30 days or less.
- Security-relevant account events — token regenerated, data exported,
account deleted or restored — are written to an audit log, without ever
recording the secret itself.
Your own controls
- Export everything under your account as JSON, from the
app.
- Delete your account: credentials are revoked at once and
the data is held for a 30-day grace period before permanent removal.
Records that must be retained for tax or audit are anonymised, not kept
against your name.
- Disconnect any AI or data account at any time; the
features depending on it stop, nothing else is affected.
What is not in place yet
Stated plainly so you can judge the risk yourself:
- Backups are provider-managed and the restore has not yet been
exercised. An untested backup is not a backup, and we will
update this line once a restore has actually been performed and
verified.
- No third-party penetration test has been carried out.
- No SOC 2, ISO 27001 or comparable certification.
- Error monitoring is configured but not switched on in
production yet.
- Rate limits are enforced per server instance rather than centrally, so
a scaled-out deployment would allow proportionally more before
throttling.
- This is a small operation, not a 24/7 on-call team. Serious issues are
handled as fast as one person reasonably can.
Reporting a vulnerability
If you find a security problem, please report it privately to
[[ SECURITY EMAIL ON YOUR OWN DOMAIN, e.g. security@… ]]
before disclosing it publicly. Tell us what you found and how to reproduce it;
we will confirm receipt, keep you updated, and credit you if you would like.
Please do not access, modify or retain other people's data while testing.
See also our Privacy Policy and
Terms of Service.
[[ YOUR REGISTERED NAME ]] · sole trader
(ditta individuale) established in Italy · VAT number (partita IVA)
[[ NUMBER ]]