Securitate

O bază de date pentru fiecare client

Memoria dumneavoastră nu este un rând într-o tabelă partajată cu o coloană de client. Fiecare client primește a sa propria bază de date. Nu există tabele partajate și nici interogări între clienți care să poată fi greșite, deoarece granița este baza de date în sine, nu un filtru pe care cineva trebuie să-și amintească să-l scrie.

Acea limită este testată din exterior la fiecare lansare: două conturi reale, iar fiecare „ușă” care returnează date este verificată pentru a confirma că niciuna nu poate vedea cealaltă. O lansare nu este trimisă decât dacă aceste teste sunt reușite.

Chei, și cine le poate folosi

Nu vă putem arăta propria cheie

Cheile API vă sunt afișate exact o dată, la creare. Ceea ce stocăm este un hash SHA-256 — deci o copie a bazei noastre de date nu oferă nimănui o cheie funcțională, iar nici noi, nici un atacator nu vă putem citi cheia. Revocarea unei chei intră în vigoare în serviciu în aproximativ un minut și imediat pe mașina care servește memoria dumneavoastră.

Cheile pot fi restrânse

O cheie nu trebuie să fie atotputernică. Cheile pot fi limitat pe proiect — citire și scriere, doar citire sau complet invizibil – care este forma potrivită pentru un contractant, o sarcină CI sau un agent cu un singur scop care nu are nicio treabă să citească restul lucrărilor dumneavoastră. O cheie cu domenii corupte sau necitabile primește refuz la tot, în loc să i se acorde totul.

Autentificare cu doi factori

Contul tău poate solicita un al doilea factor la autentificare, iar atunci când îl activezi, acesta este impus la fiecare conectare — după parolă și după GitHub sau Google deopotrivă — nu doar afișat ca o setare.

Crearea unei chei API necesită o autentificare protejată: autentificare în doi pași pe contul tău, sau o autentificare prin GitHub sau Google. O parolă singură nu creează niciodată o cheie — nici măcar pe un cont care are și GitHub sau Google conectate, pentru că ceea ce contează este modul în care te-ai autentificat de data aceasta.

Fiecare acțiune distructivă — ștergerea unui proiect, redactarea istoricului, ștergerea contului, restaurarea unei copii de rezervă — te întreabă din nou cine ești: parola ta, dacă ai una, și codul tău cu autentificare în doi pași; fără autentificare în doi pași, o conectare GitHub sau Google din ultimele zece minute. Exportarea datelor tale nu are nevoie niciodată de asta.

Conectați-vă cu GitHub sau Google

Autentificarea prin GitHub sau Google folosește fluxul standard cu cod de autorizare și PKCE, legat de browserul care a inițiat-o. Primim adresa ta de email, numele tău și ID-ul contului tău la acel serviciu — nimic altceva. Nu păstrăm niciun token de acces GitHub sau Google și nu putem citi depozitele, poșta sau fișierele tale. Un cont GitHub sau Google se alătură unui cont Brethof existent doar atunci când acel serviciu a verificat adresa de email și noi la fel, sau când contul nu are încă o parolă.

Protecție împotriva propriilor agenți

Acesta este aspectul pe care majoritatea serviciilor nu îl iau în considerare. Memoria dumneavoastră este operată continuu de agenți AI – și un agent poate face o greșeală, poate primi o instrucțiune malicioasă ascunsă în conținutul pe care i s-a cerut să-l citească, sau poate șterge lucrul greșit cu ore înainte ca un om să observe.

Așadar, arhiva brută a conversațiilor este în mod deliberat dincolo de accesul lor. Niciun agent nu poate șterge un singur mesaj. Niciun agent nu poate atinge deloc ultimele trei luni. Istoricul mai vechi poate fi eliminat doar în bloc, pe proiect. Ștergerea unui proiect întreg – singura acțiune care ajunge la arhivă în ansamblu – nu este disponibilă agenților la niciun nivel; ea are loc în panoul contului, unde o persoană tastează numele proiectului.

