Sécurité

Une base de données par client

Votre mémoire n’est pas une ligne dans une table partagée avec une colonne client. Chaque client dispose de la sienne. base de données propre. Il n’y a pas de tables partagées et aucune requête inter-clients à risquer de mal formuler, car la limite est la base de données elle-même et non un filtre dont quelqu’un doit se souvenir de l’écrire.

Cette limite est testée de l’extérieur à chaque publication : deux comptes réels, et chaque porte qui renvoie des données est vérifiée pour s’assurer que l’un ne peut pas voir l’autre. Une publication n’est pas envoyée tant que ce test n’est pas réussi.

Clés, et qui peut les utiliser

Nous ne pouvons pas vous montrer votre propre clé.

Les clés API ne vous sont affichées qu’une seule fois, à la création. Ce que nous stockons est un hash SHA-256 — une copie de notre base de données ne permet donc à personne d’obtenir une clé fonctionnelle, et ni nous ni un attaquant ne pouvons relire la vôtre. La révocation d’une clé prend effet sur le service en environ une minute, et immédiatement sur la machine qui sert votre mémoire.

Les clés peuvent être affinées

Une clé n’a pas à être toute-puissante. Les clés peuvent être Défini par projet — lecture/écriture, lecture seule, ou totalement invisible

Authentification à deux facteurs

Votre compte peut exiger un second facteur à la connexion, et lorsque vous l'activez, il est appliqué à chaque connexion — après le mot de passe et après GitHub ou Google également — et n'est pas simplement affiché comme un paramètre.

La création d'une clé API nécessite une connexion protégée : l'authentification à deux facteurs sur votre compte, ou une connexion via GitHub ou Google. Un mot de passe seul ne crée jamais de clé — pas même sur un compte qui a aussi GitHub ou Google connecté, car ce qui compte, c'est la manière dont vous vous êtes connecté cette fois-ci.

Chaque action destructive — suppression d'un projet, rédaction de l'historique, suppression du compte, restauration d'une sauvegarde — vous redemande qui vous êtes : votre mot de passe si vous en avez un, et votre code à deux facteurs ; sans double authentification, une connexion GitHub ou Google des dix dernières minutes. L'exportation de vos données n'en a jamais besoin.

Se connecter avec GitHub ou Google

La connexion via GitHub ou Google utilise le flux d'autorisation standard avec PKCE, lié au navigateur qui l'a lancé. Nous recevons votre adresse e-mail, votre nom et votre identifiant de compte auprès de ce service — rien d'autre. Nous ne conservons aucun jeton d'accès GitHub ou Google, et nous ne pouvons pas lire vos dépôts, vos e-mails ou vos fichiers. Un compte GitHub ou Google n'est associé à un compte Brethof existant que lorsque ce service a vérifié l'adresse e-mail et que nous l'avons également fait, ou lorsque le compte n'a pas encore de mot de passe.

Protection contre vos propres agents

C’est la partie à laquelle la plupart des services ne pensent pas. Votre mémoire est constamment manipulée par des agents d’IA — et un agent peut commettre une erreur, recevoir des instructions malveillantes cachées dans le contenu qu’on lui demande de lire, ou supprimer la mauvaise information des heures avant que quelqu’un ne s’en aperçoive.

Ainsi, l’archive brute des conversations reste délibérément hors de leur portée. Aucun agent ne peut supprimer un seul message. Aucun agent ne peut toucher aux trois derniers mois. Les archives plus anciennes ne peuvent être supprimées que par lots, par projet. Supprimer tout un projet — l’unique action qui atteint l’archive dans son ensemble — n’est pas disponible pour les agents, quel que soit leur niveau ; cela s’effectue dans le panneau de compte, où une personne tape le nom du projet.

La raison pour laquelle cela est important est simple : la mémoire curatée est dérivée, tandis que l’archive est l’original. Tout ce qu’une mauvaise modification fait perdre peut être reconstruit à partir de l’histoire. Rien ne peut reconstruire l’histoire.

