Il problema non è mai stato se i Large Language Models potessero essere ingannati, ma quanto lontano si potesse spingere un attaccante con un singolo prompt malevolo. L’ultima evoluzione, emersa da ricerche sulla sicurezza AI, mostra che la risposta è: molto più lontano di quanto si pensasse. Alcuni dei tool AI più diffusi possono essere trasformati in ingranaggi per botnet su scala internet, sfruttando una debolezza strutturale che nessun aggiornamento di modello può colmare del tutto.

Al cuore del meccanismo c’è l’incapacità intrinseca degli LLM di distinguere tra istruzioni legittime e malevole quando queste arrivano da fonti esterne – email, codice sorgente, pagine web, documenti – che il modello processa come parte del proprio contesto. L’iniezione di comandi (prompt injection) sfrutta proprio questo confine assente: bastano poche righe nascoste in un contenuto apparentemente innocuo per riorientare il comportamento del modello, spesso in modo invisibile sia all’utente che ai sistemi di monitoraggio tradizionali.

Finora la maggior parte degli attacchi ha seguito un modello “push”: il codice malevolo viene spinto verso una vittima specifica, ad esempio tramite un’email o un invito di calendario contaminato. Questo approccio limita la scala dell’attacco perché richiede di colpire individualmente ogni bersaglio. La svolta che sta attirando l’attenzione dei ricercatori è di natura opposta: sfruttare la capacità degli LLM di andare attivamente a recuperare contenuti da fonti terze (un comportamento tipico di molti tool che leggono pagine web, repository, basi di conoscenza) per trasformare il modello stesso in un moltiplicatore dell’attacco. In pratica, l’iniezione non viene più inviata alla vittima, ma depositata in luoghi che il modello esplora autonomamente, generando un effetto a catena senza bisogno di targeting diretto.

Per chi progetta difese, il dato più scomodo è che le contromisure attuali – le cosiddette guardrail – sono per lo più palliativi. Non risolvono il problema alla radice perché non stabiliscono un confine architetturale tra fonti fidate e non fidate all’interno del flusso di elaborazione del modello. I fornitori di piattaforme AI cloud cercano di filtrare input e output con classificatori di contenuti e policy di sicurezza, ma restano sempre in rincorsa: ogni nuovo pattern di attacco richiede una regola nuova, e il modello non ha alcuna nozione nativa di “fonte attendibile”.

Questo scenario ha implicazioni dirette per chi valuta deployment on-premise o ibridi. A prima vista, portare i modelli dentro il proprio perimetro di rete potrebbe sembrare una protezione naturale: i dati restano sotto controllo, l’accesso a internet può essere limitato, e i prompt provengono solo da utenti interni. Ma l’illusione svanisce non appena il modello interagisce con repository di codice, documentazione tecnica o basi di conoscenza aziendali – archivi che raramente sono verificati in modo granulare per contenuti ostili. Un documento di specifica modificato in modo sottile, un commento in un ticket Jira o una nota in un wiki interno possono diventare veicoli di iniezione altrettanto efficaci di una pagina web pubblica. La sovranità dei dati non basta se la provenienza dei contenuti non è certificata lungo tutta la pipeline.

Da un punto di vista strutturale, la vicenda segnala che la sicurezza degli LLM non si può delegare interamente al modello o ai tool di serving. Serve un salto di livello: spostare le difese più a monte, nell’architettura di ingestion dei dati, con meccanismi di isolamento contestuale e firma crittografica delle fonti. In un’ottica on-premise, questo si traduce nella possibilità di costruire pipeline di retrieval-augmented generation (RAG) in cui ogni documento recuperato da un database vettoriale è verificato, tracciato e confinato in un contesto con privilegi minimi, riducendo la superficie di attacco anche in presenza di modelli intrinsecamente vulnerabili.

Non è un caso che i grandi fornitori di AI consumer stiano accelerando su strumenti di "grounding" e su modalità di esecuzione confinate. Ma queste soluzioni, quando sono gestite da terzi, introducono un ulteriore livello di opacità: l’utente non ha modo di verificare come vengono applicate le guardrail, né di personalizzarle in base al proprio threat model. Il self-hosting, invece, restituisce al team di sicurezza la possibilità di definire politiche di contesto granulari e di monitorare l’intero flusso – dal token in ingresso al completamento generato.

In definitiva, l’emergere di attacchi su scala botnet basati su prompt injection non è tanto una novità tecnica, quanto la conferma che la corsa alle funzionalità sta superando la riflessione architetturale sulla fiducia. Per le organizzazioni che trattano dati sensibili o operano in settori regolati, il messaggio è chiaro: la scelta tra cloud e on-premise non può essere fatta solo su parametri di costo o latenza. Deve includere la capacità di governare la provenienza delle informazioni che il modello processa, perché finché gli LLM continueranno a vedere ogni contenuto come istruzione, il confine tra un assistente e un vettore d’attacco dipenderà da chi controlla il rubinetto dei dati.