Sicurezza LLM

La sicurezza LLM è la disciplina specializzata di protezione delle applicazioni costruite su large language model da una classe unica di minacce che non esisteva nella sicurezza software tradizionale. Man mano che le organizzazioni implementano chatbot AI, agenti autonomi e workflow basati su LLM su larga scala, comprendere e affrontare le vulnerabilità specifiche degli LLM diventa un requisito operativo critico.

Perché gli LLM Richiedono un Nuovo Approccio alla Sicurezza

La sicurezza applicativa tradizionale presuppone un confine chiaro tra codice (istruzioni) e dati (input dell’utente). La validazione dell’input, le query parametrizzate e la codifica dell’output funzionano applicando questo confine strutturalmente.

I large language model collassano questo confine. Elaborano tutto — istruzioni dello sviluppatore, messaggi dell’utente, documenti recuperati, output degli strumenti — come un flusso unificato di token in linguaggio naturale. Il modello non può distinguere in modo affidabile un system prompt da un input utente malevolo progettato per sembrarne uno. Questa proprietà fondamentale crea superfici di attacco senza equivalenti nel software tradizionale.

Inoltre, gli LLM sono agenti capaci che utilizzano strumenti. Un chatbot vulnerabile non è solo un rischio per i contenuti — può essere un vettore di attacco per esfiltrazione di dati, esecuzione di chiamate API non autorizzate e manipolazione di sistemi connessi.

L’OWASP LLM Top 10

L’Open Worldwide Application Security Project (OWASP) pubblica l’LLM Top 10 — il riferimento standard del settore per i rischi critici di sicurezza LLM:

LLM01 — Prompt Injection: Input malevoli o contenuti recuperati sovrascrivono le istruzioni dell’LLM. Vedi Prompt Injection .

LLM02 — Gestione Insicura dell’Output: Il contenuto generato dall’LLM viene utilizzato in sistemi downstream (rendering web, esecuzione di codice, query SQL) senza validazione, abilitando XSS, SQL injection e altri attacchi secondari.

LLM03 — Avvelenamento dei Dati di Training: Dati malevoli iniettati nei dataset di training causano degrado del comportamento del modello o introducono backdoor.

LLM04 — Denial of Service del Modello: Input computazionalmente costosi causano un consumo eccessivo di risorse, degradando la disponibilità del servizio.

LLM05 — Vulnerabilità della Supply Chain: Modelli pre-addestrati compromessi, plugin o dati di training introducono vulnerabilità prima del deployment.

LLM06 — Divulgazione di Informazioni Sensibili: Gli LLM rivelano dati confidenziali dai dati di training, system prompt o documenti recuperati. Vedi Esfiltrazione di Dati (Contesto AI) .

LLM07 — Design Insicuro dei Plugin: Plugin o strumenti connessi agli LLM mancano di un’autorizzazione adeguata, abilitando attacchi di escalation.

LLM08 — Eccessiva Autonomia: Gli LLM a cui vengono concessi permessi o capacità eccessive possono causare danni significativi quando manipolati.

LLM09 — Eccessivo Affidamento: Le organizzazioni non riescono a valutare criticamente gli output degli LLM, permettendo a errori o informazioni fabbricate di influenzare le decisioni.

LLM10 — Furto del Modello: Accesso non autorizzato o replicazione di pesi o capacità proprietarie dell’LLM.

Pronto a far crescere il tuo business?

Inizia oggi la tua prova gratuita e vedi i risultati in pochi giorni.

Richiedi demo Accedi

Controlli di Sicurezza LLM Fondamentali

Separazione dei Privilegi e Principio del Minimo Privilegio

Il controllo singolo più efficace: limita ciò a cui il tuo LLM può accedere e fare. Un chatbot per il servizio clienti non ha bisogno di accesso al database HR, ai sistemi di elaborazione dei pagamenti o alle API amministrative. L’applicazione dei principi di minimo privilegio limita drasticamente il raggio d’azione di un attacco riuscito.

Sicurezza del System Prompt

I system prompt definiscono il comportamento del chatbot e spesso contengono istruzioni sensibili dal punto di vista aziendale. Le considerazioni di sicurezza includono:

• Non includere segreti, chiavi API o credenziali nei system prompt
• Progettare prompt resistenti ai tentativi di override
• Istruire esplicitamente il modello a non rivelare il contenuto del prompt
• Testare la riservatezza del prompt come parte delle valutazioni di sicurezza regolari (vedi Estrazione del System Prompt )

Validazione di Input e Output

Sebbene nessun filtro sia infallibile, la validazione degli input riduce la superficie di attacco:

• Segnalare e bloccare pattern di injection comuni e frasi simili a istruzioni negli input dell’utente
• Validare gli output del modello prima di passarli a sistemi downstream
• Utilizzare formati di output strutturati (schemi JSON) per vincolare le risposte del modello

Sicurezza della Pipeline RAG

La retrieval-augmented generation introduce nuove superfici di attacco. I deployment RAG sicuri richiedono:

• Controlli rigorosi su chi può aggiungere contenuti alle knowledge base indicizzate
• Validazione del contenuto prima dell’indicizzazione
• Trattare tutti i contenuti recuperati come potenzialmente non affidabili
• Monitoraggio per tentativi di RAG poisoning

Guardrail Runtime

Guardrail runtime stratificati forniscono difesa in profondità oltre l’allineamento a livello di modello:

• Filtri di moderazione del contenuto sia sugli input che sugli output
• Rilevamento di anomalie comportamentali
• Rate limiting e prevenzione degli abusi
• Logging di audit per analisi forensi

Test di Sicurezza Regolari

Le tecniche di attacco LLM evolvono rapidamente. Il penetration testing AI e l’AI red teaming dovrebbero essere condotti regolarmente — come minimo prima di cambiamenti importanti e annualmente come valutazioni di base.

Termini Correlati

• Prompt Injection — la vulnerabilità LLM più critica
• OWASP LLM Top 10 — il framework completo dei rischi di sicurezza LLM
• AI Red Teaming — test di sicurezza avversariali sistematici
• RAG Poisoning — attacchi di contaminazione della knowledge base
• AI Penetration Testing — valutazioni di sicurezza strutturate per sistemi AI