Beveiliging

Eén database per klant

Uw geheugen is geen rij in een gedeelde tabel met een klantkolom. Elke klant krijgt zijn eigen eigen database. Er zijn geen gedeelde tabellen en geen cross-customer queries die fout kunnen gaan, omdat de grens de database zelf is, niet een filter dat iemand moet onthouden te schrijven.

Die grens wordt bij elke release van buitenaf getest: twee echte accounts, en elke poort die gegevens teruggeeft wordt gecontroleerd om te bevestigen dat geen van beide de ander kan zien. Een release wordt niet uitgebracht als dat niet slaagt.

Sleutels, en wie ze mag gebruiken

We kunnen u uw eigen sleutel niet laten zien.

API-sleutels worden u precies één keer getoond, bij het aanmaken. Wat wij opslaan is een SHA-256-hash — zodat een kopie van onze database niemand een werkende sleutel oplevert, en noch wij noch een aanvaller uw sleutel kunnen teruglezen. Het intrekken van een sleutel heeft binnen ongeveer een minuut effect op de dienst, en onmiddellijk op de machine die uw geheugen bedient.

Sleutels kunnen worden beperkt

Een sleutel hoeft niet almachtig te zijn. Sleutels kunnen per project beperkt — lezen en schrijven, alleen-lezen of volledig onzichtbaar

Tweefactorauthenticatie

Uw account kan bij het inloggen een tweede factor vereisen, en wanneer u die inschakelt, wordt deze bij het inloggen afgedwongen, niet alleen als instelling weergegeven. We raden het aan en dwingen het niet: uw geheugen is alleen zo beschermd als het account dat het bevat, maar het wissen van uw eigen gegevens afhankelijk maken van het registreren van een telefoon zou erger zijn.

Bescherming tegen je eigen agenten

Dit is het onderdeel waar de meeste diensten niet aan denken. Uw geheugen wordt voortdurend bewerkt door AI-agenten — en een agent kan een fout maken, een kwaadaardige instructie krijgen die verborgen zit in inhoud die hij moest lezen, of het verkeerde verwijderen uren voordat een mens het merkt.

Dus het originele gespreksarchief ligt opzettelijk buiten hun bereik. Geen enkele agent kan één bericht verwijderen. Geen enkele agent mag de afgelopen drie maanden aanraken.Eerder historisch materiaal kan alleen in bulk worden verwijderd, per project. Het verwijderen van een heel project – de enige actie die het archief volledig bereikt – is voor geen enkele agent beschikbaar; dit gebeurt in het accountpaneel, waar een mens de projectnaam invoert.

De reden waarom dit belangrijk is, is eenvoudig: gecureerde herinneringen zijn afgeleid, en het archief is het origineel. Alles wat verloren gaat door een slechte bewerking kan opnieuw worden opgebouwd uit de geschiedenis. Niets kan de geschiedenis opnieuw opbouwen.

Versleuteling, backups en waar uw gegevens zich bevinden

Verkeer wordt tijdens het transport versleuteld met TLS. Wanneer het opgeslagen is, wordt uw geheugen ook versleuteld. twee keer: Er wordt volledige versleuteling gebruikt op het laagste niveau, en daarnaast is je database – elke conversatie, elk record en het write-ahead-log – ook versleuteld. je eigen sleutel per klant, gescheiden van die van alle andere klanten. De sleutel die het opslagvolume ontgrendelt, wordt helemaal niet op de databaseserver opgeslagen: een gestolen schijf, een gelekte afbeelding of een afgeschreven drive zijn onbelangrijk.

Verwijdering is cryptografisch

Omdat elke klant zijn eigen sleutel heeft, is het wissen van jou geen hoopvolle actie bij het doorzoeken van de opslag: Uw sleutel is vernietigd en uw database is verwijderd., En wat overblijft, is voor iedereen onleesbaar, inclusief ons. De gecodeerde back-ups worden direct verwijderd in plaats van te laten verlopen, en eventuele overgebleven kopieën worden uitgewist wanneer onze back-upsystemen opnieuw worden geïnstalleerd, uiterlijk binnen 30 dagen. Er is geen kopie meer die we kunnen terughalen.

Wat per-customer encryptie niet dekt

