What we have done about security, and what we have not.

Can see

Who holds which role. Every integration, its scopes, who connected it. Every control on this page and its live state. The audit log. Which AI provider processes what.

Cannot see

Candidate names, emails or files. Transcripts, deliverables, scorecards, verdicts. Interview content of any kind.

How is authorization enforced?

in placemeasured live in the app

One permission model. Permissions are named for what they protect rather than who holds them, and every check asks can(role, permission). An unknown role holds nothing, so a typo fails closed.

Can somebody reviewing your security see candidate data?

in place

No. The Security role reads every control, integration and audit entry, and no candidate, transcript, deliverable or scorecard. An auditor who can change what they audit is not an auditor.

Can any employee of yours view a customer's data?

in place

Only an account owner can view their own organization through another member's eyes, and only within that organization. It cannot be used to climb, and the real identity is carried alongside: every audit event and configuration snapshot names the owner as the actor and records the seat they were viewing from. Deploy Ready staff have no such route into a customer account.

Do you keep an audit log, and can it be tampered with?

in placemeasured live in the app

Yes, and there is no write path from a client — events are recorded from inside the action that caused them. Nothing updates or deletes a row. Reading the log is itself an audited event, and a refused read is recorded as denied.

Could a secret end up in your logs?

partial

Redaction happens in the audit helper rather than at each call site, catching credentials both by field name and by the shape of the value, at any depth. Application logs are less rigorous and are the weaker half of this answer.

To close it: A structured logger with the same redaction applied to application logs.

How do you keep one customer's data away from another's?

in placemeasured live in the app

Every tenant-owned table carries an org_id, and every read scopes to it in the query rather than filtering afterwards. A static check in CI fails the build if any route reads a whole tenant table.

Do you test for cross-tenant access?

in place

Yes, two ways: a static check over every API route that runs on each push, and a live-data assertion that every tenant row is attributed. The static one found a real leak that code review had missed three times.

Is isolation enforced at the database as well as the application?

not donemeasured live in the app

No. Row-level security is not enabled, and the application connects with a role that would bypass it. Isolation is enforced in the application layer only, and verified by the check above.

To close it: A non-superuser role without BYPASSRLS, a per-request tenant setting inside a transaction, and a policy on every table.

Are third-party credentials encrypted at rest?

in placemeasured live in the app

Yes. OAuth access and refresh tokens and ATS API keys (Greenhouse, Ashby, Lever, SmartRecruiters, Workable) are sealed with AES-256-GCM before they reach the database, with a per-value IV and an authentication tag. The key comes from the platform's secret store, never from the application. An ATS key stored before sealing existed is re-sealed the next time it is read.

Is the database encrypted at rest?

in place

Yes, by the managed provider. Worth noting this protects the disk, not the row — which is why credentials are separately sealed above.

Where do encryption keys live?

in place

In the deployment platform's encrypted environment store, and in a local .env for development. Never in source control — a key the application can mint would end up in the same backup as the data it protects.

Is data encrypted in transit?

in place

Yes. All API traffic is HTTPS, and the interview room's media and data channels are WebRTC with DTLS-SRTP.

Candidate code runs somewhere. Where, and how is it contained?

in place

On the candidate's own machine, in their own shell, as them. We are not a sandbox and do not claim to be one — the boundary is that their machine is neither ours nor the interviewer's. Nothing a candidate writes executes on our infrastructure.

It is an Electron app. How is it hardened?

partial

Context isolation is on and node integration is off in the renderer, which is one local document that may not navigate anywhere else; new windows are refused and links open in the person's own browser. A Content Security Policy forbids inline and remote script. Pages may ask the OS only for the camera, microphone, screen, fullscreen and clipboard write. The preview's embedded page gets no preload and no Node, is sandboxed, and may only point at this machine. File access over IPC — the tree, reads, writes, the profile read-back and the workspace snapshot — is confined to the workspaces the main process itself opened, resolved through symlinks so a link committed into a repository cannot point out of it; repository status, change-watching and reveal-in-Finder still take a renderer-supplied root and leak only metadata. The candidate's shell starts from an allowlisted environment rather than the app's own. The renderer itself does not yet run under Electron's sandbox, and IPC payloads are checked by the handlers that take paths rather than validated as a whole.

To close it: Electron's `sandbox` on the renderer, and schema validation on every IPC payload rather than only on the handlers that take paths.

