Sicherheit

Eine Datenbank pro Kunde

Ihre Erinnerung ist keine Zeile in einer gemeinsamen Tabelle mit einer Kundenspalte. Jeder Kunde erhält seine eigene. eigene Datenbank. Es gibt keine gemeinsamen Tabellen und keine kundenübergreifenden Abfragen, die falsch ausgeführt werden könnten, denn die Grenze ist die Datenbank selbst und nicht ein Filter, an den sich jemand erinnern muss.

Diese Grenze wird bei jeder Veröffentlichung von außen getestet: Zwei echte Konten sowie jede Tür, die Daten zurückgibt, werden überprüft, um sicherzustellen, dass keiner den anderen sehen kann. Eine Veröffentlichung wird nur dann freigegeben, wenn dies gelingt.

Schlüssel und wer sie verwenden kann

Wir können Ihnen Ihren eigenen Schlüssel nicht zeigen.

API-Schlüssel werden Ihnen genau einmal angezeigt, bei der Erstellung. Was wir speichern, ist ein SHA-256-Hash – eine Kopie unserer Datenbank liefert also niemandem einen funktionsfähigen Schlüssel, und weder wir noch ein Angreifer können Ihren Schlüssel wieder auslesen. Das Widerrufen eines Schlüssels wirkt sich innerhalb von etwa einer Minute auf den Dienst aus und sofort auf der Maschine, die Ihr Gedächtnis bereitstellt.

Die Schlüssel können eingegrenzt werden.

Ein Schlüssel muss nicht allmächtig sein. Schlüssel können pro Projekt begrenzt — Lesen und Schreiben, nur Lesen oder völlig unsichtbar – das ist die richtige Form für einen Auftragnehmer, einen CI-Job oder einen Einzweck-Agenten, der nichts mit dem Rest Ihrer Arbeit zu tun haben sollte. Ein Schlüssel mit beschädigten oder unlesbaren Berechtigungen wird alles verweigert, anstatt alles zu gewähren.

Zwei-Faktor-Authentifizierung

Ihr Konto kann einen zweiten Faktor beim Login verlangen, und wenn Sie ihn aktivieren, wird er bei jeder Anmeldung erzwungen — nach einem Passwort und nach GitHub oder Google gleichermaßen — und nicht lediglich als Einstellung angezeigt.

Das Erstellen eines API-Schlüssels erfordert eine geschützte Anmeldung: Zwei-Faktor-Authentifizierung auf deinem Konto oder eine Anmeldung über GitHub oder Google. Ein Passwort allein erstellt niemals einen Schlüssel — nicht einmal auf einem Konto, das auch mit GitHub oder Google verbunden ist, denn entscheidend ist, wie du dich dieses Mal angemeldet hast.

Jede destruktive Aktion — das Löschen eines Projekts, das Schwärzen der Historie, das Löschen des Kontos, das Wiederherstellen eines Backups — fragt erneut, wer Sie sind: Ihr Passwort, falls Sie eines haben, und Ihren Zwei-Faktor-Code; ohne Zwei-Faktor eine GitHub- oder Google-Anmeldung aus den letzten zehn Minuten. Beim Exportieren Ihrer Daten wird dies nie benötigt.

Mit GitHub oder Google anmelden

Die Anmeldung über GitHub oder Google nutzt den Standard-Autorisierungscode-Flow mit PKCE, gebunden an den Browser, der sie gestartet hat. Wir erhalten Ihre E-Mail-Adresse, Ihren Namen und Ihre Konto-ID bei diesem Dienst — nichts weiter. Wir speichern kein GitHub- oder Google-Access-Token und können Ihre Repositories, E-Mails oder Dateien nicht lesen. Ein GitHub- oder Google-Konto verknüpft sich nur dann mit einem bestehenden Brethof-Konto, wenn dieser Dienst die E-Mail-Adresse verifiziert hat und wir ebenfalls, oder wenn das Konto noch kein Passwort hat.

Schutz vor eigenen Agenten

Dies ist der Aspekt, den die meisten Dienste nicht berücksichtigen. Ihr Gedächtnis wird kontinuierlich von KI-Agenten verarbeitet – und ein Agent kann einen Fehler machen, eine bösartige Anweisung erhalten, die in Inhalten versteckt ist, die er lesen soll, oder etwas Falsches löschen, Stunden bevor ein Mensch es bemerkt.

Daher ist das unverarbeitete Gesprächsarchiv absichtlich außerhalb ihrer Reichweite. Kein Agent kann eine einzelne Nachricht löschen. Kein Agent darf die letzten drei Monate überhaupt berühren. Ältere Historie kann nur gesammelt, pro Projekt, entfernt werden. Die Löschung eines gesamten Projekts – die einzige Aktion, die das Archiv vollständig erfasst – steht Agenten auf keiner Stufe zur Verfügung; dies geschieht im Kontopanel, wo ein Mensch den Projektnamen eingibt.

