Aprire un repository sconosciuto con un agente AI non equivale più soltanto a far leggere del codice. Se l’assistente può interpretare istruzioni del progetto, eseguire comandi, installare dipendenze o usare strumenti collegati, anche un file apparentemente innocuo può diventare parte del suo contesto operativo.
Il problema è diventato concreto con le campagne osservate nel 2026 dal Google Threat Intelligence Group. Nel rapporto pubblicato l’8 settembre, GTIG descrive attori che hanno usato configurazioni nascoste e prompt injection per influenzare assistenti di coding e scanner basati su LLM. La domanda utile non è quindi se GitHub sia sicuro, ma quanto ti fidi del repository prima di concedere a un agente accesso a shell, rete e credenziali.
Come può un repository influenzare un agente AI
Gli agenti di coding moderni non leggono soltanto i file sorgenti. Possono caricare istruzioni dedicate al progetto, configurazioni dell’IDE, file per agenti, script di setup, dipendenze, workflow CI/CD e integrazioni con strumenti esterni. GitHub documenta, per esempio, che Copilot può utilizzare istruzioni repository-wide, file specifici per percorso e file dedicati agli agenti.
Questo comportamento è utile perché permette all’assistente di capire come compilare, testare e modificare un progetto. Lo stesso meccanismo crea però un confine di fiducia: se quelle istruzioni arrivano da un repository ostile, l’agente può ricevere indicazioni che non provengono dall’utente.
Cosa ha osservato Google nelle campagne del 2026
Nel rapporto GTIG dell’8 settembre 2026, Google descrive UNC6780, gruppo finanziariamente motivato che ha colpito ecosistemi open source come PyPI, npm e Docker Hub. Tra le tecniche osservate compaiono repository e pacchetti compromessi, workflow malevoli e file inseriti in directory di progetto utilizzate da IDE e assistenti AI.
GTIG segnala configurazioni collocate in cartelle nascoste del workspace con istruzioni capaci di spingere un assistente a eseguire script o comandi durante normali interazioni di sviluppo. Sono stati osservati anche prompt inseriti nei commenti di file JavaScript con l’obiettivo di confondere scanner di sicurezza basati su modelli linguistici.
Questo non significa che ogni agente esegua automaticamente qualsiasi istruzione presente in un repository. Prodotti diversi hanno sandbox, conferme, permessi e politiche differenti. Il punto è che il contenuto del progetto può diventare input per il modello e, se l’agente dispone di strumenti potenti, un input malevolo può tentare di trasformarsi in un’azione.
Prompt injection non è la stessa cosa di una vulnerabilità software
Una vulnerabilità tradizionale sfrutta un errore nel software per ottenere un comportamento non previsto. La prompt injection lavora invece sul livello delle istruzioni: un contenuto esterno tenta di convincere il modello a cambiare priorità, ignorare il compito originale o usare uno strumento in modo indesiderato.
Le due categorie possono però incontrarsi. Un agente che viene convinto a lanciare uno script, installare un pacchetto o leggere un file sensibile può trasformare un problema di istruzioni in un incidente operativo. Il rischio dipende quindi sia dal modello sia dai privilegi che gli hai concesso.
È lo stesso principio che emerge quando gli agenti lavorano nel browser. Nel nostro approfondimento su Gemini Spark in Chrome e i dati utilizzati dagli agenti abbiamo visto che più contesto e più autorizzazioni aumentano anche ciò che deve essere protetto.
Quali file controllare prima di aprire il progetto con un agente
La prima difesa è separare ispezione ed esecuzione. Se hai appena clonato un repository che non conosci, non partire chiedendo all’agente di configurare tutto autonomamente. Controlla prima ciò che può modificare il comportamento dell’ambiente.
- File di istruzioni per agenti e IDE: cartelle e file dedicati a Copilot, Claude, Gemini, Cursor e strumenti simili.
- Script di installazione e avvio: package script, setup, bootstrap, task e comandi eseguiti all’apertura del workspace.
- Dipendenze: nomi simili a pacchetti noti, sorgenti non standard, versioni appena pubblicate o riferimenti diretti a repository sconosciuti.
- Git hooks e workflow CI/CD: possono eseguire comandi in momenti che non coincidono con il normale avvio dell’applicazione.
- Configurazioni MCP e tool esterni: un server o un’integrazione può ampliare ciò che l’agente è in grado di leggere e fare.
- File nascosti e configurazioni dell’IDE: non vanno esclusi dalla revisione solo perché non appartengono al codice principale.
GitHub spiega nella propria documentazione sulle custom instructions di Copilot che file come .github/copilot-instructions.md e istruzioni dedicate agli agenti possono essere caricati nel contesto. In un progetto fidato è una funzione utile; in un repository da verificare è un elemento da leggere prima di lasciare che l’agente lavori in autonomia.
La regola più importante: niente segreti nel primo avvio
Un repository sconosciuto non dovrebbe essere aperto per la prima volta in un ambiente che contiene token di produzione, chiavi SSH, credenziali cloud o file .env reali. Se l’agente o uno script riesce a leggerli, il danno potenziale cresce molto più del problema iniziale.
GTIG ha osservato campagne interessate proprio a credenziali per servizi AI, token e configurazioni degli strumenti di sviluppo. La difesa pratica è usare un ambiente separato con privilegi minimi: una macchina virtuale, un container o un profilo di sviluppo privo di credenziali personali e aziendali.
Shell, rete e scrittura: quali permessi limitare
Un assistente che può soltanto leggere file espone una superficie diversa rispetto a un agente che può eseguire comandi, modificare il repository e collegarsi liberamente a Internet. Prima della prima analisi conviene partire dal livello di privilegi più basso possibile.
- Shell: richiedi conferma per i comandi e non autorizzare esecuzioni automatiche che non hai letto.
- Rete: limita l’accesso esterno quando il compito non lo richiede, soprattutto durante setup e installazione.
- Scrittura: osserva il diff prima di accettare modifiche generate dall’agente.
- Credenziali: usa token separati, con scope minimo e durata limitata.
- Tool esterni: collega solo MCP server e servizi che riconosci e di cui conosci origine e permessi.
Se il prodotto permette di lavorare in sandbox o di approvare ogni uso degli strumenti, queste opzioni sono particolarmente utili sui progetti non ancora verificati. Le impostazioni cambiano rapidamente tra servizi, quindi è corretto controllare la documentazione aggiornata del proprio agente prima di affidargli un repository esterno.
Come capire se l’agente sta facendo qualcosa di anomalo
Non serve aspettare un antivirus per accorgersi di ogni comportamento sospetto. Durante la prima sessione puoi controllare cosa cambia nel progetto e quali azioni vengono proposte. Un comando che tenta di leggere directory esterne al workspace, recuperare credenziali, modificare configurazioni globali o scaricare eseguibili non necessari merita una verifica.
Controlla il git diff, i nuovi processi, i file creati e, nei contesti più sensibili, le connessioni di rete. Se l’agente insiste nel compiere un’azione non richiesta, interrompi l’esecuzione e torna a un’analisi manuale del repository.
La capacità degli agenti di concatenare strumenti rende importante anche l’isolamento dell’ambiente. Il caso che abbiamo ricostruito parlando di agenti AI, sandbox e contenimento mostra perché il confine tecnico attorno al modello conta quanto il prompt iniziale.
Windsurf, Cursor, Copilot, Claude o Gemini: qual è il più sicuro?
Non esiste una risposta valida per ogni versione e configurazione. La sicurezza non dipende soltanto dal nome del modello o dell’editor, ma da quali file vengono caricati nel contesto, quali comandi sono consentiti, se esiste una sandbox, come vengono gestite le conferme e quali credenziali sono disponibili nella sessione.
Per questo non è corretto trasformare il rapporto GTIG in una lista di prodotti “vulnerabili”. Google ha documentato tecniche rivolte all’ecosistema degli assistenti di coding e degli scanner LLM. La valutazione del singolo strumento va fatta sulla sua documentazione corrente e sulla configurazione usata dall’utente.
Checklist prima di affidare un repository sconosciuto all’AI
- Clona il repository in un ambiente separato.
- Non inserire chiavi API, token, SSH key o
.envdi produzione. - Leggi prima file di istruzioni, configurazioni IDE, workflow, hook e script di setup.
- Controlla dipendenze e server MCP prima di installarli.
- Avvia l’agente con permessi minimi e conferma manualmente i comandi.
- Limita rete e accesso al filesystem quando il compito lo consente.
- Controlla git diff, nuovi file e processi dopo le prime azioni.
- Solo dopo la verifica collega account, servizi e credenziali necessari al lavoro.
Gli agenti di coding fanno risparmiare tempo proprio perché possono leggere il progetto e agire su di esso. Quel vantaggio richiede però di trattare il repository come una sorgente di input non fidata finché non l’hai controllato. Nel 2026 la sicurezza del codice non riguarda più soltanto ciò che il programma esegue: riguarda anche ciò che può convincere l’agente a eseguire.
