AI-geheugen versleutelen: waarom een sleutel per project beter is dan een per database

Een geheugen dat de moeite waard is om te hebben, is de moeite waard om te beschermen. Als een systeem gaat bewaren wat u het vertelde over de diagnose van uw kind, uw rechtszaak of uw financiën, dan verdient de frase « versleuteld in rust » — die elke aanbieder gebruikt — een strengere blik op wat ze werkelijk betekent.

Wat « versleuteld in rust » meestal betekent

Meestal betekent het volledige-schijf- of volumeversleuteling. De schijf is versleuteld; het databaseproces houdt de sleutel en ontsleutelt alles wat het leest. Dat beschermt tegen één ding — dat iemand de schijf fysiek wegneemt — en tegen bijna niets anders. Een aanvaller die de draaiende database bereikt, een gestolen back-up die zijn sleutel meeneemt, een te brede interne query: in al deze gevallen zijn de gegevens gewoon leesbaar, want vanuit het oogpunt van de database waren ze dat altijd.

Voor een product gebouwd op geheugen heeft het bovendien een ongemakkelijke eigenschap: één sleutel opent iedereen. Er is geen technische grens tussen uw materiaal en dat van een andere klant, alleen correct geschreven query's.

Een sleutel per project

FocusLM versleutelt op rijniveau, niet op schijfniveau. Elk project krijgt zijn eigen gegevenssleutel. Elk geheugenbestand, elke revisie ervan en elk bericht in de chat van dat project wordt met die sleutel versleuteld en met geen andere. Chatthreads die tot geen project behoren, worden met een werkruimtesleutel versleuteld, volgens hetzelfde principe.

Die sleutels per project worden op hun beurt versleuteld door één sleutel per omgeving, die nooit naast de gegevens wordt bewaard die hij beschermt. Deze opzet — een sleutel die sleutels versleutelt, die gegevens versleutelen — is envelopversleuteling, en het is de standaardaanbeveling voor sleutelhiërarchieën in de sleutelbeheer- richtlijnen van het NIST. Ze levert twee praktische dingen op: de bovenste sleutel roteren raakt één kleine rij per project in plaats van iemands gegevens opnieuw te versleutelen, en de sleutel van één project kan afzonderlijk worden vernietigd.

De binding is strakker dan « zelfde sleutel, zelfde project ». Elke versleutelde waarde is cryptografisch gebonden aan de exacte rij en het project waartoe ze behoort, zodat cijfertekst die naar een ander project is gekopieerd niet in de verkeerde context ontsleutelt: ze ontsleutelt helemaal niet. Gegevens tussen tenants verplaatsen is geen subtiele bug die later opduikt; het is een fout op het moment van de poging.

Waarom we niet over cijfertekst zoeken

De voor de hand liggende wens is alles versleuteld houden en er toch gewone tekstzoekopdrachten op uitvoeren. Er bestaan schema's — deterministische versleuteling maakt gelijke waarden gelijk, ordebehoudende houdt waarden sorteerbaar — en ze zijn precies zo handig als ze klinken.

Ze lekken ook. Een lange reeks werk over inferentie-aanvallen op eigenschapsbehoudend versleutelde databases toont aan dat, wanneer cijferteksten gelijkheid of orde behouden, een aanvaller met niets dan de versleutelde kolom en gewone openbare statistiek een groot deel van de platte tekst kan herstellen. Frequentieanalyse doet het meeste werk: in echte gegevens is de verdeling van waarden zelden vlak, en versleuteling die structuur behoudt, behoudt de verdeling ermee.

De zoekindex bevat uw tekst niet

Semantisch zoeken heeft vectoren nodig, en vectoren hebben hun eigen privacyverhaal — een dat makkelijk misgaat, omdat een embedding op een inerte lijst getallen lijkt.

Het is niet inert. In Text Embeddings Reveal (Almost) As Much As Texttoonden Morris en collega's aan dat dichte embeddings terug te herleiden zijn naar hun oorspronkelijke tekst door reconstructie als gecontroleerde generatie te behandelen en een gok iteratief te corrigeren tot ze naar hetzelfde punt her-embedt. Ze herstelden 92% van de 32-token-invoeren exacten haalden volledige patiëntnamen uit een corpus klinische notities. Later werk generaliseerde de aanval: een generatief inversiemodel kan samenhangende hele zinnen reconstrueren uit één zin-embedding, en vervolgstudies hebben het resultaat gereproduceerd en uitgebreid.

De tekst verwijderen sluit dat argument echter niet af, en het als afgesloten voorstellen zou oneerlijk zijn. De vector zelf is er nog — dat moet, want de geometrie tussen vectoren is precies wat semantisch zoeken mogelijk maakt. Hem versleutelen zoals we een notitie versleutelen zou niets over laten om te doorzoeken.

