Sikkerhed

En database per kunde

Din hukommelse er ikke en række i en delt tabel med en kundekolonne. Hver kunde får sin egen. egen database. Der er ingen fælles tabeller og ingen tværkundeforespørgsler, der kan gå galt, fordi grænsen er selve databasen i stedet for et filter, man skal huske at skrive.

Denne grænse testes fra udsiden ved hver udgivelse: to rigtige konti, og hver dør, der returnerer data, kontrolleres for at bekræfte, at ingen kan se den anden. En udgivelse sendes ikke ud, med mindre det består.

Nøgler, og hvem der kan bruge dem

Vi kan ikke vise dig din egen nøgle.

API-nøgler vises kun én gang, ved oprettelse. Det, vi gemmer, er en SHA-256-hash – så en kopi af vores database giver ingen en fungerende nøgle, og hverken vi eller en angriber kan læse din nøgle tilbage. Tilbagekaldelse af en nøgle træder i kraft på tjenesten inden for omkring et minut og øjeblikkeligt på den maskine, der betjener din hukommelse.

Nøgler kan begrænses

En nøgle behøver ikke at være almægtig. Nøgler kan være afgrænset per projekt — Læs og skriv, kun læsning, eller helt usynlig – hvilket er den rigtige form for en kontraktør, en CI-opgave eller en enkeltformålsagent, der ikke har noget at gøre med at læse resten af dit arbejde. En nøgle med korrupte eller uleselige scopes nægtes alt i stedet for at få tilladelse til alt.

To-faktor-autentificering

Din konto kan kræve en anden faktor ved login, og når du slår det til, håndhæves det ved logind, ikke kun vises som en indstilling. Vi anbefaler det, og vi tvinger det ikke: din hukommelse er kun så beskyttet som den konto, der holder den, men at gøre sletning af dine egne data betinget af at tilmelde en telefon ville være værre.

Beskyttelse mod dine egne agenter

Dette er den del, de fleste tjenester ikke tænker på. Din hukommelse bliver kontinuerligt behandlet af AI-agenter – og en agent kan lave en fejl, få en skadelig instruktion gemt i indhold, den er blevet bedt om at læse, eller slette det forkerte timer, før et menneske opdager det.

Altså er den oprunne konversationsarkivet med vilje uforrindeligt for dem at komme til. Ingen agent kan slette en enkelt melding. Ingen agent kan på nogen måde påvirke de sidste tre måneder. Eldre historik kan kun fjernees i stor mængde, projekt for projekt. At slette et hele projekt – den eneste handlingen, der kan påvirke arkivet i helhed – er ikke tilgængeligt for agenter på nogen niveau; det sker i kontopanelen, hvor en menneske skriver ind projektets navn.

Grunden til, at dette er vigtigt, er enkel: kurateret hukommelse er afledt, og arkivet er det oprindelige. Alt, hvad en dårlig redigering taber, kan genopbygges fra historien. Intet kan genopbygge historien.

Kryptering, sikkerhedskopier og hvor dine data lever

Trafikken krypteres under overførsel med TLS. Når den er i hvile, krypteres din hukommelse. to gange: Fuld volumenkryptering i bunden, og oven på det er din database – hver samtale, hver registrering og write-ahead-loggen – krypteret under din egen, Adskilt fra alle andre kunders data.

Sletning er kryptografisk

Fordi hver kunde har sin egen nøgle, er det ikke en håbefuld gennemgang af lagringsområdet at slette dig: Din nøgle er ødelagt, og din database er slettet, Og det, som overbliver, er ulesteligt for alle, inklusive os. De krypterede sikkerhedskopier slettes direkte istedet for at blive lade til at udløbe, og alle overblevende kopier slettes når vores sikkerhedskopiersystemer cykliser, i højst 30 dage. Der er ingen kopi, vi kan bruge til at genoprette det.

Hvad kundebaseret kryptering ikke dækker

To ærlige grænser. Databasemotoren holder interne statistikker for forespørgselsplanlægning, der stikprøver kolonneværdier; disse prøver ligger under volumenkrypteringen, ikke din personlige nøgle. Og kryptering i hvile er præcis det – i hvile: Tjenesten må nødvendigvis dekryptere dine data for at levere dine søgninger og køre kuratering, så “vi ser aldrig på dine data” er vores politik og vores adgangskontroller, ikke en matematisk umulighed. Vi vil hellere fortælle dig, hvor grænsen er, end lade dig antage, at der ikke er en.

Sikkerhedskopier kører hver nat, er krypteret, før de forlader vores maskiner, Og de lagres udenfor den lokale område i EU efter en rotativ planlægning, og bliver gemt i op til tre måneder. Når en konto slettes, slettes også dess sikkerhedskopier, og alle overblivende kopier forsvinder inden for 30 dage.

Din hukommelse er lagret, indekseret og søgt helt inden for EU – vores servere er i Frankfurt og vores backups i Falkenstein, begge i Tysk. Søge-embedder beregnes på vores egne maskiner og forlader dem aldrig.

Den eneste undtagelse er AI-kurering. Den tekst, der kureres, sendes til Ollama, i USA, Behandlet og returneret. Ollamas offentliggjorde vilkår angiver, at inddata og uddata behandles tilfældigt og aldrig bruges til at træne modeller – det er deres engang, i deres egne ord, og vi angiver det som deres fremstilling fremfor som vores løfte. Ingen andet kommer ud af EU. Hvis du ønsker, at data aldrig skal komme ud af EU heller, er det muligt gennem en speciel implementering – spør efter. Hver underbehandler, med sin formål og placering, er oplyst i Privatlivspolitik.

Sådan arbejder vi

Mindste privilegier, som standard

Tjenesten køres som en uprivilegeret bruger inde i sin container, aldrig som root. Dens databaserolle er ikke en superbruger og kan ikke læse filer fra værten. Dette verificeres automatisk før hver udgivelse i stedet for at antages.

Interne endepunkter er låst ved kanten

De endepunkter, der opretter konti og validerer nøgler, er kun tilgængelige via vores egen kontrolplan, autentificeres ved netværkskanten, før en anmodning nogensinde ankommer, og igen gennem en delt hemmelighed bagved. To låse, ikke en.

Lukket ved fejl

Når noget mangler eller er ulæseligt, afviser tjenesten i stedet for at gætte. En nøgle, der ikke kan verificeres, afvises. Korrupte tilladelser giver intet. En manglende webhook-signeringshemmelighed afviser alle hændelser i stedet for at stole på det, der ankommer. Dette er en bevidst holdning: fejltilstanden for en hukommelsestjeneste bør være "intet svar", aldrig "den forkerte kundes svar".

Hver udgivelse er bevist udefra

Før enhver udgivelse sendes, gennemgår en automatiseret kontrol hele produktet fra en helt ny konto gennem en virkelig netværksforbindelse: oprettelse, udstedelse og tilbagekaldelse af nøgler, lagring og genkaldelse af hukommelse, isolering mellem to aktive konti, dataeksport og fuld sletning. Det enten består fuldstændigt, eller udgivelsen sker ikke.

At rapportere et sikkerhedsproblem

Hvis du mener, du har fundet en sårbarhed, så beder vi dig kontakte os, før du fortæller det til andre, og vi vil samarbejde med dig. Kontaktoplysningerne er offentliggjort på /.well-known/security.txt eller skriv til [email protected]. Vi truer ikke forskere, der rapporterer i god tro.

Dybere krav – en databehandlingsaftale, en dedikeret installation i en region, du vælger, eller at holde kuratering inden for EU – er ting, vi håndterer direkte. Spørg.