L'OWASP LLM Top 10 è diventato il riferimento standard per la sicurezza delle applicazioni con IA — e, come ogni Top 10, è diventato anche una checklist che i team compilano senza testare. "Abbiamo coperto le dieci categorie" di solito significa che qualcuno ha letto le dieci descrizioni.
Questa guida è l'opposto: cosa significa ogni categoria quando hai le mani dentro il sistema, quale evidenza prova lo sfruttamento e dove si concentra la severità reale.
Il punto di partenza: mappare prima di testare
Nessuna delle dieci categorie può essere valutata senza una mappa della superficie. Prima del primo payload, documenta:
- Endpoint — chi chiama il modello, con quale autenticazione, con quali limiti di rate.
- System prompt — il testo completo, incluse le istruzioni iniettate dinamicamente.
- Strumenti e plugin — ogni funzione che il modello può invocare e cosa può fare.
- Pipeline RAG — da dove arrivano i documenti, chi può scriverci, come vengono indicizzati.
- Flusso dei dati — cosa entra nel contesto, cosa esce, cosa viene persistito.
Senza questa mappa, un test su LLM è una sessione di tentativi ed errori contro una scatola nera. Con essa, ogni categoria qui sotto ha bersagli concreti.
LLM01 — Prompt Injection
Cos'è. Input manipolati che alterano il comportamento del modello, aggirano i guardrail o innescano azioni non intenzionali.
Cosa testare. Separa la diretta dall'indiretta. La injection diretta (l'utente è l'attaccante) è il caso facile e il meno interessante. La injection indiretta — l'istruzione arriva dentro un documento recuperato, un'email elaborata, una pagina che l'agente ha navigato — è dove accadono gli incidenti reali, perché non richiede all'attaccante alcun accesso al sistema.
L'evidenza che conta. Non è il modello che dice qualcosa che non dovrebbe. È il modello che esegue qualcosa che non dovrebbe: una chiamata a uno strumento non autorizzata, un dato che ha attraversato un confine di tenant, un'azione di scrittura innescata da testo di terzi.
LLM02 — Gestione insicura dell'output
Cos'è. L'output del modello viene consumato a valle senza validazione — e diventa XSS, SSRF, command injection o SQL injection.
Cosa testare. Segui l'output. Viene renderizzato in HTML? Passato a una shell? Interpolato in una query? Usato come URL? Ognuna di queste destinazioni è una vulnerabilità tradizionale con un nuovo punto d'ingresso.
Perché conta. È la categoria che converte un problema di IA in RCE. Tratta l'output del modello esattamente come tratti l'input non attendibile di un utente — perché è quello che è.
LLM03 — Avvelenamento dei dati di addestramento
Cos'è. Manipolazione dei dati di pre-training, fine-tuning o embedding per introdurre bias o backdoor.
Cosa testare. Nelle valutazioni applicative il bersaglio pratico raramente è il pre-training — è il corpus di embeddings. Chi può scrivere nel vector store? Un ticket di supporto inviato da un cliente finisce indicizzato? Se sì, il controllo di accesso in scrittura all'indice è un controllo di sicurezza di primo ordine.
LLM04 — Denial of service del modello
Cos'è. Operazioni che degradano le prestazioni, gonfiano i costi o mandano giù il servizio.
Cosa testare. Esaurimento della finestra di contesto, prompt ricorsivi, espansione incontrollata delle chiamate agli strumenti. Misura il costo, non solo la latenza: nelle architetture con agenti un singolo input può innescare una cascata di chiamate a pagamento.
LLM05 — Supply chain
Cos'è. Modelli pre-addestrati, dataset, plugin ed estensioni di terze parti che portano con sé vulnerabilità.
Cosa testare. Provenienza dei pesi, verifica di integrità, formato di serializzazione, permessi dei plugin installati. La domanda di audit è diretta: se il repository di origine del modello venisse compromesso oggi, te ne accorgeresti?
LLM06 — Divulgazione di informazioni sensibili
Cos'è. Esposizione di PII, segreti o system prompt tramite risposte o canali laterali.
Cosa testare. Fuga del system prompt (sottovalutata — è la mappa degli strumenti e dei limiti), fuga tra tenant in contesto condiviso, PII recuperata da documenti che l'utente non dovrebbe raggiungere. Verifica il controllo di accesso nel recupero, non solo nell'interfaccia.
LLM07 — Design insicuro dei plugin
Cos'è. Integrazioni di strumenti che permettono azioni non autorizzate o esecuzione di codice.
Cosa testare. Ogni plugin come un'API senza autenticazione, perché in pratica è così: chi autorizza la chiamata è il modello, e il modello è influenzabile dal testo. Parametri validati? Ambito verificato per utente o ereditato dal servizio? Un plugin che gira con credenziale di servizio trasforma qualsiasi injection in escalation.
LLM08 — Agency eccessiva
Cos'è. Permessi o autonomia oltre il necessario — sfruttabili per azioni arbitrarie.
Cosa testare. Enumera le capacità reali e confrontale con il caso d'uso dichiarato. Un assistente di sola lettura con permesso di scrittura, un agente di triage con accesso alla produzione, un'integrazione con token di amministratore perché "era più semplice".
Perché conta. Questa categoria è il moltiplicatore di severità di tutte le altre. Ridurre l'agency è la mitigazione con il miglior rapporto costo-beneficio nella sicurezza dell'IA — e non dipende dalla capacità del modello di resistere a nulla.
LLM09 — Dipendenza eccessiva
Cos'è. Fidarsi dell'output del modello senza validazione — decisioni sbagliate, codice vulnerabile, disinformazione.
Cosa testare. È tanto controllo di processo quanto tecnico. Esiste una revisione umana dove la decisione ha conseguenze? Il codice generato passa dallo stesso gate di sicurezza del codice scritto a mano? Nei flussi finanziari o clinici, il modello decide o raccomanda?
LLM10 — Furto del modello
Cos'è. Estrazione, replicazione o esfiltrazione non autorizzata di modelli e pesi proprietari.
Cosa testare. Estrazione tramite query di massa, accesso diretto all'artefatto dei pesi, esposizione dell'endpoint di model serving. Per la maggior parte delle aziende che consumano modelli di terze parti questa è la categoria a minore priorità — il che non significa che i controlli di archiviazione e accesso possano essere ignorati.
Dove si concentra davvero la severità
Nelle valutazioni che conduciamo, i rilievi critici si raggruppano in tre categorie: LLM02 (gestione dell'output), LLM07 (design dei plugin) e LLM08 (agency eccessiva). Le tre condividono una caratteristica: non sono difetti del modello. Sono difetti dell'applicazione attorno al modello.
Questo ha una conseguenza pratica scomoda. Cambiare il modello con uno più allineato non ne risolve nessuna. Ciò che risolve è l'architettura — validazione dell'output, ambito di autorizzazione per utente, principio del minimo privilegio sugli strumenti.
LLM01 resta la categoria con il maggior volume di rilievi. Ma il volume non è severità: una prompt injection isolata, in un sistema senza agency e con output validato, è una seccatura. Una prompt injection in un agente con permesso di scrittura e strumenti con credenziale di servizio è compromissione.
Dal report alla decisione
Un test OWASP LLM Top 10 che consegna dieci sezioni e un elenco di rilievi non risolve il problema del CISO, che è l'ordine di correzione. Ciò che colma questa lacuna:
- Evidenza riproducibile per ogni rilievo — il payload, la risposta, l'effetto osservabile. Se non si riproduce, non è un rilievo.
- Classificazione per impatto sul business, non per categoria OWASP. LLM08 in un chatbot pubblico e LLM08 in un agente con accesso all'ERP non sono lo stesso rischio.
- Collegamento con la kill chain. Un rilievo che permette solo la fase 1 è diverso da uno che concatena fino all'esfiltrazione.
Il Top 10 è una buona mappa di copertura. Non è, da solo, un programma di sicurezza.
Il nostro pentest di IA/LLM copre le dieci categorie con PoC riproducibile e classificazione AI-VRM. Vedi anche la Promptware Kill Chain per il modello di concatenamento dei rilievi.