Security
- Last updated
- Effective
- Entity
Kairo Labs LLC ("Kairo") treats security as a feature, not a checklist. This page covers what we do today and what we are actively working on.
1. Encryption
- In transit: TLS 1.2 or higher for every connection to Kairo, with modern cipher suites only. HSTS is enabled on all production domains.
- At rest: AES-256 (XTS or GCM depending on layer) on the managed Supabase Postgres cluster and on Supabase Storage. Disk-level encryption is provided by the underlying cloud provider.
- Application-level encryption: connected-account OAuth tokens (Google, Microsoft, and other integrations) are encrypted with AES-256-GCM using a server-side key managed outside the database before being written.
- Key management: production keys live in a managed secrets store, rotated on a defined schedule and on personnel changes. Keys never appear in source control or logs.
2. Access controls
- Row-level security (RLS) on every user-facing database table; access policies are unit-tested.
- Engineers cannot read customer content by default. Any access for support or incident response requires explicit, time-bound, and audited approval.
- Single sign-on with multi-factor authentication (MFA) is required on every Kairo staff account that can reach production, including admin consoles for our cloud database, hosting, payments, transactional email, and AI providers.
- Least-privilege role assignments, reviewed at least quarterly.
- Production deploys are gated by code review and CI checks.
3. Infrastructure
- Hosted on managed infrastructure (Supabase + Vercel) in US regions.
- Daily backups with point-in-time recovery for the last 7 days on the production database.
- Audit logging on production database schema and policy changes.
- Network egress to AI providers traverses TLS connections only; provider accounts are configured for zero data retention (ZDR) where the provider supports it.
4. AI cost & abuse controls
Kairo's AI surfaces are protected by multi-layer rate-limiting and quota enforcement so a single compromised account or abusive script can't run up the bill or degrade service for other users.
- Server-side quota enforcement. Every AI request goes through an atomic check + increment against per-user monthly and hourly buckets. Quota is canonical on the server; client-side counters are display mirrors, not gates.
- Per-IP throttling. Pre-auth and post-auth, capture and related endpoints rate-limit by SHA-256-hashed source IP (raw IPs are never persisted) to stop scripted abuse before it reaches the user-tier gate.
- Anomaly detection.A daily cron compares each user's 24-hour AI consumption to their trailing 7-day baseline. Users burning more than 3× their normal rate trigger an internal alert within 24 hours of the spike.
- Content-hash response cache. Deterministic AI tasks (capture parsing) are cached by SHA-256 of input + timezone + reference date. Cache hits never reach an upstream model, lowering both cost and latency for repeat patterns.
- Burst auto-downshift. Pro users hitting the burst threshold are automatically routed to a smaller model for the remainder of the window. Service continues uninterrupted while protecting margins.
5. Audit trail
Team workspaces on the Pro tier carry a per-team audit log that records sensitive actions: role changes, member removals, invite-code rotations, mission and rules edits, and admin settings changes. Each entry stamps actor, timestamp, and a human summary. Audit entries surface in the team's admin panel and are retained server-side under the same encryption and access controls as the rest of customer data.
6. Account security available to you
- Password sign-in with a strong-password policy (minimum length, common-password blocklist, strength meter).
- Magic-link sign-in via Resend with single-use tokens.
- Optional OAuth via Google.
- Session cookies are HttpOnly, Secure, and SameSite-Lax.
- Sign-out from all sessions is available from Settings → Account.
7. Incident response
We maintain a documented incident-response runbook covering triage, containment, eradication, recovery, and post-incident review. If we confirm a security incident that compromises personal information, we will notify affected users and applicable regulators without undue delay and, where law requires, within 72 hours of confirmation. See the Privacy policy for the breach-notification commitment in full.
8. Compliance posture
Kairo is not pursuing SOC 2 certification at this time. Our internal control narrative is aligned with common Trust Services Criteria (security, availability, confidentiality) and we will publish a report under NDA if and when we obtain one. We comply with US privacy laws applicable to our operating footprint (CCPA/CPRA, VCDPA, CPA, CTDPA, UCPA) — see the Privacy policy.
9. Responsible disclosure
If you believe you have found a vulnerability in Kairo, please email security@heykairo.io. A PGP key is available on request. We commit to:
- acknowledging your report within one business day;
- providing a triage decision within five business days;
- working to remediate confirmed issues within a 90-day responsible-disclosure window, or sooner for high-severity findings;
- crediting researchers (with your permission) in our security acknowledgments.
We do not currently run a paid bug-bounty program. We will not pursue legal action against good-faith research that follows standard disclosure norms — no privacy violation of other users, no service disruption, no data exfiltration, and prompt private disclosure to us.
10. Contact
Security disclosures and questions: security@heykairo.io.