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 den til, håndhæves den ved hver logind — efter en adgangskode og efter GitHub eller Google lige meget — ikke blot vist som en indstilling.

Oprettelse af en API-nøgle kræver et beskyttet login: tofaktorgodkendelse på din konto, eller et login via GitHub eller Google. Et almindeligt kodeord opretter aldrig en nøgle — heller ikke på en konto, der også har GitHub eller Google tilknyttet, for det afgørende er, hvordan du loggede ind denne gang.

Enhver destruktiv handling — at slette et projekt, redigere historik, slette kontoen, gendanne en backup — spørger igen, hvem du er: din adgangskode, hvis du har en, og din tofaktorkode; uden tofaktor en GitHub- eller Google-login fra de seneste ti minutter. Eksport af dine data kræver det aldrig.

Log ind med GitHub eller Google

Login via GitHub eller Google bruger standard authorization-code-flow med PKCE, knyttet til den browser, der startede den. Vi modtager din e-mailadresse, dit navn og din konto-ID hos den tjeneste — intet andet. Vi gemmer ikke GitHub- eller Google-adgangstokens, og vi kan ikke læse dine repositories, e-mails eller filer. En GitHub- eller Google-konto tilknyttes en eksisterende Brethof-konto kun, når den tjeneste har bekræftet e-mailadressen og vi også har, eller når kontoen endnu ikke har en adgangskode.

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.

Så det rå samtalearkiv er bevidst uden for deres rækkevidde. Ingen agent kan slette en enkelt besked. Ingen agent kan overhovedet røre de sidste tre måneder. Ældre historik kan kun fjernes samlet, pr. projekt. At slette et helt projekt – den eneste handling, der når hele arkivet – er ikke tilgængelig for agenter på noget niveau; det sker i kontopanellet, hvor et menneske taster projektnavnet.

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

Din hukommelse er én container pr. kunde – sin egen database, sit eget filsystem, sin egen Linux-bruger, intet delt. Hvis du vælger den lokale form, kører containeren på din maskine: din hukommelse gemmes hos dig, og vi gemmer ingen del af den. Det, der passerer vores hub – vores sikre beregningsinstans i Zürich, Schweiz – er det indhold, der behandles: hver udveksling samt de dele af hukommelsen, din container sender, når en vurdering er nødvendig, eller en sessionsoversigt skal sammensættes. Afsnit 4 i Privatlivspolitikken angiver dem præcist. Intet af det gemmes.

Hvilken software der er på din maskine

Containeren indeholder din hukommelse, søgningen i den og mekanismerne, der holder begge korrekte. Den indeholder ingen prompt, ingen adgang til nogen AI-model og ingen indstilling, der peger den mod en. Der er intet i den, som kan vurdere din hukommelse, og intet at konfigurere, der kunne få den til at forsøge. Enhver vurdering anmodes fra vores hub over en forbindelse, din container åbner udad og autentificerer – vi ringer aldrig ind.

Den form er det, der gør trafikken reviderbar, og du er ment til at revidere den: udvekslinger går op, delene ovenfor går op, kommandoer og rækker kommer ned. Klienten er source-available – læs hver eneste linje af den.

Én ting forbliver helt på din side: søgning i din egen hukommelse – registreringerne, hele historikken og dens daterede beslutningslinjer – kører som en almindelig læsning mod dine egne tabeller, inde i din egen container. Det virker, når vores hub er utilgængelig, og sender intet til bedømmelse.

I den hostede form krypteres trafikken under overførsel med TLS, og i hvile er hele containerens filsystem — hver samtale, hver post, selve databasen — krypteret med en nøgle, der er afledt af en adgangskode, som kun du kender. Vi ser den aldrig og gemmer den aldrig: Den passerer, når din session starter, låser din hukommelse op, og hukommelsen låser sig selv igen, efter du har forladt den. En låst container er krypteret tekst for alle, også os — en stjålet disk, et lækket image eller en udfaset disk er støj, og det samme gælder vores egen root-adgang, mens du er væk.

Sletning er kryptografisk

At udslette dig er ikke et håbefuldt sweep gennem lageret: din krypterede container ødelægges som helhed — og da sletning af krypteret tekst ikke kræver en nøgle, virker det, selv hvis du har glemt din adgangskode. De tilbageværende sikkerhedskopier er ulæselige uden den og slettes, efterhånden som backuprækken roterer, senest inden for 30 dage. Der er ingen kopi, vi kan hente frem igen.

Hvad krypteringen ikke dækker

Ærlige begrænsninger. Kryptering i hvile er præcis det — i hvile: mens din hukommelse er låst op til en session, arbejder containeren nødvendigvis med dine data i klartekst for at betjene dine søgninger, så "vi ser aldrig dine data" er vores politik og vores adgangskontroller, ikke en matematisk umulighed — den matematiske garanti får du, hver gang containeren er låst. Vi vil hellere fortælle dig, hvor grænsen går, end lade dig antage, at der ikke er nogen.

Sikkerhedskopier af hostede containere er træk af selve det krypterede filsystem — krypteret tekst, før det forlader maskinen, ulæseligt uden din adgangskode — opbevaret i en kort rullende række af daglige og ugentlige kopier i Tyskland. Når en konto slettes, slettes dens sikkerhedskopier med den, og eventuelle tilbageværende kopier ryddes inden for 30 dage.

Hostet hukommelse gemmes, indekseres og gennemsøges helt inden for EU — vores servere og sikkerhedskopier er i Tyskland. Søge-embeddings beregnes på vores egne maskiner og forlader dem aldrig. Lokal hukommelse når aldrig noget af dette: den ligger på din disk, under den beskyttelse, du giver din disk.

Den eneste undtagelse er AI-kuration. Hvert afsnit, der kureres, behandles på vores sikre beregningsinstans i Zürich, Schweiz — et land, som EU anerkender som ydende et tilstrækkeligt niveau af databeskyttelse — og derfra sendes ét enkelt modelkald til Ollama, som hoster denne model i USA og Europa, hvor det behandles og returneres. Ollamas offentliggjorte vilkår angiver, at inddata og uddata behandles forbigående og aldrig bruges til at træne modeller — det er deres forpligtelse, i deres egne vilkår, og vi angiver det som deres, ikke som et løfte fra os. Intet andet forlader EU. Hvis du også har brug for, at kurationen aldrig forlader EU, er det muligt på en dedikeret installation — spørg os. Hver underprocessor, med formål og placering, er opført i Privatlivspolitikken.

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 hello@Brethof.ai. 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.