Der Grund, warum das wichtig ist, ist einfach: Die kuratierte Erinnerung ist abgeleitet, während das Archiv die Quelle ist. Alles, was durch eine schlechte Bearbeitung verloren geht, kann aus der Geschichte wiederhergestellt werden. Nichts jedoch kann die Geschichte selbst wiederherstellen.

Verschlüsselung, Backups und wo Ihre Daten leben

Ihr Gedächtnis liegt in einem eigenen Container pro Kunde – mit eigener Datenbank, eigenem Dateisystem und eigenem Linux-Benutzer; nichts wird geteilt. Wenn Sie die lokale Variante wählen, läuft dieser Container auf Ihrem Rechner: Ihr Gedächtnis wird bei Ihnen gespeichert, und wir speichern nichts davon. Was durch unseren Hub – unsere sichere Recheninstanz in Zürich, Schweiz – übertragen wird, ist der zu verarbeitende Inhalt: jeder Austausch sowie die Gedächtnisteile, die Ihr Container sendet, wenn eine Beurteilung erforderlich ist oder ein Sitzungsüberblick erstellt wird. Abschnitt 4 der Datenschutzerklärung listet diese genau auf. Nichts davon wird aufbewahrt.

Was die Software auf Ihrem Computer ist

Der Container enthält Ihr Gedächtnis, die Suche darin sowie die Mechanismen, die beides korrekt halten. Er enthält keinen Prompt, keinen Zugriff auf irgendein KI-Modell und keine Einstellung, die ihn auf eines verweisen würde. Es gibt nichts darin, das Ihr Gedächtnis beurteilen könnte, und nichts zu konfigurieren, was es versuchen ließe. Jede Beurteilung wird angefordert von unserem Hub über eine Verbindung, die Ihr Container nach außen herstellt und authentifiziert – wir wählen uns niemals ein.

Diese Struktur macht den Datenverkehr überprüfbar, und Sie sollen ihn auch überprüfen: Austausche gehen hinauf, die oben genannten Teile gehen hinauf, Befehle und Zeilen kommen zurück. Der Client ist source-available – lesen Sie jede Zeile davon.

Eines bleibt vollständig auf Ihrer Seite: die Suche in Ihrer eigenen Erinnerung – die Aufzeichnungen, die gesamte Historie und ihre datierten Entscheidungszeilen – läuft als einfacher Lesevorgang gegen Ihre eigenen Tabellen, innerhalb Ihres eigenen Containers. Sie funktioniert, wenn unser Hub nicht erreichbar ist, und sendet nichts zur Beurteilung.

Bei der gehosteten Variante wird der Datenverkehr bei der Übertragung mit TLS verschlüsselt, und im Ruhezustand ist das gesamte Dateisystem Ihres Containers – jedes Gespräch, jeder Eintrag, die Datenbank selbst – mit einem Schlüssel verschlüsselt, der aus einer Passphrase abgeleitet wird, die nur Sie besitzen. Wir sehen sie nie und speichern sie nie: Sie läuft beim Start Ihrer Sitzung durch, schaltet Ihr Gedächtnis frei, und das Gedächtnis sperrt sich wieder, sobald Sie sich entfernen. Ein gesperrter Container ist für alle Chiffretext, auch für uns – eine gestohlene Festplatte, ein durchgestrichenes Image oder ein ausgemustertes Laufwerk sind Rauschen, ebenso unser eigener Root-Zugriff, solange Sie weg sind.

Löschung ist kryptografisch

Sie zu löschen ist keine hoffnungsvolle Durchsuchung des Speichers: Ihr verschlüsselter Container wird als Ganzes zerstört – und da das Löschen von Chiffretext keinen Schlüssel benötigt, funktioniert das auch, wenn Sie Ihre Passphrase vergessen haben. Verbleibende Backups sind ohne sie unlesbar und werden gelöscht, sobald das Backup-Schema durchläuft, spätestens innerhalb von 30 Tagen. Es gibt keine Kopie, die wir zurückholen könnten.

Was die Verschlüsselung nicht abdeckt

Ehrliche Grenzen. Verschlüsselung im Ruhezustand ist genau das – im Ruhezustand: Solange Ihr Gedächtnis für eine Sitzung entsperrt ist, muss der Container notwendigerweise mit Ihren Daten im Klartext arbeiten, um Ihre Suchanfragen zu bedienen; „wir sehen Ihre Daten nie an“ ist daher unsere Richtlinie und unsere Zugriffskontrolle, keine mathematische Unmöglichkeit – die mathematische Garantie erhalten Sie, wann immer der Container gesperrt ist. Wir sagen Ihnen lieber, wo die Grenze liegt, statt Sie anzunehmen, es gäbe keine.

