Sicurezza

Un database per cliente

La tua memoria non è una riga in una tabella condivisa con una colonna per il cliente. Ogni cliente ha la propria. database proprio. Non ci sono tabelle condivise e nessuna query che coinvolga più clienti e possa causare errori, poiché il confine è rappresentato dal database stesso, e non da un filtro che qualcuno deve ricordarsi di inserire.

Quel limite viene verificato dall’esterno in ogni rilascio: vengono utilizzate due account reali, e ogni interfaccia che restituisce dati viene controllata per assicurarsi che nessuno dei due possa vedere l’altro. Un rilascio non viene inviato se questa verifica non viene superata.

Chiavi, e chi può usarle

Non possiamo mostrarvi la vostra chiave.

Le chiavi API vengono mostrate una sola volta, al momento della creazione. Quello che memorizziamo è un hash SHA-256 — quindi una copia del nostro database non permette a nessuno di ottenere una chiave funzionante, e né noi né un attaccante possiamo leggere la tua chiave. La revoca di una chiave ha effetto sul servizio entro circa un minuto, e immediatamente sulla macchina che serve la tua memoria.

Le chiavi possono essere restringite

Una chiave non deve essere onnipotente. Le chiavi possono essere Definito per progetto — Lettura e scrittura, solo lettura o completamente invisibile: questa è la forma adatta per un contractor, un lavoro CI o un agente a scopo specifico che non ha alcun motivo di leggere il resto del tuo lavoro. Una chiave con ambiti corrotti o illeggibili viene privata di tutto invece di ottenere tutto.

Autenticazione a due fattori

Il tuo account può richiedere un secondo fattore all'accesso e, quando lo attivi, viene applicato a ogni accesso — dopo la password e dopo GitHub o Google allo stesso modo — e non è semplicemente mostrato come un'impostazione.

La creazione di una chiave API richiede un accesso protetto: autenticazione a due fattori sul tuo account, oppure un accesso tramite GitHub o Google. Una password da sola non crea mai una chiave — nemmeno su un account che ha anche GitHub o Google collegati, perché ciò che conta è come hai effettuato l'accesso questa volta.

Ogni azione distruttiva — eliminare un progetto, oscurare la cronologia, eliminare l'account, ripristinare un backup — chiede di nuovo chi sei: la tua password se ne hai una, e il tuo codice a due fattori; senza la verifica in due passaggi, un accesso GitHub o Google degli ultimi dieci minuti. L'esportazione dei tuoi dati non la richiede mai.

Accedi con GitHub o Google

L'accesso tramite GitHub o Google utilizza il flusso standard di codice di autorizzazione con PKCE, legato al browser che lo ha avviato. Riceviamo il tuo indirizzo email, il tuo nome e l'ID del tuo account presso quel servizio — nient'altro. Non conserviamo alcun token di accesso GitHub o Google, e non possiamo leggere i tuoi repository, la tua posta o i tuoi file. Un account GitHub o Google si collega a un account Brethof esistente solo quando quel servizio ha verificato l'indirizzo email e lo abbiamo verificato anche noi, oppure quando l'account non ha ancora una password.

Protezione dai propri agenti

Questa è la parte a cui la maggior parte dei servizi non pensa. La tua memoria viene continuamente gestita da agenti AI – e un agente può commettere errori, ricevere istruzioni maliziose nascoste all’interno dei contenuti che gli vengono chiesti di leggere, o cancellare qualcosa di sbagliato ore prima che una persona se ne accorga.

L'archivio grezzo delle conversazioni è quindi deliberatamente fuori dalla loro portata. Nessun agente può eliminare un singolo messaggio. Nessun agente può toccare in alcun modo gli ultimi tre mesi. La cronologia più antica può essere rimossa solo in blocco, per progetto. Eliminare un intero progetto — l'unica azione che raggiunge l'archivio nella sua interezza — non è disponibile per gli agenti a nessun livello; avviene nel pannello dell'account, dove una persona digita il nome del progetto.

Il motivo per cui questo è importante è semplice: la memoria curata è derivata, mentre l’archivio è l’originale. Quello che si perde a causa di una modifica errata può essere ricostruito grazie alla storia. Niente, invece, può ricostruire la storia stessa.

Crittografia, backup e dove vivono i tuoi dati

La tua memoria è un contenitore per cliente: ha il proprio database, il proprio filesystem, il proprio utente Linux, niente è condiviso. Se scegli la forma locale, quel contenitore gira sulla tua macchina: la tua memoria è conservata da te e noi non ne conserviamo nulla. Ciò che transita per il nostro hub — la nostra istanza di calcolo sicuro a Zurigo, in Svizzera — è il contenuto in fase di elaborazione: ogni scambio, e i frammenti di memoria che il tuo contenitore invia quando serve una valutazione o viene composto un brief di sessione. La Sezione 4 della Privacy Policy li elenca esattamente. Nulla di ciò viene conservato.

Che cosa è il software sul tuo computer

Il contenitore conserva la tua memoria, la ricerca su di essa e i meccanismi che tengono entrambe corrette. Non contiene alcun prompt, nessun accesso a un modello AI e nessuna impostazione che lo punti verso uno di essi. Non c'è nulla al suo interno in grado di valutare la tua memoria, e nulla da configurare che gli permetta di provarci. Ogni valutazione viene richiesta al nostro hub tramite una connessione che il tuo contenitore apre in uscita e autentica — noi non ci connettiamo mai in ingresso.

È proprio quella forma a rendere il traffico verificabile, e sei tu che devi verificarlo: gli scambi salgono, i pezzi sopra salgono, comandi e righe tornano giù. Il client è source-available — leggine ogni riga.