Twee duidelijke grenzen. De databases引擎 bewaart interne statistieken voor het plannen van zoekopdrachten, waarbij waarden uit kolommen worden geselecteerd; deze samples vallen onder het volumeversleutelingssysteem, niet onder uw persoonlijke sleutel. En versleuteling bij stilstand betekent precies dat: de dienst moet uw gegevens ontsleutelen om zoekopdrachten te verwerken en bepaalde processen uit te voeren. Daarom is het onze beleid en onze toegangsbeheersing dat “wij nooit naar uw gegevens kijken”, en niet een wiskundig onmogelijkheid. We vertellen u liever waar de grens ligt dan dat u denkt dat die er niet is.

Back-ups worden elke nacht uitgevoerd, zijn versleuteld voordat ze onze apparaten verlaten, Ze worden op een rotatieschema buiten de EU opgeslagen en blijven tot drie maanden bewaard. Wanneer een account wordt verwijderd, worden de back-ups er ook bij verwijderd, en eventuele overgebleven kopieën worden binnen 30 dagen verwijderd.

Uw geheugen wordt volledig binnen de EU opgeslagen, geïndexeerd en doorzocht — onze servers staan in Frankfurt en onze back-ups in Falkenstein, beide in Duitsland. Zoekembeddings worden berekend op onze eigen machines en verlaten die nooit.

De enige uitzondering is AI-curatie. De passage die wordt gecureerd, wordt verzonden naar Ollama, in de Verenigde Staten, Verwerkt en teruggestuurd. Volgens de gepubliceerde voorwaarden van Ollama worden invoer en uitvoer tijdelijk verwerkt en worden ze nooit gebruikt om modellen te trainen — dat is hun toezegging, in hun eigen woorden, en wij geven dit weer als hun uitspraak in plaats van als onze belofte. Niets anders verlaat de EU. Als u wilt dat alles ook nooit de EU verlaat, is dat mogelijk via een gespecialiseerde implementatie — vraag ernaar. Elke onderverwerker, met doel en locatie, staat vermeld in de Privacybeleid.

Hoe wij werken

Minimaal recht, standaard

De dienst draait als een onbevoegde gebruiker in zijn container, nooit als root. Zijn databaserol is geen supergebruiker en kan geen bestanden van de host lezen. Dit wordt vóór elke release automatisch gecontroleerd in plaats van aangenomen.

Interne endpoints zijn aan de rand vergrendeld.

De endpoints die accounts aanmaken en sleutels verifiëren, zijn alleen bereikbaar via ons eigen control plane; ze worden geauthenticeerd aan de netwerkrand voordat een verzoek ooit aankomt, en opnieuw met een gedeeld geheim erachter. Twee sloten, niet één.

Veilig falen

Wanneer iets ontbreekt of onleesbaar is, weigert de dienst in plaats van te raden. Een niet-verifieerbare sleutel wordt geweigerd. Corrupte machtigingen verlenen niets. Een ontbrekend webhook-ondertekeningsgeheim wijst elke gebeurtenis af in plaats van te vertrouwen wat er aankomt. Dit is een bewuste houding: de faalmodus van een geheugendienst moet “geen antwoord” zijn, nooit “het antwoord van de verkeerde klant”.

Elke release is van buitenaf bewezen

Voordat een release wordt uitgebracht, controleert een geautomatiseerde poort het hele product vanaf een gloednieuw account via een echte netwerkverbinding: registreren, sleutels uitgeven en intrekken, geheugen opslaan en oproepen, isolatie tussen twee actieve accounts, gegevens exporteren en volledige verwijdering. Het slaagt volledig of de release gaat niet door.

Een beveiligingsprobleem melden

Als u denkt dat u een kwetsbaarheid hebt gevonden, vertel het ons alstublieft voordat u het aan iemand anders vertelt, en wij zullen met u samenwerken. De contactgegevens staan op /.well-known/security.txt of schrijf naar [email protected]. We bedreigen geen onderzoekers die te goeder trouw melden.

Diepere vereisten — een verwerkersovereenkomst, een speciale implementatie in een door u gekozen regio, of curatie binnen de EU houden — zijn zaken die wij direct afhandelen. Vraag het ons.