Dic 10, 2025 Approfondimenti, Attacchi, Gestione dati, In evidenza, Minacce, Minacce, News, RSS, Vulnerabilità, Vulnerabilità
Secondo il National Cyber Security Centre (NCSC), l’agenzia governativa del Regno Unito per la cybersecurity, il problema della prompt injection (PI) potrebbe non venire mai risolto.
In un approfondimento dedicato l’agenzia ha spiegato che, nonostante le due vulnerabilità vengano spesso accostate, sono in realtà concettualmente molto diverse. Assumere che siano simili significa rischiare di sottovalutare la PI e di conseguenza applicare misure di mitigazione inefficaci.
“Sebbene il confronto tra la prompt injection e la SQL injection possa essere allettante, è anche pericoloso. La seconda può essere adeguatamente mitigata con query parametrizzate, ma è probabile che la prima non possa mai essere adeguatamente mitigata allo stesso modo. Il meglio che possiamo sperare è di ridurre la probabilità o l’impatto degli attacchi” si legge nel post.

Il concetto dietro le due vulnerabilità è lo stesso: in entrambi i casi si tratta di una gestione errata di dati e istruzioni che consente di eseguire l’input utente come un comando. Nel caso della SQL injection la mitigazione standard è l’uso di query parametrizzate che trattano sempre l’input come dato e mai come istruzione.
Nel caso degli LLM questa distinzione non esiste: quando il chatbot riceve un prompt, lo elabora senza distinguere le istruzioni dai dati, cercando sempre di prevedere il token successivo più probabile. Poiché non c’è una separazione vera tra istruzione e dato a livello del modello, non esiste un equivalente delle query parametrizzate deterministico e risolutivo.
Ad oggi la mitigazione della prompt injection è un’area di ricerca molto attiva e include già diversi approcci, come l’individuazione dei tentativi di injection, l’addestramento dei modelli per prioritizzare le istruzioni rispetto a “dati che sembrano istruzioni” e istruire il modello su cosa sono i “dati“. Di fatto le metodologie si basano sempre sull’idea di separare ciò che è “dato” da ciò che è “istruzione”; poiché però gli LLM operano in maniera intrinsecamente diversa dagli altri sistemi, la mitigazione non è definitiva.
Per ridurre il rischio, è fondamentale che sviluppatori e team di sicurezza comprendano che la PI è un rischio persistente che non può essere mitigato completamente con un prodotto o un’appliance esterna.
È necessario che i modelli e le applicazioni vengano progettate seguendo i principi del Secure Design, soprattutto quando l’LLM è autorizzato a chiamare strumenti esterni o API. La protezione deve includere: l’implementazione di controlli di sicurezza non-LLM che vincolino le azioni del sistema e l’applicazione del principio del least privilege.
È possibile inoltre usare tecniche per ridurre la probabilità che l’LLM agisca sulle istruzioni iniettate usando marcatori come i tag XML per incapsulare e separare la sezione “dati” dalle “istruzioni”. L’NCSC in questo caso sconsiglia di affidarsi a delle deny-list di frasi malevole, in quanto la complessità degli LLM offre infinite riformulazioni che possono eludere questi filtri.

Infine, è essenziale monitorare prompt e dati per identificare attività sospette, inclusi l’input e l’output completi dell’LLM, e le chiamate a strumenti o API. Poiché gli attaccanti spesso devono affinare i loro attacchi, il rilevamento e la risposta a chiamate API o strumenti fallite possono indicare le fasi iniziali di una violazione.
L’NCSC avverte che, come è successo con le SQL Injection, c’è il rischio che, se non si adottano fin da subito approcci di sicurezza migliori, avvenga un picco di compromissioni e fughe di dati. “Rischiamo di vedere questo modello ripetersi con la prompt injection, dato che stiamo per integrare la genAI nella maggior parte delle applicazioni. Se queste applicazioni non sono progettate tenendo conto della prompt injection, potrebbe verificarsi un’ondata simile di violazioni“.