Motivul pentru care acest lucru contează este simplu: memoria curată este derivată, iar arhiva este originalul. Orice pierdut dintr-o editare defectuoasă poate fi reconstruit din istorie. Nimic nu poate reconstrui istoria.

Criptare, backup-uri și unde locuiesc datele dumneavoastră

Memoria dumneavoastră este un container pentru fiecare client – propria bază de date, propriul sistem de fișiere, propriul utilizator Linux, fără nicio partajare. Dacă alegeți configurația locală, acel container rulează pe mașina dumneavoastră: memoria dumneavoastră este stocată la dumneavoastră, iar noi nu stocăm nimic din ea. Ceea ce trece prin hub-ul nostru – instanța noastră de calcul securizat din Zurich, Elveția – este conținutul care este procesat: fiecare schimb, precum și fragmentele de memorie pe care containerul dumneavoastră le trimite atunci când este necesară o evaluare sau se compune un rezumat al sesiunii. Secțiunea 4 a Politicii de confidențialitate le enumerează exact. Nimic din toate acestea nu este păstrat.

Ce este software-ul de pe mașina ta

Containerul conține memoria ta, căutarea asupra ei și mecanismele care mențin ambele corecte. El nu conține niciun prompt, nici acces la niciun model AI și nicio setare care să îl direcționeze către un astfel de model. Nu există nimic în el care să poată evalua memoria ta și nimic de configurat care să-i permită să încerce. Fiecare evaluare este cerută de la hub-ul nostru printr-o conexiune pe care containerul o deschide spre exterior și autentifică – noi nu ne conectăm niciodată.

Tocmai această formă face traficul auditabil, iar dumneavoastră sunteți îndemnat să îl auditați: schimburile urcă, elementele de mai sus urcă, comenzile și rândurile coboară. Clientul este source-available — citiți fiecare linie din el.

Un singur lucru rămâne în întregime de partea dumneavoastră: căutarea în propria memorie – înregistrările, întreaga istorie și liniile sale de decizie datate – se face ca o simplă citire asupra propriilor tabele, în interiorul propriului container. Funcționează chiar și când hub-ul nostru este inaccesibil și nu trimite nimic spre evaluare.

În varianta găzduită, traficul este criptat în tranzit cu TLS, iar la repaus întregul sistem de fișiere al containerului dumneavoastră — fiecare conversație, fiecare înregistrare, chiar baza de date — este criptat cu o cheie derivată din o frază de acces pe care doar dumneavoastră o dețineți. Nu o vedem niciodată și nu o stocăm niciodată: ea tranzitează la pornirea sesiunii, deblochează memoria, iar memoria se blochează din nou după ce vă îndepărtați. Un container blocat este text cifrat pentru toată lumea, inclusiv pentru noi — un disc furat, o imagine scursă sau un drive scoase din uz nu sunt decât zgomot, la fel și accesul nostru root cât timp sunteți plecat.

Ștergerea este criptografică

Ștergerea nu este o simplă trecere cu speranța prin stocare: containerul dumneavoastră criptat este distrus în întregime — și, deoarece ștergerea textului cifrat nu necesită cheie, acest lucru funcționează chiar dacă ați uitat fraza de acces. Copiile de siguranță rămase sunt ilizibile fără ea și sunt șterse pe măsură ce scara de backup-uri se rotește, în cel mult 30 de zile. Nu există nicio copie pe care să o putem readuce.

Ce nu acoperă criptarea

Limite prezentate sincer. Criptarea la repaus este exact asta — la repaus: cât timp memoria dumneavoastră este deblocată pentru o sesiune, containerul lucrează în mod necesar cu datele dumneavoastră în clar pentru a servi căutările, deci „nu ne uităm niciodată la datele dumneavoastră" este politica și controalele noastre de acces, nu o imposibilitate matematică — garanția matematică o aveți ori de câte ori containerul este blocat. Preferăm să vă spunem unde este limita decât să vă lăsăm să credeți că nu există.

