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 nécessiter un deuxième facteur lors de la connexion, et une fois activé, il est exigé à chaque connexion, et non simplement affiché comme une option. Nous le recommandons, mais nous ne l’imposons pas : votre mémoire n’est protégée que dans la mesure où le compte qui la contient l’est également, mais rendre la suppression de vos propres données conditionnelle à l’enregistrement d’un téléphone serait pire.

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 complète des conversations reste délibérément hors de leur portée. Aucun agent ne peut supprimer un seul message. Aucun agent ne peut non plus accéder aux messages des trois derniers mois. L’historique plus ancien ne peut être supprimé que par lots, par projet. Supprimer tout un projet – l’unique action qui permet de supprimer l’archive entière – 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

Le trafic est chiffré en transit avec TLS. En repos, votre mémoire est également chiffrée. deux fois: Chiffrement du volume complet en dessous, et par-dessus cela, votre base de données — chaque conversation, chaque enregistrement, ainsi que le journal d’écriture anticipée — est chiffré en dessous. votre propre clé par client, Séparé de celui de tous les autres clients. La clé qui déverrouille le volume de stockage n’est pas du tout stockée sur le serveur de base de données : un disque volé, une image divulguée ou un disque mis hors service ne représentent qu’un problème supplémentaire.

La suppression est cryptographique

Comme chaque client dispose de sa propre clé, effacer vos données n’est pas une solution envisageable en effectuant un balayage du stockage : Votre clé a été détruite et votre base de données a été supprimée., Et ce qui reste est illisible pour quiconque, y compris nous. Les sauvegardes chiffrées sont supprimées directement au lieu d’attendre leur expiration, et toutes les copies restantes sont effacées au fur et à mesure que nos systèmes de sauvegarde tournent, dans un délai maximal de 30 jours. Il n’y a aucune copie que nous puissions récupérer.

Ce que le chiffrement par client ne couvre pas

Deux limites claires. Le moteur de base de données conserve des statistiques internes de planification des requêtes qui prennent en échantillon les valeurs des colonnes ; ces échantillons sont chiffrés au niveau du volume, et non avec votre clé personnelle. Le chiffrement en repos signifie précisément cela : en repos. Le service doit déchiffrer vos données pour répondre à vos recherches et effectuer la sélection des contenus ; donc, « nous ne consultons jamais vos données » fait partie de notre politique et de nos contrôles d’accès, et non d’une impossibilité mathématique. Nous préférons vous indiquer où se trouve cette limite plutôt que de vous laisser penser qu’il n’y en a pas.

Les sauvegardes ont lieu chaque nuit, sont chiffrés avant de quitter nos machines, Elles sont stockées en dehors du site, dans l’UE, selon un calendrier rotatif, et conservées pendant jusqu’à trois mois. Lorsqu’un compte est supprimé, ses sauvegardes le sont également, et les copies restantes sont supprimées dans un délai de 30 jours.

Votre mémoire est stockée, indexée et recherchée entièrement au sein de l’UE : nos serveurs se trouvent à Francfort et nos sauvegardes à Falkenstein, tous deux en Allemagne. Les représentations de recherche sont calculées sur nos propres machines et ne quittent jamais celles-ci.

La seule exception est la curation par l’IA. Le texte à curer est envoyé Ollama, aux États-Unis, Traité et 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 — telle est leur engagement, selon leurs propres termes, et nous le présentons comme le leur plutôt que comme une promesse de notre part. Rien d’autre ne quitte l’UE. Si vous avez besoin d’une solution garantissant que rien ne quitte non plus l’UE, cela est disponible via un déploiement dédié — demandez-en plus. Chaque sous-traitant, avec sa finalité et son emplacement, est listé dans le 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 à [email protected]. 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.