Do you record interviews?

does not apply

No. There is no video or audio recording, by choice. A transcript is produced from speech on each participant's own machine, and the code the candidate wrote is stored as a deliverable.

What monitoring runs on a candidate's machine?

in place

Only with their explicit consent, shown as a full list before anything runs, and declining is recorded rather than penalised. It never reads their screen, keystrokes, files or other applications, and cannot prevent anything from running. We can detect, with permission; we cannot enforce, and do not claim to.

How do users authenticate?

in place

GitHub OAuth, or a single-use email link that expires in fifteen minutes. There are no passwords, so there is no password store to breach or policy to enforce.

How are sessions handled and revoked?

partial

Sessions are server-side rows with an expiry, checked on every request. Signing out (POST /api/auth/signout) deletes the row the cookie names and clears the cookie, so a session ends when the person ends it rather than when the clock does. There is no per-device session list yet, so a session on a machine you no longer hold cannot be ended from another one.

To close it: Visible device and session list, with revoke.

Do you support multi-factor authentication?

partial

Not directly. Where sign-in is through GitHub, that account's MFA applies. The email link path has no second factor of its own.

To close it: MFA on the email path, and an organization setting to require it.

Do you support SAML or OIDC single sign-on, and SCIM provisioning?

not done

Not yet. The identity model is email-or-OAuth with a session table, which is compatible with adding them — no password store would have to be unwound first.

To close it: A SAML/OIDC provider per organization, and SCIM for provisioning and deprovisioning.

Does our data reach an AI provider, and is it used for training?

partial

Only if a customer uses the assistant. Where the interviewer has their own Claude installed it runs on their machine and nothing is relayed to us. Otherwise a request goes to Anthropic. There is no organization-level policy to restrict providers yet, and no central layer recording exactly what is sent.

To close it: One AI provider layer that records what is sent where, and a per-organization policy over it.

Who are your subprocessors?

partial

Hosting and database, media relay, email delivery, and an AI provider when the assistant is used. There is no published subprocessor list yet.

To close it: A maintained subprocessor list with what each receives and why.

What access do your integrations request?

in placemeasured live in the app

Calendar access is free/busy where the provider supports it. ATS imports of job postings need no key at all for three of the five providers. Every connection records who made it and when.

What do you store from our ATS?

in place

For job postings: an external id, a title, a location and a URL. Greenhouse returns dozens of fields per job; four are kept. Candidate records are only created when a customer imports them.

Is isolation enforced at the database as well as the application?

not donemeasured live in the app

No. Row-level security is not enabled, and the application connects with a role that would bypass it. Isolation is enforced in the application layer only, and verified by the check above.

To close it: A non-superuser role without BYPASSRLS, a per-request tenant setting inside a transaction, and a policy on every table.

Do you support SAML or OIDC single sign-on, and SCIM provisioning?

not done

Not yet. The identity model is email-or-OAuth with a session table, which is compatible with adding them — no password store would have to be unwound first.

To close it: A SAML/OIDC provider per organization, and SCIM for provisioning and deprovisioning.

How do you handle vulnerable dependencies?

not done

Lockfiles are committed. There is no automated scanning or update policy, and secret scanning on private repositories is a paid add-on we do not have.

To close it: Dependabot or equivalent, plus a triage expectation.

How are desktop builds signed and updated?

not done

Code signing is configured for macOS and Windows but not yet issued, so builds are unsigned today. There is no auto-update channel, which also means there is nothing to hijack.

To close it: Signing certificates in place, a signed update channel, and the ability to stop a bad release.

Are development and production separated?

not done

There is one database, and development runs against it. That is the weakest answer on this page. Another product's tables also share the instance.

To close it: A separate development database, seeded rather than copied from production.

What happens if you have a breach?

not done

There is no written incident response plan. The architecture supports investigation — an audit log, credential revocation and per-integration disconnection — but the process around it is not documented.

To close it: A runbook: what counts as an incident, who is notified, how credentials rotate, how customers are identified and told.

Have you had a penetration test?

not done

No. The boundaries most worth testing — tenant isolation and authorization — are covered by automated checks that run on every push, but that is not a substitute for somebody trying to break in.

To close it: An external test once the surface is stable.

Do you have SOC 2?

not done

