AI Security: come proteggere LLM ed agenti AI

I rischi che fanno tremare gli LLM

Sebbene la lista completa dell’OWASP Top 10 per le applicazioni GenAI sia in continua evoluzione e includa sfumature tecniche profonde, possiamo distillare alcuni dei pericoli più significativi che ogni azienda deve affrontare. La lista che andremo a delineare non riproduce alla lettera l’OWASP Top 10, ma ne distilla alcuni dei rischi più rilevanti per chi sviluppa applicazioni LLM ed agentic AI.

Prompt Injection e Jail Break

Immaginate di dare al vostro LLM un’istruzione, e che un utente malintenzionato riesca a fargli ignorare completamente quella direttiva, iniettando comandi nascosti nel prompt (da qui prende il termine di Prompt Injection). Il modello, ingenuamente, eseguirà le istruzioni maligne, magari rivelando dati sensibili o compiendo azioni non autorizzate. 

Nel jailbreak, invece, l’attaccante non sfrutta necessariamente una concatenazione vulnerabile dell’applicazione ma agisce direttamente sul modello, cercando di indurlo a superare i propri filtri di sicurezza, le policy di allineamento o le istruzioni del system prompt attraverso tecniche di prompting sofisticate. In questo caso l’obiettivo è “liberare il modello dalla gabbia”, forzandolo a produrre output o comportamenti che normalmente rifiuterebbe.

Tra l’altro, sulla differenza tra Prompt Injection e Jailbreak ne abbiamo parlato in maniera più approfondita proprio in questo nostro video.

Improper Output Handling

Un LLM genera output, certo, ma cosa succede se quell’output, anziché essere solo una risposta testuale, è un pezzo di codice malevolo o un comando che viene eseguito da un’altra parte del sistema senza adeguati controlli? Ad esempio, un LLM potrebbe generare un link di phishing o un cross-site scripting (XSS) che, se non correttamente sanificato, potrebbe compromettere la sicurezza dell’applicazione utente.

Training Data Poisoning

Un altro aspetto di estrema rilevanza è la qualità e l’integrità dei dati di addestramento. In questo caso si parla proprio di Training Data Poisoning, che consiste nell’introduzione di dati alterati o malevoli nel set di addestramento, con l’obiettivo di indurre il modello a generare risposte errate e dannose. Provate a pensare ad un LLM che, a causa di dati “avvelenati”, inizi a diffondere disinformazione o a mostrare bias inaccettabili. Questo tipo di attacco è subdolo perché compromette il modello alla base, rendendo difficile la rilevazione e la correzione a posteriori.

Model Denial of Service (DoS)

Gli attacchi DoS tradizionali a cui siamo stati abituati in questi anni, hanno l’obiettivo di sovraccaricare un servizio per renderlo indisponibile. Nel contesto degli LLM, questa procedura può avvenire sfruttando quelle vulnerabilità che forzano il modello a consumare eccessive risorse computazionali (ad esempio, tramite prompt complessi o cicli infiniti), rendendolo lento, costoso o completamente inaccessibile per gli utenti legittimi. Questo non solo danneggia l’esperienza utente, ma può anche comportare costi operativi esorbitanti.

Supply Chain Vulnerabilities

Come abbiamo imparato in questi ultimi anni da ChatGPT in poi, le applicazioni AI raramente nascono dal nulla, spesso integrano librerie di terze parti, modelli pre-addestrati, API esterne o framework open source. Ed è qui che entrano in gioco le Supply Chain Vulnerabilities, che emergono quando uno di questi componenti esterni è compromesso. Basta pensare agli attacchi basati su librerie inventate da un LLM ( cosa che succede spesso anche a noi), che consiglia un pacchetto inesistente inducendo così uno sviluppatore ad installare una versione malevola pubblicata da un attaccante. Questo è un rischio che permea l’intero ecosistema di sviluppo, dalla scelta di strumenti come Bytebot o Suna AI fino alla gestione delle dipendenze. È cruciale valutare attentamente ogni anello della catena di fornitura, come abbiamo discusso anche nell’articolo AI per Sviluppatori.

