Security

Math, not policy.

Most workspace tools encrypt data "in transit" and "at rest" — and the vendor holds the keys. Koaich is different. We hold ciphertext. You hold keys. There is no "we promise not to look" in the trust model — there's nothing for us to look at.

IN PLAIN ENGLISH

When you store something with most workspace tools, the company keeps a copy of the key. They can read it whenever they want, and so can anyone who breaks in or shows them a court order. With Koaich, only your phone or laptop has the key. We store the data, but we can't open it — not for ourselves, not for a hacker who breaches us, not for anyone. The page below describes how we built this for engineers and security teams. The short version is the previous paragraph.

The plain-English version.

For everyone. The technical detail follows.

When you say 'we can't read your data,' what does that actually mean?+

Your messages, documents, and files are locked before they leave your device. Only you and the people you've granted access to hold the key. Our engineers, sitting at our servers with full admin access, see ciphertext where your content lives. They see the structural metadata the database needs to function — accounts, vault membership, vault labels you've assigned, timestamps — but never the content itself. There is no master key we could pull out; we deliberately designed against ever having one. AI features are handled differently — see §6.6 below.

What's end-to-end encryption without the jargon?+

Imagine writing a letter, sealing it in an envelope, and handing it to a courier. The courier delivers it. The courier never opens it. With most workspace tools the courier reads every envelope, sometimes makes copies, and stores those copies forever. We don't.

What if I lose my phone?+

Your data has a key — like a house key. We never hold a copy. But your other devices each hold a piece of a spare. As long as you have one other Koaich device, you can rebuild the spare and recover. If you lose every device at once and didn't save your recovery codes, your data is gone. We chose this trade-off deliberately: if we held a master spare, anyone who broke into our office could too.

Why don't you have password recovery?+

Every tool that lets you 'reset and get back in' is keeping a copy of your data somewhere they can decrypt — that's how recovery works. We chose not to have that copy. Trade-off: you have to take device backup seriously. Benefit: there's no master copy of your data on our servers waiting to be breached, requested, or copied.

If someone asks for my data, what can you give them?+

Only what's on our servers — metadata and ciphertext. We can't decrypt message bodies because we don't hold the keys. The math, not the policy, is what enforces this.

§ 1

Three encryption tiers

Koaich uses a three-tier key hierarchy. There is no master key that compromises everything.

L1 (device tier) · Every device has its own keypair. Generated on-device. The private key never leaves it.
L2 (vault tier) · Each vault has its own symmetric key, wrapped to each member's device public key. Adding a member generates a new wrapped copy.
L3 (per-object tier) · Each message and document gets its own key, or derives from the MLS epoch key for groups. Files have a per-file symmetric key, wrapped into the message envelope.

Leak one device's key, you compromise that one device. Leak one vault's key, you compromise one vault. There is no key that compromises Koaich.

§ 2

Group messaging via MLS

Groups use the Messaging Layer Security protocol — IETF RFC 9420.

· Every membership change rotates the group key forward.
· Past members can't decrypt future messages (forward secrecy).
· A compromised member can't silently read past messages without resyncing keys (post-compromise security).

When a contractor rolls off your team, this quarter's strategy thread isn't readable on their device. Past members can't decrypt content from epochs they weren't in — even if they retain row-level database access, all they see is ciphertext. See Forward secrecy in plain English and What's MLS for the deeper version.

§ 3

External recipients (people without Koaich)

Koaich isn't a walled garden. Send to someone who doesn't have the app — they get a sealed envelope addressed to their email.

1.You compose. Your client encrypts the body under your own ephemeral keypair.
2.The server stores the ciphertext plus recipient email — that's it.
3.A daily digest email goes out to the recipient with metadata only — sender handle, message count, expiry. No body.
4.They click "Open in Koaich." They sign up or enter a one-time code. The body is re-encrypted client-side under their real key.

Digest action links (block sender, decline group, unsubscribe) are HMAC-signed and one-shot. No clickjacking, no replay.

§ 4

Recovery without vendor-held keys

Mobile: Shamir's Secret Sharing across your own trusted devices. Lose one device — recover from the others. We don't hold a recovery copy.

