Security

Assay runs hiring assessments, which means it holds candidate personal data and work product on behalf of the companies that use it. This page describes how that data is protected, at the level of what we guarantee rather than how it is built.

Note

This page is deliberately short on architectural detail. Publishing the internal shape of a system is an attack surface, so it states properties. We answer specific implementation questions under NDA during a security review.

Tenant isolation

Every customer’s data is isolated at the database layer, not in application code.

Every table in the production database enforces row-level security, and enforcement is forced rather than merely enabled. The distinction matters: in Postgres, a table’s owning role bypasses row-level security by default. Forcing it removes that exemption, so the rule applies to every connection without exception, including our own application’s.

The practical consequence is that a query which fails to scope itself to one tenant returns nothing rather than returning another customer’s rows. Isolation does not depend on every developer remembering to add a filter.

Isolation is verified by an automated test suite that runs against a real database and attempts cross-tenant reads directly, rather than by inspection of the policies.

Authentication

Authentication is handled by Firebase. Kravos never receives, stores, or is able to read a user’s password. Sessions are established against a verified identity token, and every database interaction is bound to the identity of the caller for the lifetime of that transaction.

Staff access is scoped to the organisation the user is a member of, with a role attached to that membership.

Candidate voice data

• Audio is streamed for transcription and is not stored. Candidate speech is relayed for real-time processing and is never written to disk or retained by Kravos in any form. The written transcript is what persists.
• Our speech provider is opted out of model training on this audio. This is enforced in configuration on every session, not selected per customer.

Code execution

Candidate code runs in an isolated, ephemeral sandbox provisioned per session and destroyed at the end of it. Candidate-submitted code never executes on Kravos infrastructure or inside our application processes.

Data in transit

All traffic is served over TLS, with strict transport security enforced.

Where we are honest about gaps

A security page that lists only strengths is not useful to a reviewer

These are current limitations, and we would rather you learn them here than find them later.

• No retention period is currently enforced. Assessment data is kept until deleted on request. Automated retention is planned and is not yet implemented.
• Deletion requests are actioned manually by our team. There is no self-service control.
• No formal certification. Assay is not SOC 2 or ISO 27001 certified. The controls described above are real and testable, and they are not third-party audited.
• No independent penetration test has been commissioned to date.

Reporting a vulnerability

If you believe you have found a security issue, email info@kravos.tech. Tell us what you found and how to reproduce it. We will acknowledge and keep you updated, and we will not pursue action against good-faith research that avoids privacy violations, data destruction, and service degradation.

Security review

For a procurement or vendor security review, contact info@kravos.tech. We can discuss architecture, data flow and controls in detail under NDA.