Säkerhet

En databas per kund

Ditt minne är inte en rad i en delad tabell med en kundkolumn. Varje kund får sitt eget. egen databas. Det finns inga delade tabeller och inga kundöverskridande frågor som kan bli fel, eftersom gränsen är själva databasen snarare än ett filter som någon måste komma ihåg att skriva.

Den gränsen testas utifrån vid varje utgivning: två verkliga konton, och varje dörr som returnerar data kontrolleras för att bekräfta att ingen kan se den andra. En utgivning skickas inte ut om det inte passerar.

Nycklar, och vem som kan använda dem

Vi kan inte visa dig din egen nyckel.

API-nycklar visas för dig exakt en gång, vid skapandet. Det vi lagrar är en SHA-256-hash – så en kopia av vår databas ger ingen en fungerande nyckel, och varken vi eller en angripare kan läsa ut din. Att återkalla en nyckel träder i kraft i tjänsten inom ungefär en minut, och omedelbart på den maskin som betjänar ditt minne.

Nycklar kan begränsas

En nyckel behöver inte vara allsmäktig. Nycklar kan vara avgränsad per projekt — Läs- och skrivrättigheter, endast läsning eller helt osynlig – vilket är den rätta formen för en entreprenör, ett CI-jobb eller en agent med ett enda syfte som inte har med resten av ditt arbete att göra. En nyckel med korrupta eller oläsbara omfattningar nekas allt istället för att beviljas allt.

Tvåfaktorsautentisering

Ditt konto kan kräva en andra faktor vid inloggning, och när du aktiverar den tillämpas den vid varje inloggning — efter ett lösenord och efter GitHub eller Google likaså — inte bara visas som en inställning.

Att skapa en API-nyckel kräver en skyddad inloggning: tvåfaktorsautentisering på ditt konto, eller en inloggning via GitHub eller Google. Ett lösenord ensamt skapar aldrig en nyckel — inte ens på ett konto som också har GitHub eller Google kopplat, eftersom det som räknas är hur du loggade in den här gången.

Varje destruktiv åtgärd — att radera ett projekt, redigera historiken, radera kontot, återställa en säkerhetskopia — frågar igen vem du är: ditt lösenord om du har ett, och din tvåfaktorskod; utan tvåfaktor, en GitHub- eller Google-inloggning från de senaste tio minuterna. Att exportera dina data kräver det aldrig.

Logga in med GitHub eller Google

Inloggning via GitHub eller Google använder det vanliga auktoriseringskod-flödet med PKCE, knutet till webbläsaren som startade det. Vi tar emot din e-postadress, ditt namn och ditt konto-ID hos den tjänsten — inget annat. Vi sparar ingen GitHub- eller Google-åtkomsttoken, och vi kan inte läsa dina arkiv, din e-post eller dina filer. Ett GitHub- eller Google-konto ansluts till ett befintligt Brethof-konto endast när den tjänsten har verifierat e-postadressen och vi också har gjort det, eller när kontot ännu inte har något lösenord.

Skydd mot dina egna agenter

Detta är den del som de flesta tjänster inte tänker på. Ditt minne hanteras kontinuerligt av AI-agenter – och en agent kan göra ett misstag, få en illvillig instruktion gömd i innehåll den ombads läsa, eller radera fel sak timmar innan en människa märker det.

Så det råa konversationsarkivet är medvetet utanför deras räckhåll. Ingen agent kan ta bort ett enda meddelande. Ingen agent kan röra de senaste tre månaderna överhuvudtaget. Äldre historik kan endast tas bort i bulk, per projekt. Att radera ett helt projekt – den enda åtgärd som når arkivet i sin helhet – är inte tillgängligt för agenter på någon nivå; det sker i kontopanelen, där en människa skriver in projektnamnet.

Anledningen till att detta är viktigt är enkel: kuraterat minne är härlett, och arkivet är original. Allt som en dålig redigering förlorar kan återbyggas från historien. Ingenting kan återbygga historien.

Kryptering, säkerhetskopior och var dina data finns

Ditt minne är en container per kund – egen databas, eget filsystem, egen Linux-användare, inget delat. Om du väljer den lokala formen körs containern på din maskin: ditt minne lagras hos dig och vi lagrar inget av det. Det som passerar vår hubb – vår säkra beräkningsinstans i Zürich, Schweiz – är innehållet som bearbetas: varje utbyte och de delar av minnet som din container skickar när en bedömning behövs eller en sessionsammanfattning ska komponeras. Avsnitt 4 i Integritetspolicyn listar dem exakt. Inget av detta sparas.

Vad programvaran på din maskin är

Containern innehåller ditt minne, sökningen i det och mekanismerna som håller båda korrekta. Den innehåller ingen prompt, ingen åtkomst till någon AI-modell och ingen inställning som pekar den mot en sådan. Det finns inget i den som kan bedöma ditt minne, och inget att konfigurera som skulle låta den försöka. Varje bedömning begärs från vår hubb över en anslutning som din container öppnar utåt och autentiserar – vi ringer aldrig in.

Den formen är det som gör trafiken granskningsbar, och du förväntas granska den: utbyten går upp, delarna ovan går upp, kommandon och rader kommer tillbaka ner. Klienten är source-available – läs varje rad i den.

