Prompt injection negli agenti AI: quando il tool di coding diventa il bersaglio

TLDR

La prompt injection diventa piu pericolosa quando un modello AI puo leggere file, issue, codice e usare strumenti.
Il rischio non e la frase magica che buca il chatbot, ma il workflow: piccoli passaggi innocui che insieme producono un effetto pericoloso.
Un agente di coding deve trattare repository, README, issue, log e pagine web come input non fidato.
La difesa passa da permessi minimi, sandbox, review umana, allowlist di tool e audit dei comandi eseguiti.

Perche conta ora

Per anni abbiamo parlato di prompt injection come di una cosa quasi teatrale: scrivi una frase furba, il chatbot dimentica le regole, la demo fa ridere e tutti tornano al lavoro.

Quel periodo e finito.

Il problema oggi non e piu il chatbot isolato. Il problema e l'agente: un sistema che legge il repository, interpreta issue, modifica file, chiama tool, suggerisce comandi, apre documentazione e prova a "portare a termine il task". Nel momento in cui il modello non sta solo parlando ma sta lavorando, ogni testo che incontra diventa una possibile leva.

Un README, una issue pubblica, un commento in un file, una pagina di documentazione, un log di errore o una risposta di un tool possono diventare input ostile. Non perche contengano magia, ma perche l'agente prova a essere utile.

Ed e proprio li che si apre la crepa.

Il cambio di prospettiva

La domanda sbagliata e: "Questo modello rifiuta una richiesta pericolosa in chat?"

La domanda giusta e: "Questo workflow resta sicuro quando l'obiettivo pericoloso viene spezzato in passaggi normali?"

Un agente di coding non ragiona come un form statico. Riceve un compito, raccoglie contesto, genera patch, legge errori, corregge, propone test, itera. Ogni passaggio puo sembrare innocente. La catena completa, pero, puo arrivare dove una singola richiesta diretta sarebbe stata bloccata.

Ecco il punto tecnico: la sicurezza non puo essere valutata solo sul prompt singolo. Va valutata sulla sequenza.

Se un modello rifiuta in chat ma poi produce lo stesso risultato mentre "aiuta a sistemare un progetto", il controllo e nel posto sbagliato. Sta guardando la porta d'ingresso mentre la finestra del garage e aperta.

Come entra l'attacco

La prompt injection indiretta sfrutta contenuti che sembrano dati, ma sono scritti per essere interpretati come istruzioni.

Esempi realistici:

una issue pubblica che contiene istruzioni rivolte all'agente;
un README in un repository clonato da Internet;
un file di configurazione con commenti ambigui;
una pagina web letta dall'agente durante la ricerca;
un log che suggerisce un comando "risolutivo";
un tool MCP o una skill descritta in modo ingannevole.

Il trucco non e convincere l'utente umano. Il trucco e convincere l'automazione che quel testo faccia parte del lavoro.

Questo cambia anche la mentalita difensiva: non basta dire "non copiare comandi da Internet". Ora bisogna chiedersi anche quali comandi o modifiche un agente potrebbe proporre dopo aver letto contenuto non fidato.

Il rischio dei repository non fidati

Un repository sconosciuto non e solo codice. E un ambiente narrativo.

Dentro puo esserci documentazione, test, script, issue template, prompt nascosti, file di setup, messaggi di errore finti, configurazioni per tool e istruzioni rivolte agli assistenti AI. Se apri quel progetto con un agente che ha accesso al filesystem, ai token o alla shell, stai dando a quel testo un canale per influenzare l'ambiente.

Il rischio aumenta quando:

l'agente puo leggere directory fuori dal progetto;
esistono token o chiavi in variabili d'ambiente;
il terminale e integrato nel workflow;
i tool hanno permessi larghi;
le conferme umane diventano automatiche per stanchezza;
il repository include configurazioni per agenti, plugin o MCP server.

