“Trust us” is not
an answer.

Klorn reads other people's email so you don't have to. That sentence is the threat model: the primary input is text written by strangers, some of whom are adversarial. Here is what the architecture actually guarantees, with the file that implements each one.

PropertyWhat is actually trueWhere to check
Email is hostile inputEvery email body, subject and third-party string is wrapped in <untrusted_content> markers before reaching a model, and pre-existing wrapper tags are stripped first so a crafted message cannot close the wrapper. Prompt injection is in scope, not an accepted limitationSECURITY.md
Token encryption at restAES-256-GCM before the token touches the database, with keyring rotation (v1/v2 envelopes) so a suspected leak is rotated without a flag day. A missing key outside dev/test aborts boot rather than falling backcrypto-tokens.ts
Outbound actionsSend, permanent delete and forward-external cannot ride on classifier confidence. Each requires a receipt minted at approval time pinning a sha256 of the canonical payload, re-verified at execution. If anything drifted in between, the action is refusedattention-floor.ts
Dev conveniencesDev JWT secret, dev encryption key, localhost CORS and the demo user sit behind a dev/test allowlist that fails closed for any other NODE_ENVenv.ts
AnalyticsFirst-party only. A short allowlist of coarse event names in Klorn's own Postgres. No external tracker, and never message contentanalytics.ts
Encryption in transitTLS-only on every hosted surface — API, web, Google APIs, model providersself-hosting.md

What Klorn can read

Exactly the scopes shown on your own Google consent screen, and nothing that is not listed there: gmail.readonly, gmail.modify, gmail.send, calendar.readonly, calendar.events, and your account email and profile. A calendar-only link grants read-only calendar access and no mailbox access at all.

How long anything is kept

Log retention is enforced by a scheduled sweep rather than a promise: agent actions, email processing, push delivery and webhook ledgers are deleted after 90 days, rate-limit rows after 30, and token accounting after 180 for cost-drift analysis. The windows are a table in the source, not a setting we can quietly widen without it showing in a diff.

Reporting a vulnerability

Email k0820086@gmail.com with a description and reproduction steps. Please do not open a public issue for an exploitable finding. You'll get an acknowledgment within a few days; fixes to the approval floor and the token-encryption paths take priority over everything else. Machine-readable contact details are at /.well-known/security.txt.

What we are not claiming. Klorn has not had a third-party penetration test or a SOC 2 audit, and this page does not imply one. It is a solo-maintained product in beta. The compensating control is that the code is AGPL-3.0 and the security-relevant paths are named above by file — you can read them instead of taking our word for it.

SECURITY.md carries the longer version, including the known gaps we chose to state rather than omit.

Try Klorn free