Bezpieczeństwo

Jedna baza danych na klienta

Twoja pamięć to nie wiersz w wspólnej tabeli z kolumną klienta. Każdy klient ma swoją własną. własna baza danych. Nie ma wspólnych tabel ani zapytań między klientami, które mogłyby pójść nie tak, ponieważ granicą jest sama baza danych, a nie filtr, o którym ktoś musi pamiętać, aby go zastosować.

Ta granica jest sprawdzana z zewnątrz przy każdym wydaniu: dwa rzeczywiste konta oraz każde wejście, które zwraca dane, są weryfikowane, aby upewnić się, że żadne z nich nie może widzieć drugiego. Wydanie nie trafia do użytkowników, dopóki to nie zostanie sprawdzone.

Klucze i kto może nimi korzystać

Nie możemy pokazać Ci Twojego własnego klucza.

Klucze API są pokazywane dokładnie raz, przy tworzeniu. Przechowujemy jedynie hash SHA-256 — więc kopia naszej bazy danych nie daje nikomu działającego klucza, a ani my, ani atakujący nie możemy odczytać Twojego klucza. Odwołanie klucza zaczyna obowiązywać w usłudze w ciągu około minuty, a natychmiast na maszynie obsługującej Twoją pamięć.

Klucze można zawęzić

Klucz nie musi być wszechmocny. Klucze mogą być dostosowane do projektu — Czytanie i zapisywanie, tylko do odczytu lub całkowita niewidzialność – to odpowiednia forma dla wykonawcy, zadania typu CI lub agenta o jednoznacznym przeznaczeniu, który nie powinien mieć dostępu do reszty twojej pracy. Klucz z uszkodzonymi lub nieczytelnymi zakresami dostępu odrzuca wszelkie próby dostępu zamiast je zatwierdzać.

Uwierzytelnianie dwuskładnikowe

Twoje konto może wymagać drugiego czynnika przy logowaniu, a gdy go włączysz, jest on wymuszany przy każdym logowaniu — po haśle oraz po GitHub i Google alike — a nie jedynie wyświetlany jako ustawienie.

Utworzenie klucza API wymaga chronionego logowania: uwierzytelniania dwuskładnikowego na Twoim koncie albo logowania przez GitHub lub Google. Samo hasło nigdy nie tworzy klucza — nawet na koncie, które ma też połączone GitHub lub Google, ponieważ liczy się to, jak zalogowałeś się tym razem.

Każda destrukcyjna czynność — usunięcie projektu, redakcja historii, usunięcie konta, przywrócenie kopii zapasowej — ponownie pyta, kim jesteś: o Twoje hasło, jeśli je masz, oraz Twój kod dwuskładnikowy; bez dwuskładnikowego uwierzytelniania — logowanie GitHub lub Google z ostatnich dziesięciu minut. Eksportowanie danych nigdy tego nie wymaga.

Zaloguj się przez GitHub lub Google

Logowanie przez GitHub lub Google korzysta ze standardowego przepływu kodu autoryzacji z PKCE, powiązanego z przeglądarką, która go rozpoczęła. Otrzymujemy Twój adres e-mail, imię i nazwisko oraz identyfikator konta w tej usłudze — nic więcej. Nie przechowujemy tokenów dostępu GitHub ani Google i nie możemy czytać Twoich repozytoriów, poczty ani plików. Konto GitHub lub Google łączy się z istniejącym kontem Brethof tylko wtedy, gdy ta usługa zweryfikowała adres e-mail i my również to zrobiliśmy, albo gdy konto nie ma jeszcze hasła.

Ochrona przed własnymi agentami

To jest ta część, o której większość usług nie myśli. Twoja pamięć jest stale przetwarzana przez agentów AI — a agent może popełnić błąd, otrzymać złośliwą instrukcję ukrytą w treści, którą miał przeczytać, lub usunąć niewłaściwą rzecz na kilka godzin przed tym, zanim człowiek to zauważy.

Dlatego surowe archiwum rozmów jest celowo poza ich zasięgiem. Żaden agent nie może usunąć pojedynczej wiadomości. Żaden agent w ogóle nie może dotknąć ostatnich trzech miesięcy. Starszą historię można usuwać tylko hurtowo, w obrębie całego projektu. Usunięcie całego projektu — jedyne działanie sięgające całego archiwum — nie jest dostępne dla agentów na żadnym poziomie; odbywa się w panelu konta, gdzie człowiek wpisuje nazwę projektu.