Security Misconfiguration e Data Exposure involontaria

Errori nella configurazione di permessi, credenziali predefinite non modificate o la divulgazione di dettagli sensibili tramite messaggi di errore verbose possono portare a un’esposizione involontaria di dati. Un LLM configurato male potrebbe inavvertitamente accedere a un database sensibile o rivelare dettagli interni del sistema, mettendo a rischio la privacy e la sicurezza delle informazioni.

Un esempio concreto di questo tipo di rischio è l’incidente di ChatGPT del marzo 2023. In quel caso, la divulgazione di informazioni sensibili non fu causata da prompt injection o jailbreak, ma da un errore infrastrutturale: un bug in una libreria open-source (redis-py) portò alla condivisione temporanea di dati di sessione tra utenti diversi. L’incidente espose titoli di chat e, per una piccola percentuale di utenti, anche dati di pagamento, dimostrando come la sicurezza non dipenda solo dal modello, ma da ogni strato dell’architettura che lo circonda.

Model Inversion e Extraction

Altri tipi di attacchi mirano ad estrarre informazioni sensibili dal modello stesso. Nel Model Inversion, gli attaccanti tentano di ricostruire i dati di addestramento originali, potenzialmente rivelando informazioni personali. Nel Model Extraction, invece, l’obiettivo è replicare o “rubare” il modello sottostante, una minaccia non solo alla proprietà intellettuale ma anche alla sicurezza se il modello rubato viene utilizzato per scopi malevoli o retroingegnerizzato per scoprire vulnerabilità.

Agenti AI: quando il rischio si fa autonomo

Gli agenti AI aggiungono un ulteriore strato di complessità alla sicurezza attraverso i processi di automazione. Un modello LLM si limita a generare testo mentre un agente AI, come abbiamo esplorato già nei trend del 2026, può interpretare un obiettivo, pianificare azioni ed interagire con strumenti esterni (API, database, sistemi legacy) per raggiungere il suo obiettivo. Questo significa che un prompt Injection su un agente AI non solo può causare la divulgazione di informazioni, ma può portare a azioni reali e potenzialmente devastanti, come la modifica di record aziendali, l’invio di email compromettenti o la manipolazione di sistemi critici.

La sicurezza come pilastro dell’innovazione AI

La rivoluzione dell’Intelligenza Artificiale è qui per restare, lo sappiamo bene, e con essa la crescente urgenza di affrontare i rischi di sicurezza che LLM e agenti AI introducono. Il lavoro dell’OWASP ci offre una mappa preziosa per navigare questo territorio inesplorato, ma spetta a noi, come sviluppatori e aziende, intraprendere il viaggio con la massima cautela e professionalità.

Questo è esattamente l’obiettivo del nostro corso di AI Security: partire dai riferimenti OWASP e costruire una comprensione profonda e trasferibile. Ogni tema viene affrontato ancorandosi alla letteratura: paper di ricerca, report industriali e documenti tecnici, per capire non solo che cosa può andare storto, ma perché va storto e quali trade-off emergono quando si implementano controlli reali.

Proteggere queste tecnologie non è solo un obbligo etico e legale, ma un vantaggio competitivo. Un’applicazione AI sicura è un’applicazione affidabile, che ispira fiducia negli utenti e nei partner. Investire nella sicurezza intelligenza artificiale significa investire nella sostenibilità e nel successo a lungo termine delle vostre iniziative AI. E per chi vuole approfondire queste competenze e diventare un pioniere in questo campo, i percorsi di carriera come l’ AI Developer sono la risposta per trasformare le sfide in opportunità. Non si tratta solo di costruire un’AI, ma di costruirla bene e in sicurezza.