Security at InstaCruit

• Application hosting. The application runs on Vercel. We do not operate our own servers, and there is no self managed operating system for us to patch. Platform level patching, network isolation and edge DDoS protection are handled by the provider.
• Database. Managed PostgreSQL on Supabase, encrypted at rest by the provider, with the provider's automated backups. The application connects over TLS through a connection pooler.
• File storage. Resumes, interview recordings and asynchronous video answers are held in Supabase object storage, encrypted at rest by the provider. Files are served through time limited signed URLs rather than open public links wherever the product requires authentication.
• Real time media. Live interview audio and video runs over LiveKit using encrypted WebRTC transport. Live AI voice runs directly from the candidate's browser to the AI provider over an encrypted connection, using a short lived credential minted by our server, so a long lived API key is never present in the browser.
• Background work. Analysis and integration sync run as queued jobs through Upstash QStash, with signature verified delivery, and as scheduled jobs that require a shared secret before they will execute.
• In transit encryption. TLS 1.2 or higher on every external connection. HTTPS is enforced across the application and marketing site.

Beyond the encryption at rest that our database provider applies to the whole disk, we separately encrypt values that are themselves credentials before they are written to the database. This covers integration API keys, OAuth access and refresh tokens, and webhook signing secrets that customers store with us.

• Algorithm: AES-256-GCM, an authenticated cipher, with a unique random initialisation vector per value and an authentication tag verified on decryption
• The key is a 32 byte secret held in the runtime environment, never in the database and never in the client bundle
• The design goal is specific: a database leak alone must not become a credential leak in your ATS or other connected systems

Stored credentials are masked when read back through the API, so a full secret is never returned to a browser or written to a log after it is saved.

Candidate personal data, transcripts and recordings rely on provider level encryption at rest rather than an additional application layer cipher. We are telling you that rather than implying field level encryption we do not have.

• Identity provider. Authentication is handled by Supabase Auth. Passwords are hashed by the provider and never stored by us in plain text or reachable by our application code.
• Two factor authentication. Any user can enrol a TOTP authenticator app from organisation settings. Enrolment produces a QR code and requires a verified code before the factor becomes active.
• Email verification and one time codes. Sign in and account recovery use verified email addresses and one time codes.
• Session timeout. Organisations can set a session timeout, applied to sessions at sign in. The default is 60 minutes.
• Candidate access. Candidates never create a password to take an interview. Interview and video sessions are reached through single purpose links whose tokens are validated server side and which expire, so a link cannot be reused or shared indefinitely.

Every customer facing record carries an organisation identifier, and every server side query is scoped to the organisation of the signed in user. Authorisation is checked in the API layer on each request rather than being trusted from the client. Deleting an organisation cascades to its jobs, candidates, applications, interviews and assessments.

Roles. Each member of an organisation holds one of four roles, and the role is checked on the server for the actions listed below. A viewer reads but changes nothing. A member also moves candidates through the pipeline. A recruiter also creates and edits jobs, runs interviews, and rejects candidates. An admin also reaches billing, team invitations, integration credentials, API keys, webhooks, organisation settings and job deletion. The person who created the organisation always keeps admin, which is what makes it impossible to demote the last administrator.

To be precise about the limits of this: role checks are applied to the state changing actions that matter, listed in the table in section 11. They are not yet applied to every read. A viewer or a member can still open the candidate records, transcripts and reports inside their own organisation. If someone should not see a candidate at all, do not invite them to the organisation. Per job and per candidate visibility scoping does not exist, and we will not describe roles as more than they are.

Endpoints that spend money or expose candidate media validate access credentials before doing anything, including the endpoint that mints AI voice session credentials.

• All service credentials are supplied as runtime environment variables, held in the hosting provider's encrypted environment store, and are not committed to the repository
• Only variables explicitly marked as public are exposed to the browser. Provider secret keys, the database URL, the encryption key and AI provider keys are server side only and never included in a client bundle
• Customer supplied credentials are encrypted before storage and masked in every API response
• Scheduled jobs and queue callbacks require a shared secret or a verified signature, so they cannot be triggered by an anonymous request

• Recordings are deleted after 15 days. A scheduled job runs every day and removes the stored audio and video file for any completed or cancelled interview older than 15 days, then clears the stored reference. This is automatic and does not depend on anyone remembering to do it.
• Transcripts and assessments are kept. They are the written record behind a screening decision, and they persist for as long as the customer keeps the candidate record.
• Account deletion. Deleting an organisation removes its associated records by database cascade.
• Individual requests. Deletion and access requests are handled by a person, not a self service portal. See the Privacy Policy for how to make one.

Interview audio, transcripts, resume text and anything the in-product AI assistant reads on your behalf are sent to AI providers so the platform can transcribe, assess and answer. We never train models on customer or candidate data, and our providers do not train on data submitted through their APIs.

On retention, the accurate answer rather than the comfortable one: our primary provider keeps API content for up to 30 days for abuse monitoring, then deletes it, unless a longer period is required by law. It is not used for training during that window. Zero retention is available from the provider on approval, and we will say so here when it is in place rather than implying it before.

The full list of providers, what each one receives and where it processes, is in the sub-processor table of our

We do not have a 24 hour security operations centre, and we will not pretend otherwise. What we commit to is this:

• Investigate every credible report of a security issue promptly, and prioritise it above feature work
• Contain and remediate a confirmed incident as quickly as we can, including revoking credentials and invalidating sessions where warranted
• Notify affected customers without undue delay, and within 72 hours of becoming aware of a personal data breach where the GDPR requires it, so that customers can meet their own notification duties as controllers
• Tell affected customers what happened, what data was involved, what we did about it and what we changed, rather than issuing a vague notice
• Cooperate with customers who need to notify their own regulators or candidates

Our providers give us audit logs, and the application records activity such as interview starts and integration syncs, which we use during an investigation.

If you have found a vulnerability, we want to hear about it. Email [email protected] with steps to reproduce, the affected URL or endpoint, and the impact you believe it has.

What we ask

• Give us a reasonable chance to fix the issue before disclosing it publicly
• Use only accounts and data you own, and stop as soon as you have confirmed a vulnerability
• Do not access, modify, download or delete other people's data, and do not run denial of service, spam or social engineering against our staff, users or providers
• Do not use automated scanners that generate heavy load against production

What we commit to

• Acknowledge your report within 2 business days
• Give you an assessment and a remediation plan within 10 business days
• Keep you updated until it is resolved, and credit you if you want to be credited
• Not pursue legal action against researchers who follow the guidance above in good faith

We do not currently run a paid bug bounty programme. If that changes, it will be announced here.

What we offer instead is specificity. Every control described on this page is implemented today, and the gaps are listed below rather than omitted. We are happy to complete a security questionnaire, walk a reviewer through the architecture, or sign a data processing agreement. Contact [email protected].

This section exists so that a reviewer does not have to guess. These are controls we have not finished, stated as gaps rather than features.

Security is shared. The controls above only work if the account is used carefully.

• Enable two factor authentication for every user in your organisation
• Give each person their own login and remove access promptly when someone leaves
• Treat interview links as sensitive, since they grant access to a specific interview session
• Do not paste candidate data into third party tools that your own policy has not approved
• Set a session timeout that matches how your team works