Copiile de siguranță ale containerelor găzduite sunt extrageri ale sistemului de fișiere criptat însuși — text cifrat înainte de a părăsi mașina, ilizibil fără fraza dumneavoastră de acces — păstrate pe o scurtă scară rotativă de copii zilnice și săptămânale în Germania. Când un cont este șters, copiile sale de siguranță sunt șterse odată cu el, iar orice copii rămase se elimină în 30 de zile.

Memoria găzduită este stocată, indexată și căutată în întregime în UE — serverele și copiile noastre de siguranță se află în Germania. Embedding-urile pentru căutare sunt calculate pe propriile noastre mașini și nu le părăsesc niciodată. Memoria locală nu ajunge niciodată la niciuna dintre acestea: ea este pe discul dumneavoastră, sub orice protecție pe care i-o oferiți.

Singura excepție este curarea AI. Fiecare pasaj care este curat este procesat pe instanța noastră de calcul securizat din Zürich, Elveția — o țară pe care UE o recunoaște ca oferind un nivel adecvat de protecție a datelor — iar de acolo un singur pas de model este trimis către Ollama, care găzduiește acest model în Statele Unite și în Europa, este procesat și returnat. Termenii publicați de Ollama precizează că datele de intrare și de ieșire sunt procesate temporar și nu sunt niciodată folosite pentru antrenarea modelelor — acesta este angajamentul lor, în propriii lor termeni, și îl enunțăm ca fiind al lor, nu ca o promisiune a noastră. Nimic altceva nu părăsește UE. Dacă aveți nevoie ca nici curarea să nu părăsească UE, acest lucru este disponibil printr-o implementare dedicată — întrebați-ne. Fiecare sub-procesor, cu scopul și locația sa, este listat în Politica de confidențialitate.

Cum operăm

Privilegii minime, în mod implicit

Serviciul rulează ca un utilizator fără privilegii în containerul său, niciodată ca root. Rolul său de bază de date nu este de superutilizator și nu poate citi fișiere de pe gazdă. Acestea sunt verificate automat înainte de fiecare lansare, nu presupuse.

Endpoint-urile interne sunt blocate la margine.

Punctele de terminare care furnizează conturi și validează cheile sunt accesibile doar de propriul nostru plan de control, autentificate la marginea rețelei înainte ca o cerere să ajungă, și din nou printr-un secret partajat în spatele acestuia. Două încuietori, nu una.

Eșec închis

Când ceva lipsește sau este ilizibil, serviciul refuză decât să ghicească. O cheie neverificabilă este refuzată. Permisiuni corupte nu acordă nimic. Un secret de semnare webhook lipsă respinge fiecare eveniment, în loc să aibă încredere în ceea ce sosește. Aceasta este o postură deliberată: modul de eșec al unui serviciu de memorie ar trebui să fie „fără răspuns“, niciodată „răspunsul clientului greșit“.

Fiecare lansare este verificată din exterior

Înainte de lansarea oricărei versiuni, o poartă automată parcurge întregul produs de la un cont nou-nouț printr-o conexiune reală la rețea: înregistrare, emitere și revocare de chei, stocare și rechemare a memoriei, izolare între două conturi active, export de date și ștergere completă. Fie trece complet, fie lansarea nu are loc.

Raportarea unei probleme de securitate

Dacă credeți că ați găsit o vulnerabilitate, vă rugăm să ne anunțați înainte de a spune altcuiva, și vom lucra cu dumneavoastră. Datele de contact sunt publicate la /.well-known/security.txt sau scrieți la hello@Brethof.ai. Nu amenințăm cercetătorii care raportează cu bună credință.

Cerințe mai profunde — un acord de procesare a datelor, o implementare dedicată într-o regiune aleasă de dumneavoastră, sau menținerea curățării în interiorul UE — sunt lucruri pe care le gestionăm direct. Întrebați.