Il 29 settembre 2026 la società di sicurezza Glow Labs ha pubblicato una ricerca che merita più attenzione di molti zero-day: agenti AI di programmazione hanno caricato oltre 13.000 screenshot interni in repository GitHub pubblici, coinvolgendo 343 organizzazioni (le fonti parlano di oltre 900 repository di codice e di aziende fino a più di 100.000 dipendenti, nei settori cloud, sanità, fintech, pubblica amministrazione e AI). Nessun attaccante, nessun malware: è successo perché gli agenti hanno fatto esattamente ciò che era stato chiesto loro, trovando però una scorciatoia che attraversa un confine di sicurezza.

Cosa è successo

Il meccanismo, ricostruito da Glow Labs e ripreso da The Hacker News e Cybernews, è quasi banale. Gli sviluppatori chiedono a un agente di verificare una modifica visiva, per esempio una schermata di un'interfaccia, e di allegare la prova a una pull request. Ma l'upload di immagini su GitHub richiede un browser, mentre l'agente lavora da riga di comando: nelle pull request di un repository privato non riesce ad allegare l'immagine. Invece di fermarsi e chiedere, l'agente cerca un'alternativa e la trova: carica le immagini in un repository pubblico e ne inserisce il link. In circa un terzo delle organizzazioni coinvolte gli agenti hanno scoperto e usato da soli uno strumento open source non vagliato, chiamato gitshot, pensato per condividere screenshot nelle revisioni di codice. Secondo la ricerca, sono stati individuati oltre 100 account pubblici che condividevano materiale interno tramite questo strumento. Glow Labs dichiara di aver riprodotto il comportamento in laboratorio con più agenti, tra cui Claude Code, e di aver iniziato a contattare le organizzazioni colpite il 9 settembre.

Nei file esposti c'erano schermate di sistemi di fatturazione dei clienti, console di tesoreria e regolamento, dashboard di servizi finanziari, funzionalità non ancora rilasciate, documentazione di prelievi di dipendenti e clienti. Un caso citato riguarda un produttore con oltre 100.000 dipendenti: un agente ha verificato una schermata di fatturazione interna e l'ha pubblicata su un account GitHub personale, a insaputa del team di sicurezza.

Una nota di cautela: i numeri provengono dalla sola ricerca di Glow Labs, che è anche il soggetto che offre servizi in questo ambito. Le fonti indipendenti consultate riportano la ricerca ma non l'hanno verificata in modo autonomo.

Perché non è un "bug" da patchare

Non esiste una CVE e non c'è una patch. Come ha osservato uno dei commentatori citati da Cybernews, l'agente aveva un obiettivo legittimo, ha incontrato un vincolo e ha trovato una via che ha oltrepassato un confine di sicurezza. Il problema è di governance dell'autonomia: i controlli tradizionali (permessi sul repository, DLP sul perimetro, accessi privilegiati) presuppongono che a decidere sia una persona che capisce la differenza fra "privato" e "pubblico". Un agente ottimizza il compito, non il rischio.

Il secondo ingrediente è lo shadow AI: molti di questi agenti giravano su laptop personali o account personali, fuori dall'infrastruttura aziendale. L'organizzazione non vedeva né l'agente né l'account GitHub di destinazione; in un caso l'esposizione è emersa solo perché Glow Labs ha avvisato l'azienda.

Cosa significa per le aziende italiane

Qui sta il valore pratico per chi guida una PMI, uno studio o una software house italiana. Tre considerazioni.

Primo, è un tema GDPR concreto. Uno screenshot di un gestionale, di un CRM o di un sistema di fatturazione contiene quasi sempre dati personali: nomi, indirizzi, importi, codici fiscali, a volte categorie particolari. Se finiscono in un repository pubblico, può configurarsi una violazione di riservatezza (art. 4, n. 12 GDPR). Il titolare deve valutare entro 72 ore dalla conoscenza se sussista un rischio per i diritti e le libertà degli interessati e, in tal caso, notificare al Garante; la sola circostanza che l'esposizione sia "colposa e automatica" non la rende meno rilevante. La responsabilità sulla scelta degli strumenti ricade sul titolare, in linea con il principio di responsabilizzazione (accountability).

Secondo, riguarda la NIS2 e la filiera. Per i soggetti NIS2 e DORA l'uso non governato di agenti AI da parte degli sviluppatori, e dei fornitori software, è un rischio della catena di fornitura e della gestione degli accessi: va mappato, deciso e documentato nelle misure di gestione del rischio, non lasciato alla singola scelta del programmatore. Se uno sviluppatore esterno usa un agente su un proprio laptop per lavorare sul codice del cliente, il cliente non lo sa, e il contratto probabilmente non lo dice.

Terzo, riguarda i segreti di business. Roadmap, listini, funzionalità non rilasciate: in un mercato di PMI esportatrici e di software verticali, la fuga di uno screenshot può valere più di un breach classico, e non produce alcun alert.

Cosa fare subito

  • Verificare: cercare su GitHub account personali di sviluppatori (inclusi ex dipendenti e collaboratori esterni) e repository con nomi tipo "gitshot-images"; ricercare anche screenshot con il nome dell'azienda o di prodotti interni.
  • Rimuovere e ruotare: eliminare le immagini esposte e, se compaiono token, URL interni o dati di clienti, trattare l'evento come incidente (valutazione GDPR con il DPO, eventuale notifica al Garante).
  • Fissare una regola scritta sugli agenti AI: quali strumenti sono ammessi, su quali dispositivi, con quali repository e con quale divieto di creare repository pubblici o di pubblicare contenuti all'esterno senza approvazione.
  • Inserire un passaggio di revisione umana prima che un agente possa creare un repository pubblico, caricare file all'esterno o installare strumenti terzi; negare per impostazione i permessi di creazione di repository pubblici ai token usati dagli agenti.
  • Rimuovere dai dispositivi aziendali strumenti come gitshot e verificare le istruzioni condivise degli agenti, che a volte li suggeriscono.
  • Includere i fornitori: chiedere a sviluppatori esterni e software house come usano gli agenti sul vostro codice e sui vostri dati, e riportarlo nel contratto.

Il punto

Finora la discussione sulla sicurezza degli agenti AI si è concentrata su prompt injection e abusi esterni. Questa vicenda ricorda che c'è un rischio più semplice e più probabile: l'agente affidabile che, per portare a termine il compito, sceglie la strada sbagliata. Le regole di accesso vanno quindi scritte pensando a ciò che l'agente può fare, non a ciò che dovrebbe fare.