Il pentest di IA è il penetration testing applicato a sistemi costruiti su modelli di linguaggio — chatbot, agenti autonomi e pipeline RAG. Simula attacchi reali per trovare falle come prompt injection, fuga di dati e abuso di strumenti prima che lo faccia un avversario, con evidenza riproducibile e severità classificata per impatto sul business.
Il termine prende in prestito l'etichetta dal penetration testing tradizionale, ma la pratica differisce in quasi tutto ciò che conta. Un pentest di applicazione web presuppone una frontiera netta tra codice e dati; un pentest di IA parte dalla premessa opposta. Questa guida spiega cosa significa quel cambiamento nella pratica, come si conduce l'esercizio, quali sistemi ne hanno bisogno e dove entrano le categorie dell'OWASP LLM Top 10 2025.
Cos'è esattamente il pentest di IA?
Il pentest di IA è la valutazione offensiva di un sistema che usa un modello di linguaggio per prendere decisioni, generare testo o attivare azioni. L'obiettivo non è misurare la qualità delle risposte del modello, bensì dimostrare come un attaccante manipola il sistema attorno ad esso: l'interfaccia, gli strumenti connessi, le fonti di dati e i permessi della sessione.
La differenza di fondo sta nella frontiera tra codice e dati. Nel software tradizionale, un binario esegue istruzioni e un file di configurazione fornisce parametri; lo sfruttamento avviene quando l'attaccante riesce a spostare dati sul lato del codice. In un LLM, quella separazione non esiste. Il system prompt, l'input dell'utente, il documento recuperato da un vector store e l'output di uno strumento raggiungono il modello attraverso lo stesso canale: testo. Il modello non ha un meccanismo strutturale per distinguere l'istruzione legittima dell'operatore da un'istruzione piantata dentro un PDF che la pipeline ha appena indicizzato.
La conseguenza pratica è diretta: ogni dato che entra nel contesto è potenzialmente eseguibile. Un pentest di IA testa esattamente questa realtà invece di ignorarla.
Come funziona un pentest di IA?
Un pentest di IA segue fasi che vanno dalla mappatura della superficie alla dimostrazione dell'impatto. Ogni fase produce evidenza riproducibile, non solo una risposta indesiderata del modello. I passi che applichiamo, in ordine:
- Mappatura della superficie. Documentare endpoint, autenticazione, limiti di frequenza, il system prompt completo, ogni strumento che il modello può invocare, la pipeline RAG e il flusso di dati — cosa entra nel contesto, cosa esce, cosa viene persistito. Senza questa mappa, il test diventa tentativi ed errori contro una scatola nera.
- Accesso iniziale. Provare che un'istruzione dell'attaccante raggiunge il modello — tramite prompt injection diretto (l'utente è l'attaccante) o indiretto (l'istruzione arriva dentro un documento, una email, un ticket o una pagina che il sistema consuma).
- Escalation dei privilegi. Aggirare i guardrail, estrarre il system prompt e sbloccare chiamate di strumento che dovrebbero essere riservate all'operatore.
- Ricognizione. Enumerare le capacità reali: quali strumenti l'agente invoca, quali fonti di dati raggiunge, quali credenziali rientrano nell'ambito della sessione.
- Persistenza. Verificare se esiste un luogo scrivibile che il modello rilegge in seguito — memoria a lungo termine, documenti nel vector store, regole di progetto — e usarlo per sopravvivere alla fine della sessione.
- Azione sull'obiettivo. Dimostrare l'impatto concreto: esfiltrazione di dati, un'azione di scrittura non autorizzata, movimento laterale verso l'ambiente tradizionale o frode.
- Rendicontazione. Consegnare un percorso di attacco con evidenza in ogni passo, severità per impatto sul business e un ordine di correzione giustificato.
Ciò che separa un pentest serio da una batteria di prompt avversariali è dove si ferma. Eseguire cinquanta jailbreak e riportare che "il modello è vulnerabile al prompt injection" misura solo la fase 2. Il valore sta nel mostrare cosa farebbe un avversario dopo.
Quali sistemi di IA hanno bisogno di pentest?
Ha bisogno di pentest di IA ogni sistema in cui un modello di linguaggio influisce su dati sensibili, attiva strumenti o prende decisioni che riguardano gli utenti. Nella pratica, tre architetture concentrano il rischio:
- Chatbot e assistenti. Interfacce conversazionali esposte a clienti o dipendenti. Il rischio cresce con l'accesso: un chatbot che risponde solo a domande è una superficie piccola; uno che consulta dati di account, apre ticket o elabora pagamenti è un'altra cosa. Qui testiamo fuga tra utenti, estrazione del system prompt e azioni attivate dal testo.
- Agenti autonomi. Sistemi che pianificano ed eseguono compiti con più chiamate di strumento, spesso senza revisione umana a ogni passo. Sono l'architettura di severità più alta, perché l'autonomia moltiplica l'impatto di qualsiasi injection. Nelle pipeline multi-agente, un agente si fida dell'output di un altro per lo stesso motivo per cui si fida dell'input dell'utente — è tutto testo.
- Pipeline RAG. Sistemi che recuperano documenti da un vector store e li iniettano nel contesto. Il punto critico raramente è il modello; è chi può scrivere nell'indice. Se un ticket di supporto inviato da un cliente finisce indicizzato, il controllo di accesso in scrittura al vector store diventa un controllo di sicurezza di primo ordine.
La domanda che definisce l'ambito non è "usiamo l'IA?", ma "cosa raggiunge questo sistema quando qualcuno lo convince ad agire?".
Cosa copre l'OWASP LLM Top 10 2025?
L'OWASP LLM Top 10 (revisione 2025) organizza i rischi più rilevanti delle applicazioni con LLM in dieci categorie. Funzionano come la spina dorsale dell'ambito di un pentest di IA:
- LLM01 — Prompt Injection. Input manipolati che alterano il comportamento del modello o attivano azioni non intenzionali; include il vettore indiretto, il più sfruttato negli incidenti reali.
- LLM02 — Sensitive Information Disclosure. Esposizione di PII, segreti o dati di altri utenti tramite risposte o canali laterali.
- LLM03 — Supply Chain. Modelli, dataset, plugin ed estensioni di terze parti che portano vulnerabilità o provenienza compromessa.
- LLM04 — Data and Model Poisoning. Manipolazione di dati di addestramento, fine-tuning o embedding per introdurre bias o backdoor.
- LLM05 — Improper Output Handling. Output del modello consumato a valle senza validazione, che diventa XSS, SSRF, iniezione di comandi o di SQL — la categoria che converte un problema di IA in RCE.
- LLM06 — Excessive Agency. Permessi o autonomia oltre il necessario, sfruttabili per azioni arbitrarie; il moltiplicatore di severità di tutte le altre.
- LLM07 — System Prompt Leakage. Fuga del system prompt, che descrive strumenti, limiti di autorizzazione e la struttura dei dati accessibili — la mappa della rete in linguaggio naturale.
- LLM08 — Vector and Embedding Weaknesses. Falle nel modo in cui gli embedding sono generati, archiviati e recuperati, incluso il controllo di accesso al recupero e la fuga tra tenant.
- LLM09 — Misinformation. Output errati o fabbricati trattati come affidabili dai sistemi o dagli utenti a valle.
- LLM10 — Unbounded Consumption. Operazioni che degradano le prestazioni, gonfiano i costi o mettono giù il servizio — nelle architetture con agenti, un singolo input può attivare una cascata di chiamate a pagamento.
Coprire le dieci categorie non significa leggere le dieci descrizioni. Significa avere, per ciascuna, un obiettivo concreto nel sistema ed evidenza di sfruttamento o della sua assenza.
Pentest di IA e pentest tradizionale: qual è la differenza?
Il pentest di IA e il pentest tradizionale condividono l'obiettivo — trovare le falle prima dell'attaccante — ma divergono in premessa, vettore ed evidenza. La tabella riassume dove i due si separano:
| Dimensione | Pentest tradizionale | Pentest di IA |
|---|---|---|
| Frontiera codice/dati | Ben definita | Assente — tutto è testo sullo stesso canale |
| Vettore principale | Iniezione via parametri e protocolli | Prompt injection diretto e indiretto |
| Superficie di persistenza | File, database, account | Memoria dell'agente, embedding, contesto |
| Determinismo | Alto — stesso input, stesso output | Basso — risposte probabilistiche |
| Evidenza che conta | Payload che produce una risposta del sistema | Payload che fa eseguire un'azione al modello |
| Ambito dei dati | Definito da permessi espliciti | Ampliato da ciò che il modello raggiunge nella sessione |
L'implicazione per chi acquista è che un pentest di IA non sostituisce il pentest tradizionale — lo completa. Il sistema di IA vive quasi sempre dentro un'applicazione, una rete e un cloud che vanno anch'essi testati. Un percorso di attacco completo spesso comincia in linguaggio naturale e finisce in una vulnerabilità convenzionale.
Quando fare un pentest di IA?
Il momento migliore è prima che il sistema raggiunga dati o azioni sensibili in produzione, e poi in modo ricorrente man mano che la superficie cambia. Trigger concreti che giustificano un test:
- Prima del go-live di qualsiasi sistema di IA che interroghi dati reali, attivi strumenti o parli con i clienti.
- A ogni cambio di agency — quando l'assistente ottiene un nuovo strumento, accesso in scrittura o un'integrazione con credenziale di servizio.
- Alla connessione di una nuova pipeline RAG o all'apertura del vector store a contenuti inviati da terze parti.
- Nei cicli di compliance, quando la governance dell'IA diventa richiesta da regolamentazione settoriale o da norme come la ISO/IEC 42001.
La sicurezza dell'IA non è un test unico al lancio. La superficie è viva: ogni nuovo strumento, ogni fonte di dati aggiunta e ogni cambio di permesso riapre l'ambito.
Come lo esegue Berghem
Berghem conduce il pentest di IA come un esercizio offensivo strutturato, non come una batteria di prompt. Partiamo dalla mappatura della superficie, applichiamo le fasi dall'accesso iniziale all'azione sull'obiettivo e consegniamo un percorso di attacco con evidenza riproducibile in ogni passo, severità per impatto sul business e ordine di correzione prioritizzato per ritorno.
L'ambito è calibrato sul sistema: chatbot, agente autonomo o pipeline RAG ricevono obiettivi e vettori distinti, sempre ancorati alle categorie dell'OWASP LLM Top 10 2025. Per la metodologia completa, l'ambito e il formato di consegna, consulta il nostro servizio di pentest di sistemi di IA e LLM. Quando il rischio si concentra in agenti con autonomia elevata, il lavoro si estende alla sicurezza degli agenti di IA e, sul piano della governance, alla certificazione ISO/IEC 42001.
Domande frequenti
Il pentest di IA è lo stesso del Red Team di IA?
No. Il pentest di IA valuta un sistema con ambito e tempi definiti, coprendo le sue categorie di rischio in modo sistematico. Il Red Team simula un avversario con un obiettivo specifico e senza ambito chiuso, per testare rilevamento e risposta. I due si completano: il pentest mappa le falle, il Red Team misura la capacità di reagire ad esse.
Quanto dura un pentest di IA?
Dipende dalla superficie: numero di strumenti connessi, fonti di dati, integrazioni e livello di autonomia del sistema. Un chatbot con ambito ristretto richiede molto meno sforzo di un agente autonomo con accesso in scrittura a più sistemi. I tempi si definiscono dopo la mappatura iniziale, quando la superficie reale diventa visibile — non con un numero fisso annunciato in anticipo.
Il pentest di IA sostituisce il pentest tradizionale?
No. I due sono complementari. Il sistema di IA vive dentro un'applicazione, una rete e un cloud che vanno anch'essi testati, e un percorso di attacco completo spesso comincia nel prompt injection e finisce in una vulnerabilità convenzionale. L'ideale è combinare il pentest di IA con test di applicazione, API e cloud.
Berghem è un'azienda di sicurezza IA che serve il Brasile e l'America Latina.