Una cosa rimane interamente dalla tua parte: la ricerca nella tua memoria — i record, tutta la storia e le sue righe decisionali datate — avviene semplicemente come lettura direttamente dalle tue tabelle, all'interno del tuo stesso contenitore. Funziona anche con il nostro hub irraggiungibile e non invia nulla da valutare.

Nella forma ospitata, il traffico è crittografato in transito con TLS, e a riposo l'intero filesystem del tuo container — ogni conversazione, ogni record, il database stesso — è crittografato con una chiave derivata da una passphrase che solo tu possiedi. Non la vediamo mai e non la memorizziamo: transita all'avvio della sessione, sblocca la tua memoria, e la memoria si riblocca da sola quando ti allontani. Un container bloccato è testo cifrato per tutti, noi inclusi — un disco rubato, un'immagine trapelata o un'unità dismessa sono solo rumore, e lo è anche il nostro accesso root mentre sei assente.

La cancellazione è crittografica

Cancellarti non è una speranzosa passata sui dati: il tuo container crittografato viene distrutto nella sua interezza — e poiché eliminare testo cifrato non richiede alcuna chiave, funziona anche se hai dimenticato la tua passphrase. I backup rimanenti sono illeggibili senza di essa e vengono cancellati man mano che la scala dei backup scorre, entro 30 giorni al massimo. Non esiste alcuna copia che possiamo recuperare.

Ciò che la crittografia non copre

Limiti dichiarati. La crittografia a riposo è esattamente questo — a riposo: mentre la tua memoria è sbloccata per una sessione, il container lavora necessariamente con i tuoi dati in chiaro per servire le tue ricerche, quindi "non guardiamo mai i tuoi dati" è la nostra politica e i nostri controlli di accesso, non un'impossibilità matematica — la garanzia matematica la hai ogni volta che il container è bloccato. Preferiamo dirti dov'è il confine che lasciare che tu pensi non esista.

I backup dei container ospitati sono prelievi del filesystem crittografato stesso — testo cifrato prima di lasciare la macchina, illeggibile senza la tua passphrase — conservati su una breve scala progressiva di copie giornaliere e settimanali in Germania. Quando un account viene eliminato, i suoi backup vengono eliminati con lui, e le copie residue vengono rimosse entro 30 giorni.

La memoria ospitata è archiviata, indicizzata e cercata interamente all'interno dell'UE — i nostri server e i backup sono in Germania. Gli embedding di ricerca sono calcolati sulle nostre macchine e non le lasciano mai. La memoria locale non arriva a nulla di tutto questo: sta sul tuo disco, protetta da qualunque protezione tu dia al tuo disco.

L'unica eccezione è la curatela tramite AI. Ogni passaggio in fase di curatela viene elaborato sulla nostra istanza di calcolo sicuro a Zurigo, Svizzera — un paese che l'UE riconosce come garantente un livello adeguato di protezione dei dati — e da lì un singolo passaggio di modello viene inviato a Ollama, che ospita questo modello negli Stati Uniti e in Europa, dove viene elaborato e restituito. I termini pubblicati da Ollama dichiarano che input e output sono elaborati in modo transitorio e mai usati per addestrare modelli — è il loro impegno, nei loro stessi termini, e lo riportiamo come loro, non come promessa nostra. Null'altro esce dall'UE. Se hai bisogno che anche la curatela non esca mai dall'UE, è disponibile su un deployment dedicato — chiedi. Ogni sottoresponsabile, con finalità e ubicazione, è elencato nella Privacy Policy.

Come operiamo

Minimi privilegi, per impostazione predefinita

Il servizio funziona come utente non privilegiato all’interno del proprio container, mai come root. Il suo ruolo nel database non è quello di superutente e non può leggere file dall’host. Tali caratteristiche vengono verificate automaticamente prima di ogni rilascio, anziché essere date per scontate.

I punti di terminazione interni sono bloccati ai bordi.

I punti di accesso che gestiscono le account e verificano le chiavi sono raggiungibili solo dal nostro piano di controllo, autenticati ai bordi della rete prima ancora che arrivi una richiesta, e nuovamente tramite un segreto condiviso. Due meccanismi di sicurezza, non uno.

Fallire in modo sicuro

Quando qualcosa manca o è illeggibile, il servizio rifiuta la richiesta invece di fare congetture. Una chiave non verificabile viene respinta. I permessi corrotti non garantiscono alcun risultato. Un segreto di firma per i webhook assente fa sì che vengano rifiutati tutti gli eventi, invece di fidarsi di ciò che arriva. Si tratta di una scelta intenzionale: il modo in cui un servizio di memorizzazione dovrebbe funzionare in caso di errore è “nessuna risposta”, mai “la risposta del cliente sbagliato”.

Ogni rilascio è verificato dall’esterno

Prima che qualsiasi versione venga rilasciata, un controllo automatizzato esamina l’intero prodotto partendo da un account completamente nuovo attraverso una connessione di rete reale: registrazione, emissione e revoca delle chiavi, memorizzazione e recupero della memoria, isolamento tra due account attivi, esportazione dei dati e cancellazione completa. Il controllo deve passare completamente, altrimenti il rilascio non avviene.

Segnalare un problema di sicurezza

Se ritiene di aver individuato una vulnerabilità, la preghiamo di informarci prima di dirlo a chiunque altro; lavoreremo insieme a lei. I dati di contatto sono pubblicati su /.well-known/security.txt o scrivere a hello@Brethof.ai. Non minacciamo i ricercatori che riferiscono in buona fede.

Requisiti più approfonditi — un accordo sul trattamento dei dati, una distribuzione dedicata in una regione a tua scelta, o il mantenimento della cura dei dati all’interno dell’UE — sono cose che gestiamo direttamente. Chiedi.