No, and we will not claim otherwise. The architecture is being built so that certification becomes documenting controls that already exist rather than a rewrite. This page is part of that.

To close it: Type I after the controls above are in place; Type II after an observation window.

Do you support multi-factor authentication?

partial

Not directly. Where sign-in is through GitHub, that account's MFA applies. The email link path has no second factor of its own.

To close it: MFA on the email path, and an organization setting to require it.

How are sessions handled and revoked?

partial

Sessions are server-side rows with an expiry, checked on every request. Signing out (POST /api/auth/signout) deletes the row the cookie names and clears the cookie, so a session ends when the person ends it rather than when the clock does. There is no per-device session list yet, so a session on a machine you no longer hold cannot be ended from another one.

To close it: Visible device and session list, with revoke.

Could a secret end up in your logs?

partial

Redaction happens in the audit helper rather than at each call site, catching credentials both by field name and by the shape of the value, at any depth. Application logs are less rigorous and are the weaker half of this answer.

To close it: A structured logger with the same redaction applied to application logs.

Do you classify data by sensitivity?

partial

Four levels, with candidate PII, transcripts, deliverables, scorecards, OAuth tokens and customer source code all treated as the most sensitive. It governs logging, retention and access.

To close it: The classification applied per column rather than held as documentation.

How long do you keep candidate data?

in progressmeasured live in the app

Indefinitely at present. Nothing expires. Retention is designed — per organization, per data class, with a legal hold — but not built.

To close it: Per-class retention with a scheduled job, and a legal-hold flag that suspends it.

Can you delete a candidate's data on request?

partial

Partly. Deleting a record cascades to its dependent rows in the database, but there is no single verified erasure path covering every store, and no way to evidence that it completed.

To close it: One erasure operation across database and object storage, with an audit record proving completion.

Where is data stored, and can we choose the region?

partial

United States, on managed infrastructure. There is no regional choice, which is a gap for customers with EU residency requirements.

To close it: A region per organization, and a data map to support it.

It is an Electron app. How is it hardened?

partial

Context isolation is on and node integration is off in the renderer, which is one local document that may not navigate anywhere else; new windows are refused and links open in the person's own browser. A Content Security Policy forbids inline and remote script. Pages may ask the OS only for the camera, microphone, screen, fullscreen and clipboard write. The preview's embedded page gets no preload and no Node, is sandboxed, and may only point at this machine. File access over IPC — the tree, reads, writes, the profile read-back and the workspace snapshot — is confined to the workspaces the main process itself opened, resolved through symlinks so a link committed into a repository cannot point out of it; repository status, change-watching and reveal-in-Finder still take a renderer-supplied root and leak only metadata. The candidate's shell starts from an allowlisted environment rather than the app's own. The renderer itself does not yet run under Electron's sandbox, and IPC payloads are checked by the handlers that take paths rather than validated as a whole.

To close it: Electron's `sandbox` on the renderer, and schema validation on every IPC payload rather than only on the handlers that take paths.

Does our data reach an AI provider, and is it used for training?

partial

Only if a customer uses the assistant. Where the interviewer has their own Claude installed it runs on their machine and nothing is relayed to us. Otherwise a request goes to Anthropic. There is no organization-level policy to restrict providers yet, and no central layer recording exactly what is sent.

To close it: One AI provider layer that records what is sent where, and a per-organization policy over it.

Who are your subprocessors?

partial

Hosting and database, media relay, email delivery, and an AI provider when the assistant is used. There is no published subprocessor list yet.

To close it: A maintained subprocessor list with what each receives and why.

What runs before code ships?

partial

Type checking, a build, and the security boundary tests, on every push. They do not gate deployment yet, and deploys still run from a developer machine.

To close it: Deploys from CI, protected branches, and dependency and secret scanning.

What are your backup and recovery arrangements?

partial

Automated backups are provided by the managed database. No restore has been tested, so recovery time is unproven.

To close it: A tested restore on a schedule, with the result recorded.

Which of your staff can reach customer data?

partial

Production database credentials are held by one person. There is no separate staff access path into a customer account, and no support impersonation.

To close it: Named roles for production access, with the access itself audited.

A Security seat can be invited today, at no cost, and can review a sandbox organisation with nobody real in it. What it cannot yet do is run each verification itself from this page; that is on the roadmap, and until it is, the register points at the code and the tests instead. Every change to how you interview is kept separately, as a version — history.