Backups gehosteter Container sind Züge des verschlüsselten Dateisystems selbst – Chiffretext, bevor sie den Rechner verlassen, ohne Ihre Passphrase unlesbar –, aufbewahrt in einem kurzen rollierenden Schema täglicher und wöchentlicher Kopien in Deutschland. Wird ein Konto gelöscht, werden seine Backups mitgelöscht, und verbleibende Kopien werden innerhalb von 30 Tagen entfernt.

Gehostetes Gedächtnis wird vollständig innerhalb der EU gespeichert, indiziert und durchsucht – unsere Server und Backups stehen in Deutschland. Such-Embeddings werden auf unseren eigenen Maschinen berechnet und verlassen diese nie. Lokales Gedächtnis erreicht nichts davon: Es liegt auf Ihrer Festplatte, unter dem Schutz, den Sie Ihrer Festplatte geben.

Die einzige Ausnahme ist die KI-Kuration. Jeder zu kurierende Abschnitt wird auf unserer sicheren Recheninstanz in Zürich, Schweiz verarbeitet – einem Land, das die EU als Anbieter eines angemessenen Datenschutzniveaus anerkennt – und von dort wird ein einziger Modellaufruf an Ollama gesendet, das dieses Modell in den Vereinigten Staaten und Europa hostet, dort verarbeitet und zurückgesendet. Ollamas veröffentlichte Bedingungen besagen, dass Eingaben und Ausgaben nur vorübergehend verarbeitet und niemals zum Training von Modellen verwendet werden – das ist deren Zusicherung in deren eigenen Bedingungen, und wir geben sie als deren wieder, nicht als unser Versprechen. Nichts anderes verlässt die EU. Falls auch die Kuration niemals die EU verlassen soll, ist das bei einer dedizierten Bereitstellung möglich – fragen Sie. Jeder Unterprozessor mit Zweck und Standort ist in der Datenschutzerklärung aufgeführt.

Wie wir arbeiten

Mindestprivilegien standardmäßig

Der Dienst läuft als nicht privilegierter Benutzer innerhalb seines Containers – niemals als Root. Seine Datenbankrolle ist keine Superuser-Rolle und kann keine Dateien vom Host lesen. Dies wird vor jeder Veröffentlichung automatisch überprüft, anstatt einfach vorausgesetzt zu werden.

Interne Endpunkte sind am Rand gesperrt.

Die Endpunkte, die Konten erstellen und Schlüssel validieren, sind nur über unser eigenes Control Plane erreichbar – sie werden an der Netzwerkgrenze bereits vor Erhalt einer Anfrage authentifiziert, und anschließend noch einmal mithilfe eines gemeinsamen Geheimnisses. Zwei Sicherheitsmechanismen, nicht einer.

Fail closed

Wenn etwas fehlt oder unleserlich ist, lehnt der Dienst ab, anstatt zu raten. Ein nicht verifizierbarer Schlüssel wird abgelehnt. Beschädigte Berechtigungen gewähren nichts. Ein fehlendes Webhook-Signaturgeheimnis lehnt jedes Ereignis ab, anstatt zu vertrauen, was ankommt. Dies ist eine bewusste Haltung: Der Fehlermodus eines Speicherdienstes sollte „keine Antwort“ sein – niemals „die Antwort des falschen Kunden“.

Jede Veröffentlichung wird von außen überprüft

Vor jeder Veröffentlichung prüft ein automatisiertes Tor das gesamte Produkt von einem brandneuen Konto aus über eine echte Netzwerkverbindung: Anmeldung, Ausstellung und Widerruf von Schlüsseln, Speichern und Abrufen von Erinnerungen, Isolierung zwischen zwei aktiven Konten, Datencxport und vollständige Löschung. Entweder besteht es vollständig oder die Veröffentlichung findet nicht statt.

Ein Sicherheitsproblem melden

Falls Sie glauben, eine Schwachstelle entdeckt zu haben, teilen Sie es uns bitte mit, bevor Sie jemand anderem davon erzählen – dann werden wir mit Ihnen zusammenarbeiten. Die Kontaktdaten finden Sie unter /.well-known/security.txt oder schreiben Sie an hello@Brethof.ai. Wir bedrohen keine Forscher, die in gutem Glauben berichten.

Höhere Anforderungen – ein Datenverarbeitungsvertrag, eine dedizierte Bereitstellung in einer Region Ihrer Wahl oder die Durchführung der Kuratierung innerhalb der EU – sind Dinge, die wir direkt übernehmen. Fragen Sie uns.