« Faites-nous confiance » n’est pas une réponse.
Klorn lit les e-mails écrits par d’autres pour que vous n’ayez pas à le faire. Cette phrase est le modèle de menace : l’entrée principale est du texte écrit par des inconnus, dont certains sont malveillants. Voici ce que l’architecture garantit réellement, avec le fichier qui met en œuvre chaque point.
Cette traduction est fournie pour votre commodité ; la version anglaise fait foi. Lire la version anglaise
Vérification Google et évaluation indépendante
Google a terminé son examen de vérification OAuth pour Klorn le 2026-10-03. Auparavant, Klorn avait été évalué de façon indépendante selon CASA Tier 2 par TAC Security ; résultat : In Compliance (conforme). La lettre de validation (Letter of Validation) issue de cette évaluation a ensuite été transmise à Google.
- Évaluation
- CASA Tier 2, tests dynamiques de sécurité applicative (DAST), par TAC Security
- Résultat
- In Compliance (conforme), au niveau d’assurance AL1 (OWASP ASVS niveau 1)
- Dates
- Évalué le 2026-08-12 · rapport émis le 2026-08-30 · examen Google terminé le 2026-10-03
- Réévaluation
- Annuelle. La prochaine évaluation est prévue en août 2027
Les cinq scopes Google, et la raison de chacun
Ces cinq scopes sont ceux que Google a approuvés lors de cet examen, et les seuls scopes de messagerie et d’agenda que Klorn demande. Klorn ne demande pas le scope d’accès complet à Gmail et, pour Google Agenda, il demande uniquement calendar.events et calendar.readonly — jamais le scope complet de l’agenda.
gmail.readonly- Lire vos messages pour que Klorn puisse les trier, afficher le motif de chaque décision et résumer un fil quand vous le demandez.
gmail.modify- Modifier l’état d’un message quand vous agissez dans Klorn : archiver ou désarchiver, placer dans la corbeille ou l’en sortir, ajouter une étoile, marquer comme lu ou non lu, et enregistrer un brouillon de réponse dans Gmail.
gmail.send- Envoyer un e-mail uniquement quand vous l’approuvez — une réponse que vous confirmez, une désinscription par mailto que vous demandez — ou une réponse automatique selon des règles que vous avez définies vous-même.
calendar.readonly- Lire vos disponibilités sur tous vos agendas, afin que les e-mails de réunion soient vérifiés par rapport à votre emploi du temps réel et que les conflits soient détectés.
calendar.events- Créer, modifier ou supprimer un événement dans votre agenda principal quand vous le demandez à Klorn — pas les paramètres ni le partage de l’agenda.
Se connecter avec Google ne demande que votre nom et votre adresse e-mail. Les scopes de messagerie et d’agenda viennent plus tard, dans un second écran de consentement, quand vous connectez une boîte de réception — et une connexion limitée à l’agenda demande calendar.readonly sans aucun scope de messagerie. (openid et userinfo.email/userinfo.profile figurent aussi dans ce fichier — ils identifient le compte connecté, ne sont pas sensibles et ne font pas partie de ce que Google a examiné.)
Où vont les données
Les jetons OAuth sont chiffrés en AES-256-GCM avant d’être stockés, chaque surface hébergée fonctionne uniquement en TLS, et les statistiques d’usage n’incluent jamais le contenu des messages — le tableau ci-dessous indique le fichier derrière chaque point. Les journaux expirent selon le calendrier fixe décrit dans Combien de temps les données sont conservées. Si vous préférez que vos e-mails ne passent pas du tout par nos serveurs, auto-hébergez le même code avec votre propre clé de modèle ou un modèle local. La politique de confidentialité se trouve sur /privacy.
Ce que cela signifie, et ce que cela ne signifie pas. L’examen et l’évaluation vérifient la manière dont Klorn traite les données Google qu’il demande. Ils ne constituent pas une recommandation de Klorn par Google et ne couvrent rien au-delà de ces scopes. Aujourd’hui, vous pouvez connecter Gmail, Google Agenda, Naver Mail (bêta) et iCloud Mail (bêta) ; les autres fournisseurs ne sont pas encore disponibles.
Ce que l’architecture garantit
| Propriété | Ce qui est réellement vrai | Où vérifier |
|---|---|---|
| Les e-mails sont une entrée hostile | Chaque corps d’e-mail, objet et chaîne provenant d’un tiers est encadré par des balises <untrusted_content> avant d’atteindre un modèle, et les balises d’encadrement déjà présentes sont d’abord retirées pour qu’un message forgé ne puisse pas refermer l’encadrement. L’injection de prompt fait partie du périmètre ; ce n’est pas une limite acceptée | SECURITY.md |
| Chiffrement des jetons au repos | AES-256-GCM avant que le jeton ne touche la base de données, avec rotation du trousseau de clés (enveloppes v1/v2) pour qu’une fuite suspectée soit traitée par rotation, sans bascule brutale. Une clé manquante hors dev/test interrompt le démarrage au lieu de basculer sur une solution de repli | crypto-tokens.ts |
| Actions sortantes | L’envoi, la suppression définitive et le transfert vers l’extérieur ne peuvent pas reposer sur la confiance du classifieur. Chacun exige un reçu émis au moment de l’approbation, qui épingle un sha256 de la charge utile canonique, revérifié à l’exécution. Si quoi que ce soit a changé entre-temps, l’action est refusée | attention-floor.ts |
| Commodités de développement | Le secret JWT de dev, la clé de chiffrement de dev, le CORS localhost et l’utilisateur de démo sont derrière une liste d’autorisation dev/test qui échoue en position fermée pour tout autre NODE_ENV | env.ts |
| Statistiques d’usage | Uniquement internes (first-party). Une courte liste autorisée de noms d’événements génériques, dans la propre base Postgres de Klorn. Aucun traceur externe, et jamais le contenu des messages | analytics.ts |
| Chiffrement en transit | Uniquement TLS sur chaque surface hébergée — API, web, API Google, fournisseurs de modèles | self-hosting.md |
Combien de temps les données sont conservées
La conservation des journaux est appliquée par une purge planifiée plutôt que par une promesse : les actions de l’agent, le traitement des e-mails, l’envoi des notifications push et les registres de webhooks sont supprimés après 90 jours, les lignes de limitation de débit après 30, et la comptabilité des tokens après 180 pour l’analyse des dérives de coût. Ces durées sont un tableau dans le code source, pas un réglage que nous pourrions élargir discrètement sans que cela apparaisse dans un diff.
Signaler une vulnérabilité
Écrivez à k0820086@gmail.com avec une description et les étapes de reproduction. Merci de ne pas ouvrir d’issue publique pour une faille exploitable. Vous recevrez un accusé de réception sous quelques jours ; les correctifs du plancher d’approbation et des chemins de chiffrement des jetons passent avant tout le reste. Les coordonnées lisibles par machine se trouvent sur /.well-known/security.txt.
Ce que nous n’affirmons pas. En dehors de l’évaluation CASA Tier 2 ci-dessus, Klorn n’a fait l’objet d’aucun test d’intrusion par un tiers ni d’aucun audit SOC 2, et cette page n’en sous-entend aucun. C’est un produit en bêta maintenu par une seule personne. La mesure compensatoire : le code est sous AGPL-3.0 et les chemins liés à la sécurité sont nommés ci-dessus, fichier par fichier — vous pouvez les lire au lieu de nous croire sur parole.
SECURITY.md en donne la version longue, y compris les lacunes connues que nous avons choisi d’exposer plutôt que de taire.