De volgende stap is dus de vectorruimte te binden aan dezelfde sleutel per project die de inhoud al beschermt: de vectoren van elk project bevinden zich in een ruimte die alleen de sleutel van dat project beschrijft. Dat houdt het zoeken onveranderd en maakt de vectoren tegelijk onbruikbaar in de eigen coördinaten van het embeddingmodel — waar de gepubliceerde inversie-aanvallen opereren. Dat verhoogt de kosten van een aanval in plaats van hem te elimineren, en we zeggen dat liever dan het versleuteling te noemen. Het is in uitvoering, niet uitgeleverd.

Het gevolg voor een geheugenproduct is direct: een gestolen vectorindex moet als gestolen platte tekst worden behandeld. Daarom bewaart FocusLM's index de vector, het bestandspad en een gesleutelde vingerafdruk — en niet de tekst van uw notities. Wanneer een zoekopdracht matcht, wordt het fragment dat u leest op dat moment uit de versleutelde opslag gehaald en ontsleuteld. De index weet wáár iets relevants ligt; hij weet niet wat het zegt.

Verwijderen dat de back-up overleeft

« Verwijderen » betekent in de meeste systemen dat een rij als verwijderd wordt gemarkeerd. De gegevens blijven — in de tabel, in de dump van gisteravond, in de replica, in welke bewaartermijn de back-ups ook hebben. Voor een notitie over de ziekte van een kind is dat geen verwijderen in enige zin die de vragende persoon zou herkennen.

Omdat elk project zijn eigen sleutel heeft, kunnen we iets sterkers doen: een project verwijderen vernietigt die sleutel. De cijfertekst blijft waar ze al zit, en niets ervan kan ooit nog worden gelezen — niet in de live database, niet in een snapshot dat vóór het verwijderen is gemaakt. Dit is crypto-shredding, en het is het standaardantwoord op wissen in systemen waar elke kopie fysiek overschrijven onpraktisch of niet-verifieerbaar is, dat wil zeggen elk gedistribueerd systeem met back-ups.

Recent werk scherpt de zaak specifiek voor AI-systemen aan. Een studie uit 2026 over vectordatabases vond dat embeddings die louter zacht verwijderd zijn, uit de indexstructuur reconstrueerbaar blijven: het verwijderen is een vlag, en de gegevens zijn er nog voor wie het bestand leest in plaats van de query-engine te bevragen. Gecombineerd met embedding-inversie is een soft-delete in een vectoropslag helemaal geen delete.

Wat eerlijk gezegd nog zichtbaar is

Versleutelingsbeloften zijn precies zoveel waard als de uitzonderingen die ze toegeven. De onze:

• Structuur is geen inhoud. Map- en bestandsnamen in uw geheugen worden in klare tekst bewaard, omdat het systeem er doorheen bladert en globt. Een pad als gezondheid/oncologie/… onthult een onderwerp ook al is de notitie zelf onleesbaar.
• Chattitels. De titel van een thread wordt in klare tekst bewaard zodat de zijbalk hem kan doorzoeken, en hij wordt uit uw eerste bericht gegenereerd. Het gesprek is versleuteld; de zin die het opende niet.
• Bestandsnamen. De naam die u hebt geüpload reist mee in de opslagsleutel en in het operationele logboek, ook al is de inhoud van het bestand verzegeld.
• De zoekvectoren, voorlopig. Vandaag zitten ze in de index in de eigen ruimte van het embeddingmodel, de ruimte waarop het inversieonderzoek van toepassing is. Ze aan de projectsleutel binden is het werk dat hierboven is beschreven.
• Operationele metadata. Welk model draaide, hoe lang het duurde, wat het kostte. Niet wat er werd gezegd.

Een patroon loopt erdoorheen: inhoud is beschermd, namen niet. Paden, titels en bestandsnamen zijn wat het systeem moet lezen om te ordenen en te vinden, dus ze blijven leesbaar. Het is een echte grens, het is degene waarover we als gebruiker geïnformeerd zouden willen worden, en het is het volgende om aan te werken, geen voetnoot om weg te wuiven.

Waarom dit in het bijzonder telt voor een geheugenproduct

Een chatassistent die u tussen sessies vergeet, bevat weinig dat de moeite van het stelen waard is. Een systeem gebouwd om de dingen te verzamelen waar u telkens naar terugkeert — het gestructureerde geheugen dat gefundeerde antwoorden mogelijk maakt — verzamelt precies het materiaal dat nooit zou mogen lekken. De waarde van het geheugen en de gevoeligheid ervan groeien samen; het is dezelfde eigenschap van twee kanten bezien.

Dat is de reden om het ingenieurswerk in een sleutel per project te steken in plaats van in een vinkje dat versleuteld zegt. Hoe sterker het geheugen, hoe minder aanvaardbaar het gewone antwoord.