Kaito
A shared 2FA vault for teams — like Authy, but multiplayer: teammates store and release verification codes for shared accounts (GitHub, AWS, Stripe) with push-to-approve gating and a full audit trail.
- Multiplayer 2FA
- shared codes, per-release approval
- Hash-chained
- a tamper-evident audit log
- Bring your own key
- an org controls its own encryption
The problem
Teams constantly share logins for accounts that don't do proper team access — the company GitHub, the AWS root, the Stripe account. The two-factor codes for those get passed around over chat, or live on one person's phone. Kaito is a shared, audited vault for exactly those shared-account 2FA codes.
What it does
A team stores the 2FA secrets for its shared accounts in Kaito; the server generates the rolling six-digit codes on demand, so the underlying secret never sits in anyone's browser or gets copy-pasted around. Any token can be marked as needing approval — releasing its code then requires a higher-role teammate to approve a push notification with number-matching, and every release is logged.
Access is role-based across four tiers, every action writes to a tamper-evident audit log where each entry is chained to the one before it, and an organisation can bring its own encryption key so it controls the keys to its own data. New users get single-use recovery codes hashed at password strength, and a QR flow lets an already-signed-in phone approve a brand-new browser session end to end.
Key features
Shared 2FA codes, without sharing the secret
The server generates each rolling code on demand, so a team uses the code for a shared account without the underlying secret ever being copied around a chat.
Push-to-approve on sensitive tokens
A token can require a teammate to approve its release via a number-matching push, so the most sensitive shared codes aren't one careless click away from anyone.
A tamper-evident audit trail
Every release and decision is written to a hash-chained log, so who released which code, and who approved it, is a record that can't be quietly altered.
Role-based access across the team
Four roles — owner, admin, member, viewer — mean a large team can share accounts with the right people holding the right level of control, not all-or-nothing access.
Bring your own encryption key
An organisation can supply its own cloud encryption key to wrap its data, so a security-conscious team keeps ultimate control of the keys to its own vault.
Where it stands
The web app is live (private beta) and the companion mobile app is complete and ready to submit to the app stores. Wearable/widget support that appears in some older descriptions was written on an abandoned branch and never shipped.
Under the hood — for the technically-minded
How it's built
Kaito is a React Router 7 app over Postgres, with the whole vault built so the raw TOTP secret is generated server-side and never exposed to the browser. Its own login is protected by four separate second factors — authenticator app, email code, SMS code, and passkeys — kept distinct from the vault's own push-approve gate, so signing in and releasing a shared code are separately protected.
The push-to-approve flow resolves the right approver from the role hierarchy, uses number-matching in a short time window, and logs the decision. The audit log is hash-chained so each row commits to the previous one, and a companion mobile app (built with Expo) carries the approvals experience.
The hard problems
Sharing a secret without spreading it
The whole point is letting a team use a shared account's 2FA without the secret leaking. Generating codes server-side and never returning the raw secret to the client is what makes that possible — the team gets the code, not the key material.
A gate on release, not just on login
Protecting sign-in isn't enough when the sensitive action is releasing a code. Kaito adds a separate approval gate on release itself — a higher-role teammate approves a number-matching push in a five-minute window — so the most sensitive tokens need a second person, every time.
An audit log you can trust
For a credential vault, the audit trail has to be trustworthy, so each entry's hash chains to the previous entry's — making silent tampering detectable rather than relying on the log simply not being edited.
Built with
- React Router 7
- Drizzle
- Postgres
- WebAuthn
- Expo
Building something in this space?
Work with us →