Powód, dla którego to ma znaczenie, jest prosty: uporządkowana pamięć jest wynikiem pewnych działań, natomiast archiwum stanowi jej źródło. Wszystko, co ginie wskutek błędnej edycji, można odtworzyć na podstawie historii. Nic jednak nie może odtworzyć samej historii.

Szyfrowanie, kopie zapasowe i miejsce przechowywania danych

Twoja pamięć to jeden kontener na klienta – własna baza danych, własny system plików, własny użytkownik Linux, nic nie jest współdzielone. Jeśli wybrałeś wariant lokalny, ten kontener działa na twojej maszynie: twoja pamięć jest przechowywana u ciebie, a my nie przechowujemy jej wcale. Przez nasz hub – naszą instancję bezpiecznych obliczeń w Zurychu w Szwajcarii – przechodzi tylko przetwarzana treść: każda wymiana oraz fragmenty pamięci, które twój kontener wysyła, gdy potrzebna jest ocena lub gdy układane jest streszczenie sesji. Sekcja 4 Polityki prywatności wymienia je dokładnie. Nic z tego nie jest zachowywane.

Czym jest oprogramowanie na twojej maszynie

Kontener przechowuje twoją pamięć, wyszukiwanie w niej oraz mechanizmy, które utrzymują jedno i drugie w porządku. Nie zawiera żadnego promptu, żadnego dostępu do modelu AI ani żadnego ustawienia, które wskazywałoby mu taki model. Nie ma w nim nic, co mogłoby ocenić twoją pamięć, ani nic do skonfigurowania, co by mu to umożliwiło. Każda ocena jest proszona z naszego hubu przez połączenie, które twój kontener otwiera wychodząco i uwierzytelnia – my nigdy nie dzwoniemy do środka.

Właśnie ta struktura czyni ruch audytowalnym, a masz go audytować: wymiany idą w górę, wymienione wyżej elementy idą w górę, polecenia i wiersze wracają w dół. Klient jest source-available – przeczytaj każdą jego linię.

Jedna rzecz pozostaje całkowicie po twojej stronie: przeszukiwanie własnej pamięci — zapisy, cała historia oraz datowane linie decyzji — odbywa się jako zwykły odczyt z twoich własnych tabel, wewnątrz twojego własnego kontenera. Działa to, gdy nasz hub jest nieosiągalny, i nie wysyła nic do oceny.

W wersji hostowanej ruch jest szyfrowany w trakcie transmisji za pomocą TLS, a w spoczynku cały system plików Twojego kontenera — każda rozmowa, każdy rekord, sama baza danych — jest szyfrowany kluczem pochodzącym od hasła, które znasz tylko Ty. Nigdy go nie widzimy i nigdy go nie przechowujemy: przechodzi, gdy zaczyna się Twoja sesja, odblokowuje pamięć, a pamięć blokuje się ponownie, gdy odejdziesz. Zablokowany kontener jest szyfrogramem dla wszystkich, łącznie z nami — skradziony dysk, wyciekły obraz czy wycofany nośnik to szum, podobnie jak nasz własny dostęp root, gdy Cię nie ma.

Usuwanie jest kryptograficzne

Usunięcie Twoich danych to nie nadzieją napędzane przeczesywanie magazynu: Twój zaszyfrowany kontener jest niszczony w całości — a ponieważ usunięcie szyfrogramu nie wymaga klucza, działa to nawet wtedy, gdy zapomniałeś hasła. Pozostałe kopie zapasowe są bez niego nieczytelne i znikają, gdy rotacyjna seria kopii się przewinie, najpóźniej w ciągu 30 dni. Nie ma żadnej kopii, którą moglibyśmy przywrócić.

Czego szyfrowanie nie obejmuje

Uczciwe ograniczenia. Szyfrowanie w spoczynku to dokładnie to — spoczynek: gdy pamięć jest odblokowana na czas sesji, kontener musi pracować na Twoich danych w postaci jawnej, aby obsłużyć wyszukiwanie, więc „nigdy nie patrzymy na Twoje dane" to nasza polityka i nasze kontrole dostępu, a nie matematyczna niemożliwość — gwarancja matematyczna obowiązuje zawsze, gdy kontener jest zablokowany. Wolimy powiedzieć Ci, gdzie leży granica, niż pozwolić Ci zakładać, że jej nie ma.

