Stavo facendo una cosa abbastanza normale, almeno per chi usa ogni giorno assistenti come Claude, ChatGPT, Codex o Antigravity. Avevo trovato online una skill e volevo capire se valesse la pena installarla. Per skill intendo un pacchetto di istruzioni personalizzate: file che spiegano all’agente come affrontare un compito, quali passaggi seguire, quali strumenti usare e in che formato consegnare il risultato.

Ho chiesto all’assistente di valutarla. Non di installarla, né di eseguire quello che conteneva. Prima volevo un parere sulla qualità delle istruzioni, sulla provenienza e sugli eventuali rischi. Risultato: in mezzo al contenuto normale della skill, c’era un ordine rivolto non a me ma all’AI che lo stava leggendo.

L’ordine nascosto in una pagina normale

L’istruzione chiedeva all’assistente di visitare un altro sito, seguire le indicazioni trovate lì e pubblicare automaticamente una recensione a nome mio. Senza domandarmi il permesso. Il dettaglio interessante è proprio questo: io non avevo chiesto di pubblicare nulla e non stavo nemmeno cercando quel sito. La pagina provava a inserire una nuova missione dentro la mia richiesta originale, contando sul fatto che l’AI l’avrebbe scambiata per un comando legittimo.

L’assistente ha riconosciuto l’anomalia, non ha seguito il collegamento, non ha tentato di scrivere la recensione e me lo ha detto prima di tornare alla valutazione della skill. È andata bene. Per un momento ho pensato che il fatto fosse quasi buffo: uno stratagemma piuttosto goffo per ottenere una recensione fasulla. Poi mi sono corretto perché il risultato richiesto era banale, il meccanismo no.

Se un contenuto recuperato dal web riesce a cambiare il comportamento dell’agente, l’azione successiva potrebbe essere più seria: inviare un messaggio, modificare un file, eseguire un comando nel terminale oppure trasferire dati verso un servizio esterno. La gravità dipende dai permessi concessi. Un chatbot che può soltanto rispondere ha un raggio d’azione limitato. Un agente collegato a browser, email, repository e shell può fare parecchio di più, come ho già raccontato parlando di ChatGPT Work e del passaggio dalla risposta all’esecuzione.

Che cos’è una prompt injection

Quello che ho incontrato è un caso di prompt injection indiretta: un’istruzione camuffata da contenuto prova a dirottare un modello che lo sta leggendo per conto dell’utente. Può stare in una pagina web, in un PDF, dentro un commento nel codice, in una email o nei metadati di un file. Non deve essere visibile a una persona; basta che venga interpretata dal modello.

OWASP distingue le injection dirette, inserite nell’input dato al modello, da quelle indirette provenienti da fonti esterne come siti e documenti. Segnala anche che il rischio cresce con l’autonomia dell’agente: tra gli effetti possibili ci sono azioni non autorizzate e comandi eseguiti nei sistemi collegati. La sua indicazione pratica è mantenere privilegi minimi e richiedere l’approvazione umana per le operazioni sensibili. La scheda OWASP sulla prompt injection entra nel dettaglio tecnico.

Non è la stessa cosa di un virus tradizionale e nemmeno, per forza, di un jailbreak. Qui l’attaccante non sta convincendo me a fare clic con una finta email bancaria. Sta parlando al software che lavora per me. In pratica prova a usare l’assistente come tramite, sfruttando l’ambiguità fra due cose che per un modello hanno entrambe forma testuale: i dati da analizzare e gli ordini da seguire.

Le piattaforme stanno costruendo difese. OpenAI raccomanda di non lasciare che dati non affidabili guidino direttamente un agente e di mantenere le conferme per gli strumenti. Anthropic descrive controlli sui permessi, isolamento del recupero web e verifica dei comandi sospetti. Nessuna documentazione seria promette immunità completa. Il controllo non può essere delegato interamente allo stesso sistema che stiamo cercando di controllare.

