Security

Where the data lives

• Stored in India. Everything a company puts in, and everything its candidates say, is stored in Amazon Web Services in the Mumbai region (ap-south-1), on infrastructure in our own AWS account.
• Processed in Asia Pacific. The models that conduct the interview, write the evaluation and compare candidates run in Amazon Bedrock inside that same account. Amazon routes those calls within the Asia Pacific region, so processing may happen outside India. No third-party AI vendor receives an interview.
• Encrypted at rest and in transit. The database volume and the server's disk are encrypted, and every storage bucket encrypts by default and blocks public access. Every connection is HTTPS: plain HTTP is redirected, and browsers are told to use HTTPS for this domain and every subdomain for two years.
• Sub-processors: Amazon Web Services, and Cloudflare on the contact form only. The privacy notice lists exactly what each one receives.

How one company is kept apart from another

Every company's rows carry its id, and the database enforces row-level security on every table, so a signed-in member can read only their own company's data. We test that with the same keys a browser is given, from three identities: nobody, a stranger who belongs to no company, and a member of one company. The test asserts both directions, that a member can read their own company and cannot read anyone else's, because a rule that refused everything would pass a one-sided test.

Server code that has to act across that boundary checks membership and role first, then scopes every query to the company it just checked. Inside a company there are four roles (owner, admin, recruiter and viewer), and money, members and settings sit behind the top two.

Who can get in, and how

• No passwords exist. Hiring staff sign in with a link emailed to them, and a link is only ever sent to an address we already know: someone invited, a member, or an operator. The sign-in page answers identically whether or not the address is known, so it cannot be used to find out who works where.
• Candidates have no account. Each interview has its own link, and the candidate also proves they control the invited email address with a six-digit code before the interview starts. Links expire, and issuing a new one kills the old one.
• Every token is stored as a hash. Interview links, shared dossier links and API tokens are random values of which we keep only a SHA-256 hash, so a copy of our database would not let anyone open an interview or call the API. An API token is shown once, when it is created.
• Our own operators sign in to a separate console that no company account can reach. It supports a second factor from an authenticator app and can be restricted to known network addresses, and every change it makes is written to an audit log.
• Pages a stranger can reach are rate limited: both sign-in forms, the contact form, the page a candidate uses to recover a lost link, and the API, where repeated bad tokens from one address get that address refused for a while.

Retention and erasure

Each customer sets a retention window in their contract, and a daily job erases candidate data once it passes. Erasure deletes the transcript, the evaluation, the camera summary, the resume file and its text, the team's notes about the person and any comparison that names them, and replaces the candidate's name and email with a tombstone. What is kept is that a round happened, when, and what it cost, because invoices have to stay reconstructable, and none of that is personal data.

• Every erasure is recorded, scheduled or requested, with what was removed and when, and that record survives even the customer's own account being closed.
• A callback that was about to carry the dossier to you is cleared too, so a queued delivery cannot post a copy after the erasure, and integrated customers are sent a round.erased notice so their own systems can follow.
• The job reports whether it is running, not just whether it failed, and we are alerted if it stops.
• Backups outlive an erasure by up to 35 days. A nightly database backup is kept for 35 days and a daily disk snapshot for 7, both encrypted and in the same region, so an erased record can survive in a backup for at most that long.

The AI, and what it is given

• Nothing is used for training. No interview, ours or a customer's, is used to train or tune any model, and we have no custom models.
• Prompts and answers are not logged by the model service. Bedrock's invocation logging, which would keep a copy of every prompt and reply, is turned off in every region our calls can reach.
• Every finding quotes the candidate. A finding in an evaluation must cite the candidate's exact words from the interview, and code checks each quote against the transcript and drops any finding whose quote is not there, so the model cannot attribute something to a candidate that they did not say.
• No video or audio is recorded. The camera check runs in the candidate's own browser and sends only a summary. Body language notes are advisory, never part of the score, and can be switched off per company where emotion recognition in hiring is not allowed.

Logs, monitoring and the application itself

• Logs carry no candidate content. Errors are written as structured lines with addresses and similar values redacted before they leave the process, they never include what a candidate said or what a model wrote, and they are kept for 14 days. We do not send errors to a third-party error tracker, because that would put a copy of the data somewhere our erasure cannot reach.
• Failures alert us, and so does silence: the jobs that erase data and deliver callbacks report that they are alive, and an alarm fires if they stop.
• No third-party scripts or fonts load on any page a candidate sees. Fonts are served from our own domain.
• Standard browser protections are on every response: pages cannot be framed by another site, content types are not sniffed, and the camera and microphone are only available to our own pages.
• Outbound callbacks are signed with a per-customer secret over a timestamp and the exact body, sent only to HTTPS addresses that do not resolve to a private network, never follow a redirect, and leave from one published address. Details are in the integration guide.

The servers

• Only HTTPS is open to the internet, plus port 80 to redirect to it. There is no SSH port: administrative access goes through AWS Systems Manager, which needs no open port and is logged by AWS.
• Secrets live in AWS Parameter Store, read by the server at start, never in the code or the image. The few secrets the application must store in its database, such as a callback signing secret, are encrypted with AES-256-GCM before they are written.
• The server's own AWS permissions are narrow: the model and speech services are only usable in their intended regions, and each storage bucket is reachable only by what needs it.
• One instance, one availability zone. The product runs on a single server today. It is snapshotted daily and its database backup is tested by being restored every night, but an outage of that server is an outage of the product until it is restored.

What we do not have yet

We do not hold a SOC 2 report or an ISO 27001 certificate. This page is what we can show instead, and every statement on it is something the product does today rather than a policy we intend to follow.

Reporting a problem, and asking more

If you find a security problem, report it through the form on this site before telling anyone else. The terms say how we treat people who do. If your review needs something this page does not answer, ask us.