Web: WebAuthn passkeys backed by your authenticator (Apple ID, 1Password, hardware key). The Koaich web app never sees the private key — the authenticator signs challenges directly. For the full web-tier threat model — SRI, strict CSP, Trusted Types, planned bundle transparency log — see /web-tier-security.

Precision note on key derivation. The passkey is the auth root — it gates access to the app. The encryption root is a separate recovery mnemonic generated at L3 identity enrollment; HKDF off that key derives every wrap key in the stack. Today the passkey gates access to a mnemonic-derived encryption key. A future revision (tracked PLANNED on /web-tier-security) routes key derivation through the WebAuthn PRF extension where supported, so the encryption key is derived directly from the passkey on every unlock — the mnemonic then becomes a backup material handled only at enrollment + Shamir recovery.

There is no password-recovery backdoor. If you lose all your shares, your data is gone. This is what makes "we can't read your data" honest — if we could recover for you, we could also be compelled to read.

§ 5

Server-side enforcement (without server-side reading)

Per-tier limits — messages per day, external recipients per day, attachment size — are enforced at the database trigger level, not just in the client. A modified mobile build can't bypass them. The server enforces policy without ever decrypting content.

§ 6

What we see vs. what we don't

What our servers can see

· Account existence, creation time, registered email.
· Sender, recipient (handle or email), timestamp, TTL, approximate size — not the content.
· That a document or file exists — owner, recipients, size, MIME type — not the content.
· Vault membership: who's in which vault, their role, when they joined or left.
· Authentication events: logins, IPs, user agents.
· Per-tier usage counters.
· Invite recipient email addresses on pending vault email invites — cleartext, required by our email delivery provider to actually deliver the email. Deleted from the row once the invite is consumed; the encrypted invite payload (vault name, inviter handle, message) is never readable to us.
· The fact that you've connected Calendar or Gmail. Your browser calls those Google APIs directly under your own OAuth grant; we allowlist the origins in our CSP so the integration works. We don't proxy, intercept, or store that data — we're not in the request path.

What our servers cannot see

