Ce que nous savons. Ce que nous ignorons. Ce qui n'est pas protégé.

Les serveurs de Korai ne conservent pas le texte de vos messages. Votre historique reste dans votre navigateur, sauf si vous activez la synchronisation, chiffrée avec une clé que seuls vos appareils détiennent.

Les messages sont chiffrés en transit (TLS) à chaque étape, mais pas de bout en bout : le serveur de Korai et l'ordinateur qui fait tourner le modèle les lisent en clair pendant la réponse.

Le chat web est anonyme par défaut. Il paie avec des jetons aveugles (Privacy Pass) : un jeton ne dit pas à Korai qui vous êtes ni quand vous l'avez obtenu.

Anonyme ne veut pas dire intraçable : notre hébergeur web voit votre adresse IP, et les conversations d'un même navigateur portent le même identifiant aléatoire.

Navigateur vers Vercel : HTTPS. Vercel termine TLS et exécute le code de Korai : il voit votre adresse IP et le message. Ce code envoie à l'orchestrateur le corps du message et les jetons, pas votre adresse IP ni vos cookies.

Vercel vers l'orchestrateur : HTTPS vers Fly.io (Paris). Le proxy de Fly termine TLS, puis passe la requête à l'orchestrateur dans son réseau.

Orchestrateur vers l'hôte : un WebSocket sur TLS que le worker ouvre vers l'orchestrateur. Hôte vers le moteur du modèle : HTTP local, sur la machine de l'hôte.

Rien sur ce chemin ne chiffre le message au-delà de TLS.

Vercel, pendant le transit et dans la mémoire de sa fonction.

Le proxy de Fly.io, qui termine TLS.

L'orchestrateur. Il lit la conversation pour la router, estimer son coût, filtrer les requêtes anonymes et lancer la recherche web.

