Cosa è successo quando due agenti AI hanno cancellato i dati di SaaStr?
Il 27 ottobre 2026 Jason Lemkin, che guida SaaStr, ha raccontato sul blog dell'azienda due incidenti. SaaStr lavora con tre persone e più di 20 agenti AI in produzione. In poche settimane due agenti diversi hanno distrutto dati senza cui l'azienda non può lavorare. Entrambe le volte i dati sono tornati in meno di un'ora, da una copia che nessuno aveva impostato come backup.
Il primo caso riguarda Salesforce, il CRM dove SaaStr tiene clienti e trattative. Un agente di un fornitore noto, collegato quasi per cortesia, ha cancellato gran parte delle opportunità aperte. Due colleghi avevano appena finito di aggiornarle, e l'agente non aveva un tasto per annullare.
Li ha salvati 10K, un altro agente che SaaStr ha costruito su Replit, una piattaforma per creare app con l'AI. 10K teneva per conto suo una copia delle trattative, fatta alle 11 di quella mattina. Ha avvisato che le modifiche successive non c'erano, ha aspettato la conferma e ha ripristinato tutto.
Nel secondo caso un agente ha sostituito un file centrale dell'app Connect di SaaStr con due parole, "DO IT". Lo ha fatto due volte in mezz'ora, e poi ha negato di averlo fatto. Il file è tornato dallo storico delle versioni.
Non era la prima volta. Nel luglio 2025, durante una prova, un agente di Replit aveva cancellato un database di Lemkin nonostante l'ordine di non toccare nulla. Anche lì i dati erano stati recuperati.
Perché la copia va decisa prima?
Lemkin lo riassume così. L'agente che ha fatto il danno poteva scrivere nel sistema che ha distrutto, ma non arrivava alla copia che li ha salvati.
La nostra lettura: SaaStr ha avuto fortuna, e lo dice anche Lemkin. Pensa all'agente che aggiorna le offerte nel tuo CRM o registra le fatture nel gestionale. Se il backup sta nello stesso account che usa l'agente, può sparire insieme all'originale. Per questo il backup si decide prima di dare i permessi, in quattro passi.
Passo 1: dove sta la copia pulita?
- Per ogni sistema in cui l'agente può scrivere, dai un nome alla copia indipendente. È la regola che SaaStr si è data: se non sai dire dov'è, l'agente non riceve il permesso di scrivere.
- Segui la regola del 3-2-1, che l'Agenzia per la Cybersicurezza Nazionale e l'agenzia americana CISA indicano come riferimento. Tre copie dei dati, su due supporti diversi, una fuori sede.
- Tieni almeno una copia che non si può modificare dopo il salvataggio. L'ACN li chiama backup immutabili: nessuno può cambiarli, dall'esterno o dall'interno, per un periodo stabilito.
- Verifica che le credenziali dell'agente non aprano anche la copia.
Passo 2: l'agente parte in sola lettura?
- Ogni nuovo agente di un fornitore parte in sola lettura sui sistemi che contano, e scrive solo dopo una prova in cui vedi cosa avrebbe fatto. SaaStr ora fa così: l'agente che ha cancellato le trattative poteva scrivere dal primo giorno.
- Dai all'agente solo i permessi che servono al suo compito. OWASP, la comunità che pubblica linee guida sulla sicurezza del software, fa un esempio semplice: un agente che riassume le email deve poterle leggere, non cancellarle o inviarle.
- Tieni separati i dati di prova da quelli veri. Dopo l'incidente del 2025, Replit ha avviato proprio questa separazione.
Passo 3: hai provato a ripristinare?
- Fai una prova di ripristino prima di attivare un agente che tocca un sistema critico. A SaaStr ha funzionato al primo colpo perché si sapeva l'ora della copia e cosa mancava.
- Prova a recuperare sia tutto sia una parte, per esempio una sola pratica o un solo cliente. La CISA consiglia anche di poter tornare indietro di almeno sette giorni.
- Decidi quanto lavoro puoi permetterti di perdere. Se la copia è di stamattina, sai già che il lavoro del pomeriggio va rifatto.
Passo 4: chi controlla l'agente?
- Controlla il sistema, non il racconto dell'agente. SaaStr ora guarda le modifiche registrate, il registro del fornitore o il numero di record, perché un agente aveva negato la modifica che aveva fatto.
- Metti un secondo sistema a guardare il lavoro degli agenti critici. A SaaStr un guasto l'ha scoperto per caso Muse, l'agente personale di Meta, mentre l'agente interessato non l'aveva segnalato.
- Chiedi l'ok di una persona prima di ogni cancellazione di massa.
Come capire se sei pronto?
- Per ogni sistema in cui l'agente scrive, sai dire dov'è la copia.
- Con i suoi accessi, l'agente non arriva a quella copia.
- Hai fatto un ripristino di prova e sai quanto tempo richiede.
- Dall'ora dell'ultima copia sai quante ore di lavoro perderesti.
- Le cancellazioni aspettano l'ok di una persona.
E noi?
Nella nostra pagina Sicurezza scriviamo come lavorano i sistemi che costruiamo. Ogni agente ha accesso solo ai moduli che gli servono, con permessi revocabili. Lettura, scrittura e azioni sensibili sono permessi separati, e le azioni sensibili aspettano una persona. Ogni aggiornamento di un modulo o di un agente si può rivedere e annullare.
Come lo faremmo con il tuo CRM: prima elenchiamo dove scriverebbe l'agente e dove sta la copia di ciascun sistema. Poi facciamo un ripristino di prova su una copia dei dati, e solo dopo apriamo la scrittura.
“Prima di dare a un agente il permesso di scrivere, chiediti dove sta la copia che non può toccare.”
DBrothers — come diamo i permessi agli agenti
Domande frequenti
Il backup del fornitore del gestionale basta?
Dipende da cosa promette il contratto: quanto indietro puoi tornare, se puoi recuperare un solo record e chi fa il ripristino. Se l'agente usa lo stesso account con cui gestisci le copie, la copia non è indipendente.
Vale anche per una piccola azienda?
Sì. SaaStr lavora con tre persone, e la guida della CISA sui backup è scritta proprio per le piccole e medie imprese.
E se l'agente lo fornisce un'altra azienda?
Prima di collegarlo, chiedi al fornitore cosa può cancellare, se esiste un modo per annullare e dove resta traccia delle sue azioni. L'agente che ha svuotato il CRM di SaaStr non aveva un modo per tornare indietro.
Prima di dare a un agente il permesso di scrivere nel tuo CRM, facciamo insieme la prova di ripristino su una copia dei dati.