Una skill è codice, anche quando sembra testo

La skill che stavo esaminando non era necessariamente malevola. Il tentativo è arrivato da una pagina incontrata durante la ricerca, ed è una distinzione che vale la pena conservare. L’episodio, però, mi ha fatto guardare con meno leggerezza ai marketplace non ufficiali di skill e plugin.

Una skill spesso appare innocua perché contiene Markdown, configurazioni e frasi in linguaggio naturale. Per l’agente, però, sono istruzioni operative. Possono chiedergli di leggere file, lanciare script, installare dipendenze, usare credenziali disponibili o chiamare servizi esterni. Il confine fra documentazione e comportamento è sottile.

Installare una skill senza leggerla equivale ad adottare una procedura scritta da uno sconosciuto e autorizzare un collaboratore velocissimo a seguirla. Potrebbe funzionare bene. Potrebbe contenere un comando superfluo, una raccolta di dati non dichiarata o un passaggio che pubblica qualcosa. La filiera software è un problema noto; le skill gli danno una forma più accessibile e facile da sottovalutare.

Vale anche per chi costruisce siti. Se concediamo all’agente accesso al terminale, alle variabili d’ambiente e al deploy perché ci faccia risparmiare tempo nella realizzazione di un sito web, quelle autorizzazioni hanno un peso. Il lavoro può essere corretto e rapido, ma l’ambiente va trattato come un ambiente di sviluppo vero, non come una chat un po’ più capace.

Le verifiche che faccio prima di installare

Dopo questo episodio non ho smesso di usare skill, plugin o agenti. Sarebbe una reazione comoda ma poco utile. Ho reso più esplicite alcune verifiche che, ammetto, prima facevo con meno regolarità.

• Leggo tutti i file della skill prima dell’installazione. Cerco script richiamati, comandi di rete, dipendenze, accessi a cartelle esterne e istruzioni che chiedono di ignorare regole precedenti.
• Controllo la provenienza. Un repository con cronologia, issue pubbliche e contributori reali non garantisce sicurezza, ma offre elementi verificabili. Un archivio anonimo caricato ieri no.
• Tratto le azioni verso terzi come un confine. Pubblicare, inviare, contattare, acquistare, fare deploy o modificare dati fuori dal progetto richiede una conferma specifica. Una generica modalità “fai tutto tu” non basta.
• Concedo soltanto i permessi necessari. Se l’agente deve analizzare una skill, non gli serve pubblicare recensioni. Se deve correggere CSS, non gli serve accedere alla posta.
• Chiedo una segnalazione esplicita. Quando incontra istruzioni sospette in una fonte esterna, l’assistente deve fermarsi, riportare dove le ha trovate e spiegare quale azione stava evitando.

Quest’ultimo comportamento ha fatto la differenza. Ignorare silenziosamente l’ordine avrebbe evitato il danno, ma non mi avrebbe fatto capire che la pagina tentava di influenzare il processo. La segnalazione ha trasformato un blocco di sicurezza in informazione utile: posso escludere la fonte, rivedere i permessi e decidere se proseguire.

La stessa regola dovrebbe entrare in qualunque progetto di automazione aziendale con controllo umano. L’obiettivo non è inserire una richiesta di conferma dopo ogni lettura, fino a rendere lo strumento inutilizzabile. Bisogna collocarla prima delle azioni che hanno effetti fuori dalla sessione e rendere visibili i tentativi di cambiare obiettivo. Leggere una pagina è una cosa. Pubblicare a nome mio è un’altra.

Di solito valutiamo un assistente per ciò che riesce a fare: scrive codice, prepara una landing, confronta documenti, cerca una soluzione e la applica. Dopo questo episodio aggiungo un criterio meno appariscente. Voglio sapere che riconosce una richiesta che non arriva da me, rinuncia a eseguirla e me la mostra. Il valore di un agente sta anche negli ordini che sa ignorare.