· The content of any message, document, or file.
· Vault names + descriptions — encrypted client-side (per-vault DEK, wrapped per-member). Cleartext columns dropped from public.vaults on 2026-05-17; the server has no decrypt path.
· Vault invite payloads (vault name, inviter handle, message inside the invite email) — encrypted with a key the recipient extracts from the email URL fragment; the server stores ciphertext and never sees the fragment.
· Vault contact-approval data (the email + display name + handle being approved for vault contact) — encrypted under the same per-vault DEK; only existing vault members can decrypt.
· Contact list entries (display name, email, note) — encrypted via address_book.encrypted_payload, wrapped per-user.
· The encryption keys protecting all of the above.
· Passwords (we don't use them as the recovery primitive).
· The contents of any third-party API call you make (Calendar events, Gmail messages) — those flow browser↔Google directly under your OAuth grant.

If someone asks for your data: we can produce only what's on our servers — account-existence and authentication metadata. We cannot produce message bodies, document contents, or files. They're ciphertext under keys we don't hold. The math, not the policy, is what enforces this.

§ 6.5

The metadata roadmap

The boundary above is an honest snapshot of today. Below is the full inventory by data category — what the server can read today, what's structural metadata it needs to operate, and what's on the roadmap to encrypt further. We'll update this table as items ship.

CATEGORY	TODAY	DETAIL
Message content	ENCRYPTED	nacl.box for 1:1, MLS for groups. Server sees ciphertext only.
Document + file content	ENCRYPTED	Per-object symmetric key, wrapped to each recipient.
Encryption keys	ENCRYPTED	User-held. Server has no path to derive them.
Authentication credentials	STRUCTURAL	WebAuthn passkeys on web; no password-derived material reaches us.
Account identifiers (email at signup)	STRUCTURAL	Cleartext by design — required for invites and external delivery. Hashing-with-salt under review.
Vault labels (name, description)	ENCRYPTED	XSalsa20-Poly1305 ciphertext in vaults.name_ciphertext / name_nonce / description_ciphertext / description_nonce. Per-vault DEK lives in vault_member_label_dek, wrapped per-member under each member's L3 X25519 secret. Cleartext columns dropped from public.vaults on 2026-05-17; the server has no decrypt path. CHECK constraint vaults_ciphertext_required enforces ciphertext-required on every future row.
Vault membership (who's in which vault)	STRUCTURAL	Required cleartext for RLS-based access control. Cryptographic membership (auth-credential style) is a long-term option, not v1.
Contact list entries (name, email, note)	ENCRYPTED	Stored as ciphertext in address_book.encrypted_payload, wrapped per-user. Server holds an opaque blob; only the contact-list owner can decrypt.
Contact discovery (lookup by email)	STRUCTURAL	Lookups go through a salted keyed HMAC (email_hmac) — server never sees cleartext email at lookup time. Caveat: HMAC is deterministic, so the server can still tell two users share a contact. Full zero-knowledge discovery (PSI/OPRF) is a future workstream.
Vault invite emails (server-side template fields)	ENCRYPTED	vault_email_invites stores payload_ciphertext + payload_nonce; the cleartext vault_name, inviter_handle, inviter_display_name, invitee_message columns were dropped on 2026-05-17. CHECK constraint vei_payload_required enforces ciphertext-required. The wrapping key is delivered to the recipient via the email URL fragment (#k=…) — browsers don't transmit URL fragments, so the server never sees the key. Recipient email is intentionally cleartext (required by our email delivery provider; flagged in §6).
Vault contact-approval requests	ENCRYPTED	vault_contact_approvals stores contact_data_ciphertext + contact_data_nonce; the cleartext contact_email, contact_handle, contact_display_name, reviewer_note columns were dropped on 2026-05-17. CHECK constraint vca_contact_data_required enforces ciphertext-required. Encrypted under the per-vault DEK; only existing vault members (admins + the requester per RLS) can decrypt.
Address graph (who messages whom)	STRUCTURAL	Sender/recipient handles are visible. Sealed-sender is a long-term option once anti-abuse is reworked.
Per-tier usage counters	STRUCTURAL	Required for server-side abuse prevention.

AI inference traffic is handled separately and is not covered by the table above. See §6.6 On AI features for how AI-generated content is handled.

§ 6.6

On AI features

Koaich uses Anthropic's API for AI features (meeting prep, draft composition, summary generation). When you invoke one of these features, the relevant context plus your prompt are sent to Anthropic through our proxy. The proxy does not log or persist prompts or completions on our side, and every request must carry a per-session consent_metadata field naming the surface you opted into.

On Anthropic's side, data is governed by their standard API terms at anthropic.com/legal/commercial-terms. Per those terms, Anthropic does not use API customer data to train its models, and prompt + response data is retained for up to 30 days for trust-and-safety review before deletion. We are separately contracting Anthropic Zero Data Retention (ZDR) for Koaich workloads, which removes Anthropic-side retention entirely. PLANNED — flips to LIVE when the ZDR contract is countersigned.

We deliberately do not claim that AI prompts are end-to-end encrypted or that "our servers cannot see" them. The model has to read them. The cryptographic boundary documented in §6 covers messages, documents, files, vault labels, and contact data — not AI inference traffic. AI features are an optional, explicit-consent surface; when you use them, you are sending data to our LLM provider under the terms above.

§ 7

What we don't have (yet)

· No password recovery (intentional)
· No vendor-side content audit log (intentional — would compromise the core guarantee)
· No admin "compliance and audit" portal (roadmap)
· No BAAs out of the box for healthcare (roadmap)
· No SOC 2 / ISO 27001 / PCI certifications (roadmap — late 2026)
· Mobile passkey native integration (roadmap — web tier already passkey-only; mobile uses email + password until Apple Passkeys / Android Credential Manager ship in the next release)
· WebAuthn-PRF-derived encryption keys (roadmap — today the passkey gates access to a mnemonic-derived key; PRF would route key derivation through the passkey directly. See §4 Recovery precision note.)
· Encrypted IndexedDB at rest (roadmap — local browser storage currently cleartext; PRF-derived wrap layer is the next web-tier hardening item)
· Trusted Types CSP directive (roadmap — blocked by one same-origin innerHTML write in the rich-text editor; iframe-isolation refactor in flight)
· Reproducible builds + bundle transparency log (roadmap — Sigstore Rekor integration)

Want the architecture brief?

The half-pager that goes deeper than this page — cipher choices, key derivation, threat model — is available to security reviewers at prospective customers on request.

Join the waitlist