Security
JN Dossier asks for something people don't hand over lightly — an honest account of their career, including the parts they'd rather not say out loud. This page explains, in plain language, how that's protected. It's built and maintained by a security engineer (more here), and every claim below is something that's actually implemented — not aspirational.
Encrypted at rest
Your master profile is encrypted before it's ever written to storage, using a key held separately from the data itself (in a secrets manager, not in the same place as your file). A stolen disk, a leaked bucket, or another operator with storage access sees ciphertext — not your career history.
The honesty filter — a single, fail-closed boundary
Anything marked private, confidential, or "don't claim this" in your profile is stripped by one dedicated filter before any export leaves the system. If that filter can't positively confirm an item is safe to include, it excludes it — fails closed, not open.
Your conversation stays server-mediated
The AI interview reads and writes your profile through a controlled server-side mechanism — the raw profile JSON is never sent to your browser during a conversation, and the model is instructed never to reproduce it as text.
Content-free by default
Product analytics record numbers and event names (turn counts, token counts, timing) — never the content of what you say. There's a hard allowlist on what's allowed into telemetry; anything not on it is dropped.
Access control
Every request to the backend requires a verified sign-in token. The admin console is gated by a hard-coded email allowlist, checked server-side on every request — there is no in-app way to grant yourself admin access.
Uploads are treated as data, not instructions
Résumés and other uploaded documents are explicitly wrapped and marked as untrusted data before being shown to the AI, with an instruction never to follow anything inside them as a command — a defense against a manipulated file trying to hijack the conversation. Uploads are also screened for known manipulation patterns; a flagged file is never blocked (the structural defense above is what actually matters), but it is surfaced so it can be reviewed.
We watch for trouble, not just prevent it
Repeated failed sign-ins, unusual request patterns, and rejected uploads are tracked as security events — content-free, the same discipline as the analytics above — with automatic severity escalation when a pattern crosses a threshold. This isn't a promise that nothing bad can happen; it's a promise that if something does, there's a trail.
Every administrative action is logged — and the log can't be quietly edited
When an account's access is changed, that action is recorded with who did it and when, in a tamper-evident log: each entry is cryptographically chained to the one before it, so altering or deleting a past entry breaks the chain in a way that's detectable, not just theoretically auditable.
Kept current
Dependencies are pinned and checked against known-vulnerability databases; findings get patched rather than left to accumulate.
What this is — and isn't
This is "zero-knowledge at rest" — the storage layer can't read your data, but the running server can, briefly, while actively processing a request (the same way any service that has to reason about your data must). It is not full end-to-end encryption. We think that's an honest, useful middle ground; we'll say so plainly if that ever changes.
Questions or something looks off? Contact us here.