Quando un agente AI lavora su un progetto vero ha bisogno di accessi, che siano i log sul cloud di un cliente, un repository o un database, e la strada più veloce sarebbe dargli le chiavi.
In BrightOS, lo strumento interno con cui ogni giorno facciamo girare la Bright Factory, gli agenti non hanno le credenziali dei clienti: ogni volta che servono le chiedono, una persona prende la decisione e tutto rimane segnato.
Un agente AI con le chiavi in tasca
Gli agenti di oggi sono veloci, capaci e molto letterali, nel senso che se hanno un accesso lo usano. Prima di BrightOS questo era un problema concreto, e Luca Belmonte, che in Symboolic è Head of Architecture, lo racconta senza giri di parole nell'intervista che abbiamo registrato per i nostri canali.
«Non potevo impedire in nessun modo che Claude Code si collegasse in SSH a una macchina remota o al database di un cliente.»
Luca Belmonte · Head of Architecture di Symboolic
Se moltiplichiamo questo problema per più di venti ingegneri, decine di sessioni al giorno e tanti clienti diversi, il quadro diventa tanto chiaro da comprendere quanto confusionario nei fatti: credenziali copiate sui portatili, accessi aperti più a lungo del necessario e nessun modo semplice per ricostruire chi ha fatto cosa. È esattamente il contrario di quello che un'azienda si aspetta da chi sviluppa il suo software.
Per questo in BrightOS la sicurezza è diventata la condizione necessaria affinché tutto il resto possa funzionare.
Il confine è il cliente
Gli agenti lavorano in una sandbox, cioè un ambiente separato dal resto del computer, che vede una sola cartella, quella dei progetti, con una sottocartella per ogni cliente. Il resto del pc, semplicemente, non le è accessibile.
Ogni sessione lavora dentro il perimetro di un cliente, quindi un agente che lavora per l'azienda A non può accedere ai documenti dell'azienda B. Lo stesso vale per la memoria del lavoro: quando si cerca nelle conversazioni passate, chi lavora per un cliente vede solo le conversazioni di quel cliente e il lavoro interno, e le informazioni sensibili vengono oscurate prima di essere indicizzate.
L'agente fa la richiesta, ma è la persona a decidere
Le credenziali dei clienti restano sul computer, fuori dalla sandbox. Quando un agente ha bisogno di un accesso, per esempio per leggere i log su AWS, aprire una connessione SSH o lanciare una query su un database, non se lo prende da solo, ma lo chiede al broker, un componente di BrightOS che fa da intermediario.
Il broker concede l'accesso secondo le regole di quel cliente e solo per il tempo necessario, chiede conferma alla persona quando la regola lo prevede e registra ogni concessione. La richiesta compare sul canvas come una tessera, che dice chi la fa, cosa chiede, per quale cliente e quanto tempo resta per rispondere, con due pulsanti, Approva e Nega.
Se la risposta è no, l'agente si ferma, lo segnala chiaramente e non riprova. Nella demo, dopo il rifiuto, l'agente scrive «Accesso negato. Mi fermo. Nessuna lettura sul cloud» e chiude il lavoro con il suo esito, dove segna che per andare avanti servono i log forniti da una persona del team.
Fermarsi è previsto
Nella nostra vision c'è una frase a cui teniamo molto, e cioè che gli agenti sanno quando fermarsi. Un agente che tira a indovinare costa più di uno che chiede, e in BrightOS fermarsi è un comportamento normale, progettato fin dall'inizio.
Quando un agente ha bisogno di una persona, la sua sessione passa allo stato «ti aspetta», segnato in rosso, e arriva una notifica, così chi lo ha avviato vede subito dove e perché si è fermato. Per gli accessi, invece, c'è la tessera.
Lo stesso vale per Bolt, l'assistente che ognuno dei nostri ingegneri ha dentro BrightOS. Bolt può preparare una risposta a un collega o un messaggio nel canale di un progetto, ma nessuna azione a nome di una persona parte senza la sua conferma.
Ogni scelta ha una firma, e quindi una responsabilità
L'AI scrive, un ingegnere controlla, approva e ne risponde. Perché questo principio non resti uno slogan servono delle prove, e in BrightOS restano registrati gli esiti di ogni lavoro, le conversazioni con gli agenti, gli accessi concessi o negati e le modifiche ai file, così che si possa sempre ricostruire chi ha fatto cosa, e quando.
Prima che una modifica diventi definitiva, il pannello Modifiche mostra file per file cosa ha toccato l'agente, e l'ingegnere la legge e la approva. Così ogni lavoro affidato a un agente si chiude con un esito scritto, sempre nello stesso formato: cosa è stato fatto, cosa è cambiato e cosa resta aperto.
Quando un agente affida una parte del lavoro a un altro agente, l'aiutante non ha mai più permessi di chi lo ha creato. Ha anche lui un budget e una scadenza, e se il suo compito è verificare il lavoro di qualcun altro lavora in sola lettura. Anche il rilascio in produzione lo esegue un agente con un accesso prestato dal broker per quel cliente e per quel tempo, e registrato, quindi nessuna chiave del cliente vive sui portatili dei nostri ingegneri.
Più automazione, decisioni più umane
Cosa succederà quando gli agenti faranno ancora più lavoro? Luca ha una risposta precisa.
«Mi aspetto un processo sempre più automatizzato, in cui noi ingegneri saremo chiamati soprattutto a prendere le decisioni importanti, quelle sulla direzione del progetto.»
Scegliere un'architettura invece di un'altra, valutare una licenza o seguire una direzione strategica sono decisioni che richiedono un contesto che un agente spesso non ha. Più il lavoro operativo si automatizza, più conta che una persona metta il proprio timbro su quello che esce dalla fabbrica, e BrightOS è costruito per rendere quel momento chiaro, veloce e tracciabile.
Cosa cambia per chi ci affida un progetto
Tutto questo succede dentro l'officina, ma serve soprattutto a chi sta fuori, e per chi lavora con noi si traduce in poche garanzie molto concrete. Le credenziali dei vostri sistemi non vengono copiate sui portatili né negli ambienti in cui lavorano gli agenti, ogni accesso è concesso per un tempo limitato e resta registrato, ogni modifica e ogni decisione hanno una conversazione e un esito a cui risalire, e quello che riguarda il vostro progetto resta separato da quello che riguarda gli altri.
