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 een tweede factor vereisen bij het inloggen, en wanneer u dit inschakelt wordt het afgedwongen bij elke aanmelding — na een wachtwoord en na GitHub of Google — en niet slechts weergegeven als instelling.

Het aanmaken van een API-sleutel vereist een beveiligde aanmelding: tweefactorauthenticatie op je account, of een aanmelding via GitHub of Google. Een wachtwoord alleen maakt nooit een sleutel aan — niet eens op een account dat ook GitHub of Google gekoppeld heeft, want wat telt is hoe je deze keer bent ingelogd.

Elke destructieve handeling — een project verwijderen, geschiedenis redigeren, het account verwijderen, een back-up herstellen — vraagt opnieuw wie je bent: je wachtwoord als je er een hebt, en je tweefactorcode; zonder tweefactor, een GitHub- of Google-aanmelding van de laatste tien minuten. Het exporteren van je gegevens heeft dit nooit nodig.

Inloggen met GitHub of Google

Aanmelden via GitHub of Google gebruikt de standaard authorization-code flow met PKCE, gekoppeld aan de browser die de aanmelding startte. Wij ontvangen uw e-mailadres, uw naam en uw account-ID bij die dienst — niets anders. We bewaren geen GitHub- of Google-toegangstoken, en we kunnen uw repositories, e-mail of bestanden niet lezen. Een GitHub- of Google-account wordt alleen gekoppeld aan een bestaand Brethof-account als die dienst het e-mailadres heeft geverifieerd en wij dat ook hebben gedaan, of als het account nog geen wachtwoord heeft.

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 ruwe gespreksarchief ligt opzettelijk buiten hun bereik. Geen enkele agent kan één bericht verwijderen. Geen enkele agent mag de afgelopen drie maanden überhaupt aanraken. Oudere geschiedenis kan alleen in bulk worden verwijderd, per project. Het verwijderen van een heel project – de enige actie die het archief volledig bereikt – is voor agenten op geen enkel niveau 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

Uw geheugen is één container per klant — met eigen database, eigen bestandssysteem en eigen Linux-gebruiker; er wordt niets gedeeld. Als u voor de lokale vorm kiest, draait die container op uw machine: uw geheugen wordt bij u opgeslagen en wij slaan er niets van op. Wat via onze hub gaat — onze beveiligde rekenomgeving in Zürich, Zwitserland — is de inhoud die wordt verwerkt: elke uitwisseling en de geheugenstukken die uw container stuurt wanneer een beoordeling nodig is of een sessiebrief wordt samengesteld. Sectie 4 van de privacyverklaring somt ze precies op. Niets daarvan wordt bewaard.

Wat de software op uw machine is

De container bevat je geheugen, het zoeken daarin en de mechanismen die beide correct houden. Hij bevat geen prompt, geen toegang tot een AI-model en geen instelling die hem op een model richt. Er zit niets in dat je geheugen kan beoordelen, en er is niets in te stellen dat dat mogelijk zou maken. Elke beoordeling wordt opgevraagd bij onze hub, over een verbinding die je container uitgaand opent en authenticeert — wij bellen nooit zelf in.

Die vorm maakt het verkeer controleerbaar, en dat is precies de bedoeling: uitwisselingen gaan omhoog, de stukken hierboven gaan omhoog, commando's en rijen komen terug omlaag. De client is source-available — lees elke regel ervan.

Eén ding blijft volledig aan jouw kant: het doorzoeken van je eigen geheugen – de records, de hele geschiedenis en de gedateerde beslissingsregels – vindt plaats als een eenvoudige leesactie op je eigen tabellen, binnen je eigen container. Het werkt zelfs wanneer onze hub onbereikbaar is en stuurt niets ter beoordeling.

Op de gehoste vorm wordt verkeer tijdens transport versleuteld met TLS, en in rust is het hele bestandssysteem van uw container — elk gesprek, elk record, de database zelf — versleuteld met een sleutel die is afgeleid van een wachtzin die alleen u kent. Wij zien hem nooit en slaan hem nooit op: hij passeert zodra uw sessie start, ontgrendelt uw geheugen, en het geheugen vergrendelt zichzelf weer nadat u weggaat. Een vergrendelde container is voor iedereen cijfertekst, ook voor ons — een gestolen schijf, een gelekte image of een buiten gebruik gestelde drive is ruis, en dat geldt ook voor onze eigen root-toegang terwijl u weg bent.

Verwijdering is cryptografisch

U wissen is geen hoopvolle veeg door de opslag: uw versleutelde container wordt in zijn geheel vernietigd — en omdat het verwijderen van cijfertekst geen sleutel vereist, werkt dit zelfs als u uw wachtzin bent vergeten. Resterende back-ups zijn zonder die sleutel onleesbaar en worden gewist naarmate de back-upreeks doorloopt, uiterlijk binnen 30 dagen. Er is geen kopie die wij kunnen terughalen.

Wat de versleuteling niet dekt

Eerlijke beperkingen. Versleuteling in rust is precies dat — in rust: terwijl uw geheugen voor een sessie is ontgrendeld, werkt de container noodzakelijkerwijs met uw gegevens in leesbare vorm om uw zoekopdrachten te bedienen, dus "wij kijken nooit naar uw gegevens" is ons beleid en onze toegangscontrole, geen wiskundige onmogelijkheid — de wiskundige garantie krijgt u zodra de container is vergrendeld. Wij vertellen u liever waar de grens ligt dan dat wij u laten aannemen dat die er niet is.

Back-ups van gehoste containers zijn pulls van het versleutelde bestandsysteem zelf — cijfertekst voordat ze de machine verlaten, onleesbaar zonder uw wachtzin — bewaard in een korte rollenreeks van dagelijkse en wekelijkse kopieën in Duitsland. Wanneer een account wordt verwijderd, worden de back-ups ermee verwijderd, en resterende kopieën worden binnen 30 dagen gewist.

Gehost geheugen wordt volledig binnen de EU opgeslagen, geïndexeerd en doorzocht — onze servers en back-ups staan in Duitsland. Zoek-embeddings worden berekend op onze eigen machines en verlaten deze nooit. Lokaal geheugen bereikt hiervan niets: het staat op uw schijf, onder de bescherming die u uw schijf geeft.

De enige uitzondering is AI-curatie. Elk passage dat wordt gecurateerd, wordt verwerkt op onze secure-compute-instantie in Zürich, Zwitserland — een land dat door de EU wordt erkend als een adequaat beschermingsniveau biedend — en van daaruit wordt één modelpass gestuurd naar Ollama, dat dit model host in de Verenigde Staten en Europa, waar het wordt verwerkt en teruggestuurd. Volgens de gepubliceerde voorwaarden van Ollama worden invoer en uitvoer tijdelijk verwerkt en nooit gebruikt om modellen te trainen — dat is hun toezegging, in hun eigen voorwaarden, en wij geven het weer als die van hen, niet als een belofte van onszelf. Niets anders verlaat de EU. Als u wilt dat ook curatie nooit de EU verlaat, is dat beschikbaar op een dedicated deployment — vraag ernaar. Elke subverwerker, met doel en locatie, staat vermeld in de Privacy Policy.

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