Security at Kaito.
The depth is in the whitepaper, the proof is in the audit log, the source is in the code. This page is the public-facing surface.
TL;DR
- Encryption: AES-256-GCM at rest, TLS 1.2+ in transit. Master keys held outside the database.
- Authentication: argon2id passwords, four MFA methods, mandatory MFA enforceable per-org.
- Access: RBAC + group permissions, scoped API keys, IP allow-listing.
- Audit: Every action logged, hash-chained for tamper-evidence, exportable.
- Compliance: SOC 2 Type I planned for 2026, Type II to follow. GDPR-ready. EU data residency on the roadmap.
What we defend against — and what we don't.
- Database breach — seeds AES-256-GCM, per-org DEK wrapped by KMS, master key not in DB
- Backup leakage — SSE-KMS on every object; org DEK shredding makes prior backups unreadable per-org
- Stolen session — MFA, short session lifetime, server-side revocation
- Compromised browser — seed never reaches client (server-side TOTP)
- Malicious insider — hash-chained tamper-evident audit log, group scoping, BYOK on Enterprise
- Lost / stolen device — sessions and mobile tokens server-revocable
- Provider compromise — SMS providers separated by region; no shared keys
- Disk loss / hardware reuse — LUKS2 on top of provider-managed storage encryption
- A compromised end-user device with active session and root access
- A compromised org owner who turns off MFA enforcement and adds attackers
Envelope encryption with three layers of keys.
Application-layer envelope encryption. Each TOTP seed is encrypted with a per-seed data key, which is itself encrypted with the org master key, which is itself encrypted with the platform master key held in env or KMS.
Why three layers: key rotation. Rotating the platform key only re-wraps a few hundred org keys. Rotating an org key only re-wraps a few thousand data keys. The seeds themselves don't move.
Cipher: AES-256-GCM. 96-bit IVs from crypto.randomBytes. Auth tag verified on decrypt.
At rest in the DB: the encrypted seed blob, the encrypted data key, the IV, the auth tag, and a key version. The master key is never in the database.
Defense in depth.
argon2id, 65MB memory cost, 3 iterations. Minimum length 12. Checked against the HIBP password list on signup and change.
TOTP (yes, you can use Kaito to manage Kaito's TOTP — recursive but real), Email OTP, SMS OTP, WebAuthn / passkeys.
HTTP-only, Secure, SameSite=Lax cookies. 12h idle timeout, 7-day absolute timeout, configurable down to 1h.
Prefix-tagged (kto_live_…), scoped, expiry-bound, IP-restrictable. Hashed in the DB; raw key shown once at creation.
Behind the scenes.
Point-in-time recovery for 30 days, encrypted at rest with a separate key. Cryptographically shredded on org delete.
Kaito employees do not have access to your seed plaintexts. The decryption path requires runtime keys not held by humans.
Mandatory hardware-key MFA for all employees. No SMS, no app codes for staff.
Time-bound break-glass via PAM, every action audited, post-incident review for any production read.
Snyk + Dependabot + monthly manual review. Critical CVEs patched within 7 days.
Annual third-party. Latest report available under NDA.
Found a bug? Tell us.
Email security@kaito.io. We acknowledge within 24 business hours.
Critical issues remediated within 7 days. Hall of Fame for valid reports. Public bug bounty live at HackerOne (range $200–$10,000 depending on severity).
Want the deep dive?
Download the security whitepaper or talk to our team.