Kopie zapasowe hostowanych kontenerów to pobrania samego zaszyfrowanego systemu plików — szyfrogram, zanim opuści maszynę, nieczytelny bez Twojego hasła — przechowywane w krótkiej rotacyjnej serii codziennych i tygodniowych kopii w Niemczech. Gdy konto jest usuwane, jego kopie zapasowe są usuwane razem z nim, a pozostałe egzemplarze znikają w ciągu 30 dni.

Pamięć hostowana jest przechowywana, indeksowana i przeszukiwana wyłącznie w UE — nasze serwery i kopie zapasowe są w Niemczech. Wektory wyszukiwania są obliczane na naszych własnych maszynach i nigdy ich nie opuszczają. Pamięć lokalna nie ma z tym nic wspólnego: jest na Twoim dysku, pod ochroną, jaką mu zapewnisz.

Jedynym wyjątkiem jest kuracja AI. Każdy kurowany fragment jest przetwarzany na naszej instancji bezpiecznego obliczania w Zurychu w Szwajcarii — kraju, który UE uznaje za oferujący odpowiedni poziom ochrony danych — a stamtąd pojedynczy przebieg modelu jest wysyłany do Ollama, która hostuje ten model w Stanach Zjednoczonych i Europie, przetwarzany i zwracany. Opublikowane warunki Ollamy stanowią, że dane wejściowe i wyjściowe są przetwarzane przejściowo i nigdy nie są używane do trenowania modeli — to ich zobowiązanie, zapisane w ich własnych warunkach, i przedstawiamy je jako ich, a nie jako naszą obietnicę. Nic innego nie opuszcza UE. Jeśli potrzebujesz, by kuracja również nigdy nie opuszczała UE, jest to dostępne w dedykowanym wdrożeniu — zapytaj. Każdy podprocesor, wraz z celem i lokalizacją, jest wymieniony w Polityce prywatności.

Jak działamy

Najmniejsze uprawnienia, jako standard

Usługa działa jako użytkownik bez uprawnień w swoim kontenerze, nigdy jako root. Jej rola w bazie danych nie jest superużytkownikiem i nie może odczytywać plików z hosta. Te kwestie są automatycznie weryfikowane przed każdym wydaniem, a nie przyjmowane za pewnik.

Wewnętrzne punkty końcowe są zablokowane na krawędzi

Punkty końcowe, które tworzą konta i weryfikują klucze, są dostępne wyłącznie przez naszą własną płaszczyznę sterowania – są autoryzowane na krańcu sieci jeszcze przed nadejściem żądania, a ponownie za pomocą wspólnego sekretu. Dwa zamykania, a nie jedno.

Zamknięcie w razie błędu

Gdy coś brakuje lub jest nieczytelne, usługa odmawia zamiast zgadywać. Niezweryfikowany klucz jest odrzucany. Uszkodzone uprawnienia nie dają niczego. Brak tajnego klucza podpisu webhook odrzuca każde zdarzenie zamiast ufać temu, co przychodzi. To celowe podejście: tryb awaryjny usługi pamięci powinien polegać na „braku odpowiedzi”, nigdy na „odpowiedzi niewłaściwego klienta”.

Każda wersja jest sprawdzana z zewnątrz

Przed wypuszczeniem jakiejkolwiek wersji automatyczna bramka przechodzi przez cały produkt, zaczynając od zupełnie nowego konta, przez rzeczywiste połączenie sieciowe: rejestrację, wydawanie i odwoływanie kluczy, przechowywanie i przywoływanie pamięci, izolację między dwoma aktywnymi kontami, eksport danych i całkowite usunięcie. Albo przechodzi w całości, albo wersja nie zostaje wydana.

Zgłaszanie problemu z bezpieczeństwem

Jeśli uważasz, że odkryłeś wadę bezpieczeństwa, prosimy, powiedz nam o tym, zanim poinformujesz kogokolwiek innego, a my będziemy współpracować z tobą. Dane kontaktowe znajdują się pod adresem /.well-known/security.txt lub napisz hello@Brethof.ai. Nie zagrażamy badaczom, którzy zgłaszają problemy w dobrej wierze.

Bardziej złożone wymagania — umowa o przetwarzanie danych, dedykowane wdrożenie w wybranym regionie lub utrzymanie selekcjonowania w UE — to kwestie, którymi zajmujemy się bezpośrednio. Zapytaj.