FocusLM
Alle Artikel

KI-Gedächtnis verschlüsseln: warum ein Schlüssel pro Projekt einen pro Datenbank schlägt

27. Juli 20269 Min. Lesezeit

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.

Umgebungsschlüssel (KEK)nie neben den Daten gespeichertumhülltSchlüssel Projekt ASchlüssel Projekt BAs Gedächtnis + ChatBs Gedächtnis + Chatdiesen zerstören → A ist überall unlesbar, auch in Backups
Ein Umgebungsschlüssel umhüllt einen eigenen Datenschlüssel pro Projekt. Das Material von Projekt A ist nur unter As Schlüssel verschlüsselt — die Datenbank hält nie einen Schlüssel, der alles öffnet.

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.

Deshalb entschlüsselt FocusLM innerhalb der Anwendung und filtert dort, statt die Datenbank auf Chiffretext abgleichen zu lassen. Der Preis ist real und verdient es, benannt zu werden: eine wörtliche Suche liest die gesamten Notizen eines Projekts, statt einen Index zuerst eingrenzen zu lassen, sodass der Aufwand mit der Größe Ihres Gedächtnisses wächst, statt flach zu bleiben. Wir haben das genommen, statt Suchbarkeit mit einem dauerhaften Leck von Begriffshäufigkeiten zu erkaufen — die in einem persönlichen Gedächtnis die wichtigsten Wörter sind.

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 rekonstruiert

Die 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.

Crypto-Shredding ist wirklich unumkehrbar, was der Sinn und zugleich das Risiko ist. Ein gelöschtes Projekt aus einem Backup wiederherzustellen bringt Zeilen zurück, die niemand lesen kann. FocusLM bittet Sie deshalb, den Namen des Projekts einzutippen, bevor es geht — dieselbe Reibung, die eine zerstörerische Aktion überall sonst schützt.

Was ehrlicherweise noch sichtbar ist

Verschlüsselungsversprechen sind genau so viel wert wie die Ausnahmen, die sie einräumen. Unsere:

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.

Weiterführende Artikel