L'hôte. Le worker et le moteur traitent le texte complet, et l'opérateur de la machine peut le lire. Le worker verrouille une copie de chaque requête en RAM pour qu'elle ne soit pas écrite sur disque ; c'est au mieux (Go fait d'autres copies) et cela n'arrête pas l'opérateur.

Les autres utilisateurs ne reçoivent pas vos messages, sauf s'ils sont hôtes : un compte ne reçoit des requêtes que si un administrateur Korai l'a approuvé comme hôte. Les comptes qui possédaient déjà un jeton de worker lors de la mise en place de cette règle ont été approuvés d'office.

Le texte des messages et des réponses : nulle part. Aucune colonne de base de données, aucune ligne de log. Les logs portent des identifiants de requête, de modèle et d'hôte, et un nombre de messages.

Empreintes SHA-256 de chaque prompt et réponse (journal d'audit, activé en production), avec identifiant de requête, modèle, identifiant d'hôte et heure : dans la mémoire de l'orchestrateur, les 4 096 dernières, jusqu'au redémarrage. Elles ne sont pas salées : qui aurait accès à cette mémoire pourrait confirmer un prompt deviné. Aucune API ne les renvoie.

Empreintes courtes des prompts anonymes récents, par identifiant de session anonyme (anti-répétition) : en mémoire, jusqu'au redémarrage au plus.

Une ligne par réponse terminée : hôte, modèle, nombre de tokens, gain de l'hôte, heure. Aucun compte ni session du demandeur. Sans expiration.

Par clé API, par jour et par modèle : nombre de requêtes, tokens, coût. Sans expiration.

Réclamations de jetons anonymes : SHA-256 d'un identifiant aléatoire du navigateur, créneau de 4 heures, nombre de jetons émis, date de la dernière réclamation, plus une ligne par réclamation (heure, nombre). Sans expiration.

Jetons dépensés : les identifiants de jetons VOPRF sont en mémoire de l'orchestrateur pendant 24 heures ou jusqu'au redémarrage. Pour les jetons HMAC (repli seulement), l'empreinte, l'identifiant de lot, l'identifiant de session anonyme et l'heure sont gardés 7 jours après l'expiration du lot.

Compte : e-mail, empreinte du mot de passe, sessions de connexion, empreintes des clés API. Pas de suppression automatique.

Historique synchronisé et documents Spaces : stockés chiffrés, jusqu'à ce que vous les supprimiez.

Annonce d'un worker à la connexion (matériel, pays, ville, coordonnées, adresse IP publique) : les versions de l'orchestrateur antérieures au build du 17 octobre 2026 l'écrivent en base de données (tables workers et worker_sessions) à chaque connexion, sans expiration. Le build du 17 octobre n'en écrit plus rien en base ; il garde en mémoire le matériel utile au routage et le pays, sans adresse IP, ville ni coordonnées. Les lignes déjà écrites ne sont pas supprimées automatiquement : elles restent tant que le nettoyage manuel prévu n'a pas été lancé.

Rapports d'erreur : Sentry reçoit la route, la méthode et la trace de pile, jamais de données de requête. Logs d'application : chez Fly.io, pour la durée qu'il fixe.

Votre navigateur aveugle des valeurs aléatoires avant que l'orchestrateur les signe, puis les désaveugle (VOPRF, P-384, RFC 9576 à 9578). Au moment du chat, il présente les jetons. L'orchestrateur peut vérifier qu'un jeton est authentique mais ne peut pas le relier à la réclamation qui l'a produit. Une requête de chat anonyme ne porte aucun identifiant de compte et n'est jamais facturée à un compte.

Ce que le mode anonyme ne cache pas :

Le contenu : l'orchestrateur et l'hôte lisent la conversation.

Votre adresse IP : Vercel la voit à chaque appel.

Les liens entre vos conversations : le navigateur envoie le même identifiant de session aléatoire avec chaque chat anonyme, et réclame ses jetons avec un autre identifiant persistant.

Le timing : quand le portefeuille est vide, le navigateur réclame des jetons juste avant d'envoyer le chat. Sur un petit service, deux requêtes peuvent être rapprochées par l'heure.

La clé publique : le navigateur la récupère à chaque fois, sans l'épingler. Un serveur malhonnête pourrait donner une clé différente à chaque navigateur et reconnaître ses jetons.

Les replis : si la voie VOPRF échoue, le navigateur retombe sur d'anciens jetons HMAC, qui portent un identifiant de lot que le serveur peut relier. Quand un utilisateur connecté n'a plus de jetons gratuits, le tour est envoyé avec son compte, après un avertissement, et n'est pas anonyme.

La facturation et les tables anonymes sont dans une seule base Postgres. La séparation est dans le code : aucune clé étrangère ni requête SQL ne relie les deux côtés (token_batches, redeemed_tokens, anon_free_tranches d'un côté, les tables de compte et de facturation de l'autre), et des tests automatisés échouent si cela change. Les abonnements anonymes payants ne sont pas en vente aujourd'hui.

Quand une requête est identifiée, l'orchestrateur connaît le compte. Les lignes de log du chat ne l'enregistrent pas.

L'hôte ne reçoit jamais votre identifiant de compte ni votre adresse IP. Il reçoit la conversation, les réglages du modèle et, pour les requêtes identifiées, deux clés opaques de courte durée qui lui permettent de distinguer les requêtes d'un même compte pendant au plus une heure sur un modèle. Les requêtes anonymes n'en portent aucune.

La recherche web est activée par défaut dans le chat connecté, et désactivée par défaut pour les clés API.

Désactivée par défaut. L'historique vit dans le stockage local de votre navigateur, non chiffré.

Activée, le navigateur crée une clé aléatoire de 256 bits, gardée dans IndexedDB. Les conversations sont chiffrées en AES-256-GCM avant l'envoi. Le serveur stocke du chiffré sous une adresse dérivée de la clé et ne reçoit jamais la clé. Les autres appareils la reçoivent par phrase mnémonique ou QR code.

Limite : c'est Korai qui sert l'application web. Si le code servi était modifié, il pourrait lire la clé.

Python s'exécute dans votre navigateur, dans un Web Worker dont l'accès au réseau est bloqué.

Les outils MCP appellent les serveurs que vous configurez, directement depuis votre navigateur.

La recherche web : les requêtes que le modèle rédige vont au serveur SearXNG de Korai sur Fly.io, qui interroge Bing News, Stack Overflow, Wikipédia et Wikidata. Les pages que le modèle ouvre sont récupérées par l'orchestrateur, depuis des adresses publiques seulement.

Kosmos (Spaces) : les documents sont chiffrés dans votre navigateur avant d'être stockés, avec une clé que vous seul détenez, et leur indexation se fait sur votre appareil, sans envoi de texte. Le serveur voit les tailles, les dates, un identifiant d'espace qui sert de clé d'accès et, à chaque recherche, quels passages se ressemblent. Quand un espace est utilisé dans une conversation, les passages les plus pertinents sont envoyés en clair à l'orchestrateur de Korai et à l'ordinateur qui exécute le modèle.

Le réseau est jeune : un seul ordinateur a servi la production le 16 octobre 2026.

Un compte ne reçoit des requêtes que s'il est approuvé comme hôte par un administrateur Korai. L'approbation décide qui reçoit des requêtes ; un hôte approuvé les lit quand même.

Aucun hôte ne tourne dans une enclave matérielle (TEE) et rien n'en atteste. La grille de prix liste un palier « korai-reef » décrit comme protégé par TEE ; aucun code n'y envoie de requêtes.

Les hôtes ne sont pas encore payés : l'orchestrateur calcule leurs gains, mais aucun code ne les verse.

Ces mots ont été employés pour décrire Korai. Ils ne sont pas vrais aujourd'hui :

Le chiffrement de bout en bout des messages.

L'informatique confidentielle, le TEE, l'attestation matérielle.

La chaîne de relais (cmd/relay, quatre applications Fly). Le client web ne l'utilise que si un réglage est posé à la main, et aucune interface ne le pose. Chaque relais termine TLS et lit la requête. Le mixnet Nym a été retiré.

« Deux bases de données séparées » : il n'y en a qu'une, séparée dans le code.

Des preuves de transparence : le journal d'audit signe avec une clé tirée à chaque démarrage, ne garde rien d'un redémarrage à l'autre et ne rend de preuve à personne.

Un audit de sécurité indépendant : aucun à ce jour.

Un code publié à vérifier soi-même : le code de l'orchestrateur n'est pas publié.

Si une autorité judiciaire européenne nous adresse une réquisition régulière, nous pouvons fournir les données de compte (e-mail, dates, sessions de connexion), les compteurs d'usage par clé API et les lignes d'usage listées plus haut. Nous ne conservons pas le texte des conversations : nous n'en avons donc pas d'historique à remettre. Ce texte reste lisible en clair pendant la réponse, comme décrit plus haut.

• Politique de confidentialité : /legal/privacy
• Mentions légales : /legal/mentions
• Contact transparence : transparency@korai.one