Gli agenti IA stanno entrando nei processi di sviluppo software, e con loro arriva una classe di rischi che molte aziende non hanno ancora imparato a valutare. Lo dimostra GitLost, la vulnerabilità divulgata il 6 luglio 2026 da Noma Labs: un attaccante senza credenziali, senza accesso e senza competenze tecniche particolari può far trapelare il contenuto di repository privati di un'organizzazione semplicemente aprendo una issue pubblica su GitHub.

Cosa è successo

GitHub ha lanciato di recente i GitHub Agentic Workflows, che affiancano a GitHub Actions un agente IA (basato su Claude o su GitHub Copilot). I flussi di lavoro si scrivono in Markdown, e l'agente legge le issue, invoca strumenti e risponde in autonomia. Il ricercatore Sasi Levi di Noma Labs si è posto la domanda più ovvia e più scomoda: cosa succede quando l'agente legge qualcosa di cui non dovrebbe fidarsi?

La risposta è un caso da manuale di prompt injection indiretta. Un agente IA non distingue in modo affidabile tra le istruzioni del suo operatore e le istruzioni nascoste nei contenuti che si trova a leggere: se un attaccante scrive quei comandi dentro il corpo di una issue, l'agente può semplicemente eseguirli. Il workflow vulnerabile analizzato da Noma era configurato per attivarsi all'assegnazione di una issue, leggerne titolo e corpo, rispondere con un commento e — dettaglio decisivo — operare con accesso in lettura ad altri repository dell'organizzazione, pubblici e privati.

L'attacco è disarmante nella sua semplicità. Il ricercatore ha aperto in un repository pubblico dell'organizzazione una issue camuffata da richiesta legittima: un finto messaggio di un "VP Sales" dopo un incontro con un cliente, con dentro le istruzioni malevole. Una volta che un'automazione ha assegnato la issue, l'agente ha recuperato il file README di un repository privato e lo ha incollato in un commento pubblico, leggibile da chiunque. Nessuna credenziale, nessun accesso, nessuna riga di codice: solo un testo scritto bene.

L'aggiramento delle protezioni

GitHub aveva predisposto dei guardrail proprio per impedire questo scenario, ma Noma ha mostrato che si potevano superare. Aggiungendo alle istruzioni iniettate la parola "Additionally" ("Inoltre"), il modello riformulava il proprio output invece di rifiutarlo, aggirando silenziosamente i controlli. È un particolare che dice molto: una difesa basata sul filtro del contenuto è intrinsecamente fragile, perché nel linguaggio naturale non esiste una linea netta tra dato e istruzione come esiste, ad esempio, tra dati e comandi in una query SQL. Per questo i ricercatori e gli stessi fornitori classificano il problema come limite architetturale, non come un semplice bug da correggere con una patch puntuale. La falla è stata comunicata a GitHub tramite divulgazione responsabile.

Cosa significa per le aziende italiane

Il punto non è "GitHub è insicuro", ma che una intera classe di automazioni sta entrando nei team di sviluppo italiani — software house, PMI tecnologiche, reparti IT — spesso senza una valutazione del rischio adeguata. Revisione automatica delle pull request, triage delle issue, generazione di codice: tutte funzioni utili, tutte alimentate da agenti che leggono contenuti provenienti dall'esterno. E qui sta il cuore del problema, ben sintetizzato da Noma: la finestra di contesto dell'agente è la sua superficie d'attacco. Qualunque cosa l'agente legga — issue, pull request, commenti, file — può essere trasformata in un'istruzione.

Il fattore che rende GitLost particolarmente insidioso è la barriera d'ingresso quasi nulla. Non serve compromettere nulla: basta una issue in un repository pubblico verso un'organizzazione che espone workflow agentici con permessi cross-repository. Chiunque può provarci, compresi scanner automatici. Nel modello di sicurezza tradizionale i confini di fiducia sono garantiti dal codice; nei sistemi agentici quei confini dipendono in parte dal comportamento del modello, che per natura tende a seguire le istruzioni. È lo stesso salto concettuale che il mondo web ha già affrontato: la prompt injection è agli agenti IA ciò che la SQL injection è stata alle applicazioni web, una vulnerabilità sistemica di categoria, non un caso isolato.

Sul piano della governance, per le organizzazioni che ricadono in NIS2 gli strumenti della catena di sviluppo software rientrano nel perimetro della gestione del rischio, e l'adozione di agenti IA va inserita in quella valutazione, non lasciata all'iniziativa dei singoli team. Se poi il repository privato esposto contiene dati personali o segreti applicativi, la fuga è a tutti gli effetti un data breach ai sensi del GDPR, con i relativi obblighi di valutazione e di eventuale notifica al Garante.

Cosa fare subito

  • Mai fidarsi dell'input dell'utente come istruzione: contenuti controllabili da terzi (issue, PR, commenti) non devono mai essere trattati come comandi fidati da un agente IA.
  • Minimizzare i permessi: gli agenti con accesso cross-repository sono bersagli ad alto valore. Evitare che un workflow che legge contenuti pubblici abbia contemporaneamente accesso in lettura ai repository privati.
  • Limitare le azioni pubbliche: circoscrivere ciò che un agente può pubblicare all'esterno, in particolare in risposta al contenuto di una issue.
  • Isolare l'input dal contesto: sanificare o separare l'input dell'utente dal contesto di istruzione prima di passarlo al modello, e prevedere una revisione umana per le operazioni sensibili.
  • Inventariare e aggiornare: censire dove sono già attivi workflow agentici e con quali privilegi, e applicare gli aggiornamenti di sicurezza resi disponibili da GitHub.