La vecchia regola "non eseguire script a caso" resta valida. Solo che adesso lo script a caso potrebbe essere suggerito da un assistente che parla con tono rassicurante.

Cosa controllare subito

Prima di usare un agente AI su un progetto sconosciuto, fai queste verifiche:

Apri il repository in una cartella isolata.
Rimuovi segreti, .env, token cloud e chiavi SSH dall'ambiente.
Disattiva esecuzione automatica di comandi, install script e tool esterni.
Leggi README, issue template e file di configurazione prima dell'agente.
Se usi MCP o plugin, parti da una allowlist minima.
Chiedi conferma manuale per comandi shell, modifiche fuori repo e accesso rete.
Controlla il diff finale come se fosse stato scritto da uno sconosciuto.

La frase chiave e questa: l'agente deve dimostrare cosa sta facendo, non solo sembrare competente.

Difese pratiche per team piccoli

Non serve costruire una piattaforma militare per migliorare parecchio la situazione.

Per un team piccolo, una base sensata e:

usare ambienti di sviluppo separati per repository non fidati;
tenere i segreti fuori dalla shell usata dall'agente;
limitare i tool disponibili per default;
registrare i comandi proposti ed eseguiti;
bloccare letture fuori dalla root del progetto;
fare review manuale su file di CI, deploy, auth, dipendenze e script;
evitare token GitHub con accesso a tutta l'organizzazione;
non far lavorare agenti su issue pubbliche con accesso a repo privati.

Queste misure non eliminano la prompt injection, ma riducono il raggio dell'esplosione. Ed e spesso quello che conta: non impedire ogni errore possibile, ma evitare che un singolo testo ostile diventi esfiltrazione, shell, commit o leak.

Il punto da ricordare

La prompt injection negli agenti AI non e un bug singolo da patchare una volta per tutte. E una classe di rischio.

Somiglia piu all'XSS che a un incidente isolato: nasce dal mescolare contenuto non fidato e istruzioni operative nello stesso flusso. Per anni abbiamo imparato a non fidarci dell'input utente nelle web app. Ora dobbiamo imparare a non fidarci dell'input che un agente legge mentre cerca di aiutarci.

Il futuro dello sviluppo assistito dall'AI non e "non usare agenti". Sarebbe una risposta pigra.

La risposta seria e usarli come useresti un collaboratore velocissimo, brillante e troppo ingenuo: gli dai un ambiente limitato, controlli cosa puo toccare, guardi i diff, separi i segreti e non gli fai prendere decisioni irreversibili solo perche ha scritto una spiegazione elegante.

Il prompt non e piu solo una domanda.

In un agente, il prompt puo diventare superficie d'attacco.

FAQ

Che cos'e la prompt injection indiretta?

E un attacco in cui istruzioni malevole vengono nascoste dentro contenuti che il modello legge, come issue, documenti, pagine web o file di progetto. L'utente non scrive il comando pericoloso: lo incontra l'agente mentre lavora.

Perche gli agenti AI sono piu esposti dei chatbot?

Perche non si limitano a rispondere. Possono leggere file, generare codice, aprire tool, proporre comandi, modificare repository e talvolta eseguire operazioni nell'ambiente dello sviluppatore.

GitHub Copilot, Claude Code o Cursor sono automaticamente insicuri?

No. Il punto e che ogni agente con accesso a file e strumenti aumenta la superficie d'attacco. La sicurezza dipende da permessi, isolamento, conferme esplicite e qualita del workflow.

Come posso usare agenti AI in modo piu sicuro?

Apri repository non fidati in sandbox, limita l'accesso ai segreti, verifica i comandi prima di eseguirli, evita token troppo permissivi e non lasciare che l'agente agisca su issue o file esterni senza revisione.

La prompt injection si puo risolvere con un filtro?

Un filtro aiuta, ma non basta. Il problema nasce dalla confusione tra dati e istruzioni: servono isolamento, policy sui tool, log verificabili e controllo umano sui passaggi ad alto rischio.