En sak sker helt på din sida: att söka i ditt eget minne – posterna, hela historiken och dess daterade beslutsrader – körs som en enkel läsning mot dina egna tabeller, inuti din egen container. Det fungerar när vår hubb är onåbar och skickar inget för bedömning.

På den värdbaserade varianten krypteras trafiken under överföring med TLS, och i vila är hela din behållares filsystem – varje konversation, varje post, själva databasen – krypterat med en nyckel som härleds från en lösenfras som bara du känner till. Vi ser den aldrig och lagrar den aldrig: den överförs när din session startar, låser upp ditt minne, och minnet låser sig självt igen efter att du har gått därifrån. En låst behållare är chiffertext för alla, inklusive oss – en stulen disk, en läckt image eller en utrangerad enhet är bara brus, och samma sak gäller vår egen root-åtkomst medan du är borta.

Radering är kryptografisk

Att radera dig är inte ett hoppfullt svep genom lagringen: din krypterade container förstörs i sin helhet – och eftersom radering av chiffertext inte kräver någon nyckel fungerar detta även om du har glömt din lösenfras. De säkerhetskopior som återstår är oläsbara utan den och raderas när säkerhetskopieringstrappan cyklar, inom högst 30 dagar. Det finns ingen kopia för oss att återställa.

Vad krypteringen inte täcker

Ärliga begränsningar. Kryptering i vila är exakt det – i vila: medan ditt minne är upplåst för en session arbetar containern nödvändigtvis med dina data i klartext för att serva dina sökningar, så "vi tittar aldrig på dina data" är vår policy och våra åtkomstkontroller, inte en matematisk omöjlighet – den matematiska garantin får du närhelst containern är låst. Vi föredrar att tala om var gränsen går än att låta dig anta att det inte finns någon.

Säkerhetskopior av värdbaserade containers är hämtningar av själva det krypterade filsystemet – chiffertext innan det lämnar maskinen, oläsbar utan din lösenfras – som förvaras i en kort rullande trappa av dagliga och veckovisa kopior i Tyskland. När ett konto raderas raderas dess säkerhetskopior tillsammans med det, och alla återstående kopior försvinner inom 30 dagar.

Värdbaserat minne lagras, indexeras och söks helt inom EU – våra servrar och säkerhetskopior finns i Tyskland. Sökinbäddningar beräknas på våra egna maskiner och lämnar dem aldrig. Lokalt minne når aldrig något av detta: det finns på din disk, under det skydd du ger din disk.

Det enda undantaget är AI-kuration. Varje avsnitt som kurateras bearbetas på vår säkra beräkningsinstans i Zürich, Schweiz – ett land som EU erkänner som erbjuder en tillräcklig nivå av dataskydd – och därifrån skickas ett enda modellanrop till Ollama, som är värd för modellen i USA och Europa, där den bearbetas och returneras. Ollamas publicerade villkor anger att indata och utdata bearbetas tillfälligt och aldrig används för att träna modeller – det är deras åtagande, i deras egna villkor, och vi anger det som deras snarare än som ett löfte från oss. Ingenting annat lämnar EU. Om du behöver att kurationen inte heller lämnar EU finns det tillgängligt i en dedikerad distribution – fråga oss. Varje underleverantör, med syfte och plats, listas i Integritetspolicyn.

Hur vi arbetar

Minsta behörighet, som standard

Tjänsten körs som en icke-privilegierad användare i sin behållare, aldrig som root. Dess databasroll är inte en superanvändare och kan inte läsa filer från värddatorn. Detta verifieras automatiskt före varje utgivning snarare än antas.

Interna slutpunkter är låsta vid kanten

De slutpunkter som etablerar konton och validerar nycklar är endast nåbara av vår egen kontrollplan, autentiserade vid nätverkskanten innan en begäran ens anländer, och igen med en delad hemlighet bakom. Två lås, inte ett.

Misslyckas stängt

När något saknas eller är oläsbart vägrar tjänsten istället för att gissa. En icke verifierbar nyckel avvisas. Korrupta behörigheter ger ingenting. En saknad webhook-signeringshemlighet avvisar varje händelse istället för att lita på det som anländer. Detta är en avsiktlig hållning: felmoden för en minnestjänst bör vara "inget svar", aldrig "fel kunds svar".

Varje release är verifierad utifrån

Innan någon version släpps går en automatisk kontroll genom hela produkten från ett helt nytt konto via en riktig nätverksanslutning: registrering, utfärdande och återkallande av nycklar, lagring och återkallande av minne, isolering mellan två aktiva konton, dataexport och fullständig radering. Antingen klarar den allt eller så sker ingen release.

Rapportera ett säkerhetsproblem

Om du tror att du har hittat en sårbarhet, vänligen berätta för oss innan du berättar för någon annan, och vi kommer att samarbeta med dig. Kontaktuppgifter finns publicerade på /.well-known/security.txt eller skriv till hello@Brethof.ai. Vi hotar inte forskare som rapporterar i god tro.

Djupare krav – ett avtal om databehandling, en dedikerad distribution i en region du väljer, eller att hålla kuratering inom EU – är saker vi hanterar direkt. Fråga.