Chiffrement, sauvegardes et lieu de stockage de vos données

Votre mémoire correspond à un conteneur par client : sa propre base de données, son propre système de fichiers, son propre utilisateur Linux, rien de partagé. Si vous choisissez la configuration locale, ce conteneur s'exécute sur votre machine : votre mémoire est stockée chez vous et nous n'en conservons aucune partie. Ce qui transite par notre hub — notre instance de calcul sécurisé à Zurich, en Suisse — c'est le contenu en cours de traitement : chaque échange, ainsi que les fragments de mémoire que votre conteneur envoie lorsqu'un jugement est nécessaire ou qu'un résumé de session doit être composé. La section 4 de la Politique de confidentialité les énumère précisément. Aucun de ces éléments n'est conservé.

Ce qu'est le logiciel sur votre machine

Le conteneur contient votre mémoire, la recherche sur celle-ci et les mécanismes qui maintiennent les deux corrects. Il ne contient aucun prompt, aucun accès à un modèle d'IA, et aucun réglage qui le dirigerait vers l'un d'eux. Il n'y a rien à l'intérieur qui puisse juger votre mémoire, ni rien à configurer qui lui permette d'essayer. Chaque jugement est demandé à notre hub via une connexion que votre conteneur établit en sortant et authentifie — nous ne nous connectons jamais nous-mêmes.

C'est cette architecture qui rend le trafic auditable, et vous êtes invité à l'auditer : les échanges montent, les éléments ci-dessus montent, les commandes et les lignes redescendent. Le client est source-available — lisez chaque ligne.

Une chose reste entièrement de votre côté : rechercher dans votre propre mémoire — les enregistrements, toute l’histoire ainsi que les décisions datées — s’effectue par une simple lecture de vos propres tables, à l’intérieur de votre propre conteneur. Cela fonctionne même si notre hub est injoignable et n’envoie rien à évaluer.

Sur la configuration hébergée, le trafic est chiffré en transit avec TLS, et au repos, tout le système de fichiers de votre conteneur — chaque conversation, chaque enregistrement, la base de données elle-même — est chiffré à l’aide d’une clé dérivée d’un mot de passe que vous seul détenez. Nous ne le voyons jamais et ne le stockons jamais : il est transmis lorsque votre session commence, déverrouille votre mémoire, puis cette dernière se verrouille à nouveau une fois que vous vous éloignez. Un conteneur verrouillé n’est qu’un texte chiffré pour tout le monde, y compris nous — un disque volé, une image divulguée ou un disque désaffecté ne représentent qu’un bruit, tout comme notre propre accès en mode root lorsque vous n’êtes pas présent.

La suppression est cryptographique

Effacer vos données n’est pas une simple opération de suppression de fichiers : votre conteneur chiffré est détruit dans son intégralité — et comme aucune clé n’est nécessaire pour supprimer le texte chiffré, cela fonctionne même si vous avez oublié votre mot de passe. Les sauvegardes restantes sont illisibles sans cette clé et sont effacées au fur et à mesure que le système de sauvegarde fonctionne, au plus tard dans 30 jours. Il n’existe aucune copie que nous puissions restaurer.

Ce que le chiffrement ne couvre pas

Des limites honnêtes. Le chiffrement au repos est bien ce qu’il indique : au repos. Tant que votre mémoire est déverrouillée pour une session, le conteneur doit nécessairement traiter vos données en clair afin de répondre à vos recherches. Ainsi, l’affirmation selon laquelle « nous ne consultons jamais vos données » reflète notre politique et nos contrôles d’accès, et non une impossibilité mathématique. La garantie mathématique existe plutôt lorsque le conteneur est verrouillé. Nous préférons vous indiquer où se trouve cette limite plutôt que de vous laisser croire qu’elle n’existe pas.

