Ein Gedächtnis, das es wert ist, es zu haben, ist es auch wert, geschützt zu werden. Wenn ein System festhält, was Sie ihm über die Diagnose Ihres Kindes, Ihren Rechtsstreit oder Ihre Finanzen erzählt haben, dann verdient die Formel „verschlüsselt im Ruhezustand“ — die jeder Anbieter benutzt — einen genaueren Blick darauf, was sie eigentlich bedeutet.
TL;DR
- Jede Gedächtnisdatei und jede Chat-Nachricht wird mit einem Schlüssel verschlüsselt, der allein einem Projektgehört — nicht mit einem einzigen Schlüssel für die ganze Datenbank.
- Ein Projekt zu löschen zerstört seinen Schlüssel, sodass die Daten auch in Backups unlesbar werden — nicht nur im Live-System.
- Wir suchen nicht über Chiffretext, und wir speichern Ihren Text nicht im Suchindex. Beide Entscheidungen folgen aus veröffentlichten Angriffen, nicht aus Geschmack.
Was „verschlüsselt im Ruhezustand“ meist bedeutet
Meist bedeutet es Voll- oder Volume-Verschlüsselung der Festplatte. Die Platte ist verschlüsselt; der Datenbankprozess hält den Schlüssel und entschlüsselt alles, was er liest. Das schützt gegen genau eine Sache — dass jemand die Platte physisch entwendet — und gegen fast nichts sonst. Ein Angreifer, der die laufende Datenbank erreicht, ein gestohlenes Backup, das seinen Schlüssel mitliefert, eine zu breite interne Abfrage: in all dem sind die Daten klar lesbar, denn aus Sicht der Datenbank waren sie es immer.
Für ein Produkt, das auf Gedächtnis baut, hat das eine unangenehme Eigenschaft: ein Schlüssel öffnet alle. Zwischen Ihrem Material und dem eines anderen Kunden gibt es keine technische Grenze, nur korrekt geschriebene Abfragen.
Ein Schlüssel pro Projekt
FocusLM verschlüsselt auf Zeilenebene, nicht auf Plattenebene. Jedes Projekt erhält seinen eigenen Datenschlüssel. Jede Gedächtnisdatei, jede ihrer Revisionen und jede Nachricht im Chat dieses Projekts wird mit diesem einen Schlüssel verschlüsselt und mit keinem anderen. Chat-Threads, die zu keinem Projekt gehören, werden nach demselben Prinzip mit einem Workspace-Schlüssel verschlüsselt.
Diese projekteigenen Schlüssel werden ihrerseits von einem einzigen Schlüssel pro Umgebung verschlüsselt, der niemals neben den Daten liegt, die er schützt. Diese Anordnung — ein Schlüssel, der Schlüssel verschlüsselt, die Daten verschlüsseln — heißt Envelope-Verschlüsselungund ist die Standardempfehlung für Schlüsselhierarchien in den Key-Management-Leitlinien des NIST. Sie bringt zwei praktische Dinge: den obersten Schlüssel zu rotieren berührt nur eine kleine Zeile pro Projekt statt irgendwessen Daten neu zu verschlüsseln, und der Schlüssel eines einzelnen Projekts lässt sich allein zerstören.
Die Bindung ist stärker als „gleicher Schlüssel, gleiches Projekt“. Jeder verschlüsselte Wert ist kryptografisch an die exakte Zeile und das Projekt gebunden, zu dem er gehört, sodass ein in ein anderes Projekt kopierter Chiffretext nicht in den falschen Kontext entschlüsselt — er lässt sich gar nicht entschlüsseln. Daten zwischen Mandanten zu verschieben ist kein subtiler Fehler, der später auffällt; es ist ein Fehler im Moment des Versuchs.
Warum wir nicht über Chiffretext suchen
Der naheliegende Wunsch ist, alles verschlüsselt zu halten und trotzdem gewöhnliche Textsuche darauf laufen zu lassen. Verfahren dafür gibt es — deterministische Verschlüsselung macht gleiche Werte gleich, ordnungserhaltende hält Werte sortierbar — und sie sind genau so bequem, wie sie klingen.
Sie leaken auch. Eine lange Reihe von Arbeiten zu Inferenzangriffen auf eigenschaftserhaltend verschlüsselte Datenbanken zeigt: wenn Chiffretexte Gleichheit oder Ordnung bewahren, kann ein Angreifer allein mit der verschlüsselten Spalte und gewöhnlicher öffentlicher Statistik einen Großteil des Klartexts rekonstruieren. Die Häufigkeitsanalyse leistet das Meiste: in echten Daten ist die Verteilung der Werte selten flach, und Verschlüsselung, die Struktur bewahrt, bewahrt die Verteilung gleich mit.
Der Suchindex enthält Ihren Text nicht
Semantische Suche braucht Vektoren, und Vektoren haben ihre eigene Datenschutzgeschichte — eine, die leicht schiefgeht, weil ein Embedding wie eine untätige Zahlenliste aussieht.
Es ist nicht untätig. In Text Embeddings Reveal (Almost) As Much As Text zeigten Morris und Kollegen, dass sich dichte Embeddings in ihren Ursprungstext zurückführen lassen, indem man die Rekonstruktion als kontrollierte Generierung behandelt und eine Vermutung iterativ korrigiert, bis sie zum selben Punkt re-embeddet. Sie rekonstruierten 92 % der 32-Token-Eingaben exaktund gewannen vollständige Patientennamen aus klinischen Notizen. Spätere Arbeit verallgemeinerte den Angriff: ein generatives Inversionsmodell kann aus einem einzigen Satz-Embedding kohärente ganze Sätze rekonstruieren, und Folgestudien haben das Ergebnis reproduziert und erweitert.
Das Entfernen des Textes beendet dieses Argument jedoch nicht, und es als Abschluss darzustellen wäre unehrlich. Der Vektor selbst ist weiterhin da— er muss es sein, denn die Geometrie zwischen Vektoren ist genau das, was semantische Suche möglich macht. Ihn zu verschlüsseln wie eine Notiz ließe nichts zum Suchen übrig.
Der nächste Schritt ist daher, den Vektorraum an denselben projekteigenen Schlüssel zu binden, der den Inhalt bereits schützt: die Vektoren jedes Projekts liegen in einem Raum, den nur der Schlüssel dieses Projekts beschreibt. Das hält die Suche unverändert am Laufen und macht die Vektoren zugleich in den eigenen Koordinaten des Embedding-Modells unbrauchbar — dort, wo die veröffentlichten Inversionsangriffe arbeiten. Das erhöht die Kosten eines Angriffs, statt ihn auszuschließen, und wir sagen das lieber, als es Verschlüsselung zu nennen. Es ist in Arbeit, nicht ausgeliefert.
92 %der kurzen Texte exakt aus ihren Embeddings allein rekonstruiertDie Konsequenz für ein Gedächtnisprodukt ist direkt: ein gestohlener Vektorindex sollte wie gestohlener Klartext behandelt werden. Deshalb speichert FocusLMs Index den Vektor, den Dateipfad und einen geschlüsselten Fingerabdruck — und nicht den Text Ihrer Notizen. Wenn eine Suche trifft, wird das Snippet, das Sie lesen, in diesem Moment aus dem verschlüsselten Speicher geholt und entschlüsselt. Der Index weiß, wo etwas Relevantes liegt; er weiß nicht, was es sagt.
Ein Embedding ist keine anonymisierte Version Ihres Textes. Es ist eine umkehrbare.
Löschen, das das Backup überlebt
„Löschen“ heißt in den meisten Systemen, dass eine Zeile als gelöscht markiert wird. Die Daten bleiben — in der Tabelle, im Dump von gestern Nacht, in der Replik, in welcher Aufbewahrung die Backups auch haben. Für eine Notiz über die Krankheit eines Kindes ist das kein Löschen in irgendeinem Sinn, den die fragende Person wiedererkennen würde.
Weil jedes Projekt seinen eigenen Schlüssel hat, können wir etwas Stärkeres tun: ein Projekt zu löschen zerstört diesen Schlüssel. Der Chiffretext bleibt, wo er bereits sitzt, und nichts davon kann je wieder gelesen werden — nicht in der Live-Datenbank, nicht in einem vor der Löschung gezogenen Snapshot. Das ist Crypto-Shreddingund die Standardantwort auf Löschung in Systemen, wo jede Kopie physisch zu überschreiben unpraktisch oder nicht verifizierbar ist — also jedes verteilte System mit Backups.
Jüngere Arbeit schärft den Fall speziell für KI-Systeme. Eine Studie zu Vektordatenbanken aus 2026 fand, dass Embeddings, die bloß soft-gelöscht wurden, aus der Indexstruktur rekonstruierbar bleiben — die Löschung ist ein Flag, und die Daten sind noch da für jeden, der die Datei liest, statt die Query-Engine zu fragen. Zusammen mit Embedding-Inversion ist ein Soft-Delete in einem Vektorspeicher gar kein Delete.
Was ehrlicherweise noch sichtbar ist
Verschlüsselungsversprechen sind genau so viel wert wie die Ausnahmen, die sie einräumen. Unsere:
- Struktur ist kein Inhalt.Ordner- und Dateinamen in Ihrem Gedächtnis werden im Klartext gespeichert, weil das System sie durchblättert und globbt. Ein Pfad wie
gesundheit/onkologie/…verrät ein Thema, auch wenn die Notiz selbst unlesbar ist. - Chat-Titel.Der Titel eines Threads wird im Klartext gespeichert, damit die Seitenleiste ihn durchsuchen kann, und er wird aus Ihrer ersten Nachricht generiert. Das Gespräch ist verschlüsselt; der Satz, der es eröffnete, nicht.
- Dateinamen. Der Name, den Sie hochgeladen haben, reist im Speicher-Key und im Betriebslog mit, obwohl der Inhalt der Datei versiegelt ist.
- Die Suchvektoren, vorerst.Heute liegen sie im Index im eigenen Raum des Embedding-Modells, dem Raum, auf den die Inversionsforschung zutrifft. Sie an den Projektschlüssel zu binden ist die oben beschriebene Arbeit.
- Betriebs-Metadaten. Welches Modell lief, wie lange es dauerte, was es kostete. Nicht, was gesagt wurde.
Ein Muster zieht sich hindurch: Inhalt ist geschützt, Namen nicht. Pfade, Titel und Dateinamen sind das, was das System lesen muss, um zu ordnen und zu finden, also bleiben sie lesbar. Das ist eine echte Grenze, es ist die, über die wir als Nutzer Bescheid wissen wollten, und es ist das Nächste, woran zu arbeiten ist — keine Fußnote, die man wegwinkt.
Warum das gerade für ein Gedächtnisprodukt zählt
Ein Chat-Assistent, der Sie zwischen Sitzungen vergisst, hält wenig Stehlenswertes. Ein System, das darauf gebaut ist, die Dinge anzusammeln, zu denen Sie immer wieder zurückkehren — das strukturierte Gedächtnis, das fundierte Antworten möglich macht — sammelt genau das Material an, das niemals leaken sollte. Der Wert des Gedächtnisses und seine Sensibilität wachsen zusammen; sie sind dieselbe Eigenschaft von zwei Seiten gesehen.
Das ist der Grund, die Technik in einen Schlüssel pro Projekt zu stecken statt in ein Häkchen, auf dem „verschlüsselt“ steht. Je stärker das Gedächtnis, desto weniger akzeptabel die gewöhnliche Antwort.
Sources
- Morris et al., Text Embeddings Reveal (Almost) As Much As Text (EMNLP 2023, arXiv:2310.06816)
- Li et al., Sentence Embedding Leaks More Information than You Expect: Generative Embedding Inversion Attack (arXiv:2305.03010)
- Rethinking the Privacy of Text Embeddings: A Reproducibility Study (arXiv:2507.07700)
- Data Inference from Encrypted Databases: A Multi-dimensional Order-Preserving Matching Approach (arXiv:2001.08773)
- Ghost Vectors: Soft-Deleted Embeddings Remain Reconstructible in HNSW Vector Databases (arXiv:2606.18497)
- NIST SP 800-57, Recommendation for Key Management