Security and trust

Controls you can inspect, not badges.

This page lists the safeguards currently implemented in Kairo and separates them from certifications we do not hold. It is intended for an operator's technical, privacy and procurement review.

Last reviewed
26 August 2026
Security contact
admin@kairoengine.com

Control register

Current implementation status. “Implemented” does not imply an external certification.

ControlStatusCurrent scope
Data regionImplemented

Core tenant data is stored in Supabase Postgres and object storage hosted in Frankfurt, EU.

Tenant isolationImplemented

Postgres row-level security policies scope tenant data at the database layer using tenant identifiers.

Encryption in transitImplemented

Connections to Kairo use TLS 1.2 or later.

Encryption at restImplemented

Supabase Postgres and object storage encrypt stored data with AES-256.

Connected-account credentialsPartial

Kairo wraps TrueLayer banking tokens and the Dext API key in a second layer of AES-256-GCM encryption before storing them. Gmail and Xero tokens do not carry that second layer and rely on the database encryption above. One Kairo-held key does the wrapping, so the keys are not split per tenant.

Multi-factor authenticationNot implemented

Kairo does not offer MFA on operator accounts today. Sign-in is email and password on Supabase-managed sessions.

Audit loggingPartial

Kairo stamps each change to a booking record with the person who made it and the time, and shows that history on the job. Kairo does not keep a separate audit log of sign-ins, role changes or settings changes.

BackupsImplemented

Supabase takes daily automated backups of the database. Kairo does not run point-in-time recovery, so the earliest state Kairo can restore is the most recent daily backup.

Workspace accessImplemented

Workspaces use Kairo's controlled signup flow. Passwords require at least 12 characters across 3 character classes.

Card handlingImplemented

Stripe handles subscription and passenger card details. Kairo does not store raw card numbers.

External certificationNot claimed

Kairo does not currently claim SOC 2 or ISO 27001 certification.

Where a booking record goes

Core storage remains in the EU. A selected processor receives data only for the service it provides.

Every party sees the same live record, and only the parts they are permitted to see.

  1. 1
    Permitted user

    An operator, driver, client or passenger accesses the view allowed for their role.

  2. 2
    Kairo application

    Authentication and tenant context are checked before application requests reach stored data.

  3. 3
    EU core database

    Postgres row-level policies scope the request to the correct tenant and record.

  4. 4
    Selected processor

    Stripe, email, accounting or opted-in services receive only the data needed for that action.

Data rights and handling

Kairo is multi-tenant, which means many chauffeur operators share the same application on the same infrastructure. Tenant checks exist in two separate places. The Kairo application checks which operator a signed-in user belongs to before it runs a query. Postgres also enforces row-level security policies on the tables themselves, scoped by tenant identifier. Separation does not rely on a screen simply choosing not to show another operator's data. Even a request that bypassed the application layer would still be blocked by the database.

An operator can export everything Kairo holds about one data subject from Settings, under Account & data, and hand the resulting file to the individual who asked for it. Kairo runs erasure itself when an operator asks, rather than putting an irreversible button in the product. What Kairo may delete is limited by the legal, accounting and fraud-prevention obligations set out in the privacy policy and the data processing agreement.

Third-party processors are limited to hosting, payments, transactional communication and services an operator chooses to connect. The current list and processing regions are kept on the sub-processors page.

Hosting, payments and driver location

What each part of the system actually does with operator and passenger data.

Where data is hosted

Core tenant data sits in Supabase Postgres and object storage in the EU. Supabase publishes its own security programme at supabase.com/security (opens in a new tab). The full sub-processor list, including any service outside the EU, is kept on the sub-processors page.

How payments are handled

Stripe holds card details for subscription and passenger payments. Kairo never stores raw card numbers on its own servers. Stripe describes its controls at stripe.com/docs/security (opens in a new tab).

How driver location is collected

Kairo only collects a driver's GPS position while that driver is on an active job. Location is not tracked outside working hours or between jobs. The privacy policy sets out this and every other category of data collected.

Backups and access

Supabase takes daily automated backups of the database. Kairo does not run point-in-time recovery, so the earliest state Kairo can restore is the most recent daily backup. Kairo does not copy production data onto developer workstations, and it stamps each change to a booking record with the person who made it and the time.

Documents for review

Use the underlying terms and registers rather than treating this summary as a contract.

Report a concern or ask for detail.

If you believe you have found a vulnerability, email admin@kairoengine.com with steps to reproduce it. Send suspected vulnerabilities or due-diligence questions directly to Kairo. Do not include live customer data or credentials in the first email.

admin@kairoengine.com