Les sauvegardes des conteneurs hébergés consistent en la récupération du système de fichiers chiffré lui-même — du texte chiffré avant qu’il ne quitte l’ordinateur, illisible sans votre mot de passe — conservé sous forme de série de copies quotidiennes et hebdomadaires en Allemagne. Lorsqu’un compte est supprimé, ses sauvegardes le sont également, et les copies restantes sont effacées dans un délai de 30 jours.

La mémoire hébergée est stockée, indexée et recherchée entièrement au sein de l’UE — nos serveurs et sauvegardes se trouvent en Allemagne. Les embeddings de recherche sont calculés sur nos propres machines et n’en sortent jamais. La mémoire locale n’a jamais accès à tout cela : elle se trouve sur votre disque, sous la protection que vous lui donnez.

La seule exception concerne la curation par l’IA. Chaque passage soumis à la curation est traité sur notre instance de calcul sécurisée située à Zurich, en Suisse — un pays reconnu par l’UE comme offrant un niveau adéquat de protection des données — et de là, un seul passage du modèle est envoyé à Ollama, qui héberge ce modèle aux États-Unis et en Europe, où il est traité avant d’être renvoyé. Les conditions publiées par Ollama indiquent que les entrées et les sorties sont traitées de manière temporaire et ne sont jamais utilisées pour entraîner des modèles — tel est leur engagement, selon leurs propres termes, et nous le citons comme étant le leur plutôt que comme une promesse de notre part. Rien d’autre ne quitte l’UE. Si vous souhaitez que la curation ne quitte également jamais l’UE, cela est possible grâce à un déploiement dédié — demandez. Chaque sous-traitant, avec sa finalité et son emplacement, est listé dans la Politique de confidentialité.

Comment nous fonctionnons

Principe du moindre privilège, par défaut

Le service fonctionne en tant qu’utilisateur non privilégié à l’intérieur de son conteneur, jamais en tant que root. Son rôle de base de données n’est pas celui d’un superutilisateur et il ne peut pas lire de fichiers depuis l’hôte. Ces éléments sont vérifiés automatiquement avant chaque mise à jour, plutôt que d’être pris pour acquis.

Les points d’extrémité internes sont verrouillés au bord.

Les points d’extrémité qui gèrent les comptes et valident les clés ne sont accessibles que par notre propre plan de contrôle, authentifiés au bord du réseau avant même qu’une demande n’arrive, puis à nouveau grâce à un secret partagé. Deux verrous, pas un.

Échec fermé

Lorsqu’il y a un manque ou que le contenu est illisible, le service refuse de traiter la demande plutôt que de deviner. Une clé non vérifiable est rejetée. Des permissions corrompues ne permettent rien. Un secret de signature webhook manquant rejette tous les événements au lieu de faire confiance à ce qui arrive. Il s’agit d’une approche délibérée : le mode de défaillance d’un service de mémoire doit être « aucune réponse », jamais « la réponse du mauvais client ».

Chaque version est prouvée de l’extérieur

Avant toute publication, un contrôle automatisé parcourt l’ensemble du produit depuis un compte entièrement nouveau via une connexion réseau réelle : inscription, émission et révocation de clés, stockage et rappel de mémoire, isolation entre deux comptes actifs, export de données et effacement complet. Soit il réussit entièrement, soit la version n’est pas publiée.

Signaler un problème de sécurité

Si vous pensez avoir découvert une vulnérabilité, veuillez nous en informer avant d’en parler à qui que ce soit d’autre, et nous travaillerons avec vous. Les coordonnées de contact sont publiées à /.well-known/security.txt ou écrivez à hello@Brethof.ai. Nous ne menaçons pas les chercheurs qui rapportent de bonne foi.

Des exigences plus poussées — un accord de traitement des données, un déploiement dédié dans une région de votre choix, ou le maintien de l’organisation au sein de l’UE — sont des choses que nous gérons directement. Demandez-nous.