Oggi gli agenti di programmazione possono accedere alla shell di macchine reali. Eseguono migrazioni, puliscono directory, reimpostano branch e rimuovono file che sembrano superflui. Nella maggior parte dei casi fanno esattamente ciò che è stato richiesto. Esiste però un nuovo tipo di incidente, per cui il backup degli agenti IA è diventato un ambito specifico: una copia raggiungibile dall'agente può essere distrutta dallo stesso agente, spesso mentre svolge un compito legittimo.
Non è un rischio ipotetico inventato per vendere spazio di archiviazione. Chi esegue agenti su un checkout attivo probabilmente ne ha già visto uno cancellare qualcosa che andava conservato. Questa pagina illustra un modello di backup che può ridurre il rischio se configurato correttamente e ne chiarisce i limiti.
Perché il backup esistente non è adatto agli agenti IA
Il modello di minaccia tradizionale considera guasti hardware, errori umani o ransomware. Gli agenti attraversano tutte e tre le categorie, perché operano con le credenziali dell'utente, alla velocità di una macchina e con motivazioni apparentemente plausibili.
Un'unità di rete montata è visibile a qualsiasi processo eseguito come utente. Lo stesso vale per una cartella sincronizzata, un'unità mappata o un bucket di object storage le cui chiavi si trovano in un file di ambiente leggibile dall'agente. Se l'agente considera una directory come un vecchio risultato di compilazione, decide che il repository va reimpostato o tenta di liberare spazio, tutto ciò che vede può rientrare nell'operazione. La sincronizzazione propaga quindi la cancellazione alla copia su cui si faceva affidamento, proprio come previsto dal suo funzionamento.
La differenza fondamentale non è quindi tra cloud e archiviazione locale. È l'accessibilità della copia dall'ambiente in cui opera l'agente.
Il modello di backup: inviare, senza sincronizzare
È il punto che viene frainteso più spesso e merita una sezione dedicata.
La sincronizzazione è bidirezionale per natura. Se si elimina un file in locale, la copia remota segue: è il comportamento desiderato per i file di lavoro, ma può distruggere un archivio. Molte configurazioni definite backup sono in realtà sincronizzazioni e proteggono da un disco guasto, non necessariamente da una cancellazione. Da anni le indicazioni nazionali sulla resilienza al ransomware sottolineano lo stesso principio. Secondo le raccomandazioni della CISA, una copia deve essere isolata dal sistema che protegge. Un agente con accesso alla shell è semplicemente un modo nuovo e rapido di non rispettare questo requisito.
Un backup adatto invia nuovi contenuti senza replicare le rimozioni. Destinazioni datate o con indicazione dell'ora fanno sì che ogni esecuzione aggiunga una copia invece di sostituirla. In molte configurazioni, trenta copie giornaliere di un dump del database costano meno del tempo necessario a spiegare perché non esisteva una copia ripristinabile.
La separazione delle credenziali è essenziale
Il meccanismo è semplice, e per un backup è un pregio. Serve un percorso di invio unidirezionale con credenziali che l'ambiente di lavoro non possiede mai.
Drive consente di creare dalla dashboard password per le app associate a un dispositivo e revocabili singolarmente. Una configurazione solida utilizza una credenziale dedicata al backup, presente soltanto sulla macchina o nell'attività pianificata che esegue l'invio: mai nella directory del progetto, in un file di ambiente condiviso o in un percorso affidato all'agente. L'agente può operare liberamente sulla copia di lavoro, ma non dispone di un percorso verso la destinazione.
Se l'attività di invio viene eseguita sulla stessa macchina dell'agente, la credenziale va tenuta fuori dall'albero del progetto e protetta con autorizzazioni minime del sistema operativo. Se viene eseguita altrove, per esempio su un piccolo dispositivo sempre acceso o su un runner pianificato, la separazione è ancora più netta perché non esiste un file system condiviso. In entrambi i casi, la copia resiste solo finché l'agente e i processi che controlla non possono leggere né ottenere la credenziale.
Da cosa protegge questo backup e quali sono i suoi limiti
In questo caso la precisione conta più di un messaggio rassicurante.
Può proteggere da un agente che elimina o sovrascrive file nell'ambiente di lavoro, uno script che svuota una directory, una reimpostazione accidentale del repository e comuni errori umani, purché sia già disponibile una copia completa e isolata. Copre anche il caso in cui una sincronizzazione propaghi fedelmente una cancellazione involontaria.
Non protegge da chi possiede l'accesso alla dashboard e il secondo fattore, perché può revocare le password delle app e svuotare il cestino. Non copre inoltre la compromissione della destinazione, una politica di conservazione inadeguata o l'eliminazione intenzionale dell'archivio. E non sostituisce il controllo di versione del codice sorgente, che risolve un problema diverso.
Il backup degli agenti IA è un singolo livello. Non costituisce da solo un programma di sicurezza e sostenere il contrario sarebbe fuorviante.
Gli elementi che vale la pena inviare
L'elenco è più breve del previsto, perché gran parte di una directory di lavoro può essere riprodotta.
- Dump del database. Sono dati che non possono davvero essere rigenerati. Create copie notturne datate e conservatele in base ai limiti del piano e alla politica di conservazione.
- File di ambiente e configurazione. Piccoli, spesso dimenticati e difficili da ricostruire, possono anche contenere segreti. Cifrateli, limitate rigorosamente l'accesso e pianificate la rotazione delle credenziali.
- Contenuti caricati dagli utenti. Non sono nel controllo di versione, non possono essere rigenerati e spesso vengono ignorati finché non scompaiono.
- Artefatti generati importanti. Per esempio report ed esportazioni prodotti da un processo che nel frattempo è cambiato.
Di solito il codice sorgente non deve trovarsi qui se un repository git remoto adeguatamente protetto ne conserva già la cronologia. Includerlo non crea problemi, ma non è lo scopo principale di questo livello.
La struttura di un'attività notturna
L'implementazione può essere breve e facile da verificare, riducendo la manutenzione senza garantire che continui sempre a funzionare.
Un'attività pianificata viene eseguita una volta ogni notte. Esporta il database in un file temporaneo, aggiunge la data al nome, lo carica in un percorso datato sull'unità, verifica che il trasferimento sia riuscito e soltanto allora elimina la copia locale temporanea. I file di configurazione e i contenuti caricati seguono lo stesso percorso. L'attività usa una credenziale propria, non legge segreti dalla directory del progetto e non contiene alcuna funzione di cancellazione remota.
Due dettagli distinguono un backup utile da uno che smette di funzionare senza farsi notare. Primo, il percorso di destinazione deve includere la data, così ogni esecuzione crea una nuova copia. Caricare ogni notte lo stesso nome lascia esattamente un backup, quello della notte precedente, insufficiente per un problema scoperto giovedì. Secondo, ogni errore deve produrre un avviso verificato. Un backup che non funziona da sei settimane può creare una falsa sensazione di sicurezza.
Verificare il ripristino
Una copia che nessuno ha mai ripristinato resta un'ipotesi, non un backup verificato. È spesso il punto più debole delle configurazioni.
Una volta ogni trimestre, scaricate una copia e ripristinatela davvero in un ambiente temporaneo. Controllate tre aspetti: che il file sia stato scaricato integro, che sia completo e non troncato da un'attività interrotta a metà, e che la procedura sia nota. L'ultimo punto è fondamentale, perché un'emergenza non è il momento adatto per imparare come si esegue il ripristino.
Il ripristino convalida anche un aspetto specifico di questa architettura: l'accesso alla destinazione e la procedura di recupero funzionano ancora. Da solo non dimostra che la credenziale di invio sia ancora valida e aggiornata. Monitorate quindi separatamente ogni caricamento e il relativo orario, perché la fase di invio può interrompersi mentre tutto il resto sembra normale.
Per quanto tempo conservare le copie
La conservazione dipende dal rischio, dagli obblighi e dal budget di archiviazione, non da una regola tecnica universale. Il periodo adeguato è spesso più lungo della prima scelta.
Un problema non viene sempre scoperto subito. La rimozione di una directory può essere evidente in poche ore, mentre un danneggiamento lieve dei dati o la cancellazione di un elemento usato solo mensilmente può passare inosservato per settimane. Trenta copie giornaliere offrono un mese di cronologia. Il loro costo dipende però dal volume effettivo, dalla crescita dei dati e dal piano scelto.
Una pratica comune consiste nel conservare tutte le copie giornaliere per un mese e poi una copia al mese per un anno. In questo modo si limita la crescita mantenendo una cronologia più lunga. Qualunque sia la regola, applicatela con un'attività distinta, un'identità separata e controlli adeguati. Se lo strumento di caricamento può anche eliminare, si reintroduce parte del rischio che l'architettura dovrebbe ridurre.
Dove archiviare il backup
Drive è associato allo stesso account della posta, caratteristica che può ridurre il numero di servizi e fatture. Nell'offerta descritta qui, il componente aggiuntivo parte da 250 GB a $3.20 al mese, con un selettore che arriva a 100 TB, nei termini e nei limiti del piano. L'assenza di costi di uscita dichiarata per questa offerta è utile in fase di ripristino, ma occorre verificare le condizioni applicabili all'account.
In base alla configurazione, lo spazio può essere condiviso nell'account oppure assegnato a ogni casella, mantenendo la destinazione del backup separata dagli altri consumi. I caricamenti possono avvenire tramite WebDAV o API quando questi metodi sono supportati. Le indicazioni per il montaggio sono disponibili nella guida a WebDAV. È inoltre possibile condividere cartelle con un altro account per agevolare il ripristino, come spiegato in come funzionano i link di condivisione. La condivisione non sostituisce autorizzazioni minime, cifratura e registri di controllo.
Il principio è semplice: una cartella datata, una credenziale assente dall'ambiente di lavoro e un'attività che si limita ad aggiungere. Gli agenti hanno reso di nuovo essenziale un vecchio consiglio: la copia utile durante un incidente è quella a cui nulla nell'ambiente di lavoro può autenticarsi, nei limiti dell'isolamento effettivamente configurato.
