Hai messo un LLM davanti ai tuoi clienti o a contatto con i tuoi dati: un chatbot, un assistente interno, una pipeline RAG, un agente che legge email e chiama API. La superficie d’attacco di questi sistemi è nuova — prompt injection, jailbreak, esfiltrazione di dati attraverso le risposte del modello — e le metodologie di penetration test tradizionali non la contemplano. Il punto debole raramente è il modello in sé: è ciò a cui l’applicazione gli permette di accedere, e con quali controlli. Prima di fidarti di ciò che l’AI può fare, devi sapere cosa le si può far fare.
Dove si rompono davvero le applicazioni AI
La prompt injection è il rischio numero uno — LLM01 — della OWASP Top 10 for LLM Applications, edizione 2025, lo standard su cui mappiamo ogni test. Ma le categorie restano astratte finché non diventano scenari. Una pipeline RAG che indicizza troppo e restituisce a un utente documenti fuori dal suo perimetro. Un agente con permessi più ampi del necessario, indotto a compiere azioni che nessuno gli ha chiesto. Un’injection indiretta: il modello legge un contenuto esterno — una pagina web, un documento caricato — che contiene istruzioni scritte per lui, e le esegue. In nessuno di questi casi il modello è stato compromesso: ha fatto esattamente ciò che l’applicazione gli consentiva di fare. Per i sistemi agentici adottiamo anche la lista complementare OWASP Top 10 for Agentic Applications (dicembre 2025), che copre permessi eccessivi, abuso degli strumenti e azioni irreversibili senza supervisione umana.
Il quadro italiano rende il tema concreto: quando la shadow AI — l’uso di strumenti AI senza policy né controlli — entra in una violazione, aggiunge in media 161.541 euro al costo (IBM Cost of a Data Breach 2025).
Come si testa un sistema che non risponde mai allo stesso modo
Un attacco respinto al primo tentativo può passare al decimo: i modelli generativi non sono deterministici, e un esito singolo non fa evidenza. Per questo combiniamo attacchi automatizzati su dataset estesi, ripetuti su molte varianti per misurare con quale frequenza l’attacco riesce, con attacchi manuali costruiti sul contesto della tua applicazione. Il percorso è quello del nostro penetration testing: scoping e threat modeling per definire perimetro e scenari, esecuzione, report, retest dopo le correzioni. Si lavora preferibilmente in staging con dati sintetici; in produzione solo con regole d’ingaggio e finestre concordate per iscritto. È il collaudo di una struttura costruita su un terreno che nessuno ha ancora mappato: il metodo va costruito apposta.
Cosa facciamo
- Penetration test di applicazioni LLM: chatbot pubblici, copilot interni su knowledge base, pipeline RAG su documenti sensibili, agenti con accesso a strumenti e API
- Test di prompt injection diretta e indiretta, jailbreak e tecniche di evasione dei guardrail
- Verifica dell’esfiltrazione: cosa può uscire dal modello, dai documenti indicizzati e dalle integrazioni collegate
- Red teaming di scenario sull’intera catena: modello, orchestrazione, integrazioni, permessi
- Hardening e contromisure, su richiesta: irrobustimento del system prompt, filtri su input e output, allow-list degli strumenti a disposizione degli agenti, supervisione umana sulle azioni irreversibili, tracciamento e rilevamento delle injection
- Regression testing ricorrente: ogni cambio di modello, system prompt o integrazione riapre la superficie, e la baseline del primo assessment permette di ritestare solo ciò che è cambiato
Cosa ottieni
- Un report tecnico con vulnerabilità riproducibili: le trascrizioni delle conversazioni d’attacco come proof of concept, con severità valutata sul contesto
- La matrice di copertura sulle categorie OWASP, spendibile nei vendor assessment dei tuoi clienti e come documentazione tecnica a supporto della gestione del rischio per l’AI Act, insieme al servizio Compliance AI Act
- Un executive summary per chi decide budget e tempi
- Un piano di remediation con retest, e una baseline riutilizzabile per i test successivi
I momenti in cui questo test pesa di più: prima del go-live, dopo un cambio di modello o di fornitore, prima di dare al sistema accesso a dati personali, quando un cliente enterprise chiede garanzie in un vendor assessment. A condurlo è la stessa squadra offensiva del nostro pilastro cybersec — la stessa che mette alla prova ciò che costruiamo con Integrazione AI. Se stai portando un sistema AI in produzione, o ce l’hai già, scrivici: definiamo insieme perimetro, scenari e tempi.
// domande frequenti
Facciamo già un penetration test ogni anno: questo è un doppione?
No. Il penetration test tradizionale verifica infrastruttura e applicazioni dal comportamento prevedibile: rete, server, codice. Qui si testa il comportamento di un modello non deterministico e ciò a cui l'applicazione gli permette di accedere: prompt injection, jailbreak, esfiltrazione di dati attraverso le risposte. Sono superfici che le metodologie classiche non contemplano: i due test si completano, non si sovrappongono.
Il modello è di un grande fornitore: la sicurezza non è già inclusa?
Il fornitore protegge il modello di base e la sua infrastruttura. Tutto ciò che ci costruisci intorno — system prompt, documenti indicizzati, permessi, strumenti collegati, integrazioni — è responsabilità di chi realizza l'applicazione, ed è lì che nasce la maggior parte delle vulnerabilità reali: un modello sicuro dentro un'applicazione che gli concede troppo resta un sistema attaccabile.
Il test può danneggiare il sistema o esporre dati reali?
Le regole d'ingaggio si definiscono per iscritto prima di iniziare: perimetro, scenari ammessi, gestione dei dati. Quando possibile si lavora in un ambiente di staging con dati sintetici; in produzione solo con finestre e limiti concordati. Le evidenze raccolte restano riservate e non escono dal perimetro del test.
Quanto dura e quanto costa un assessment di AI security?
Dipende dal perimetro: numero di applicazioni, presenza di agenti e integrazioni, scenari da coprire, ambiente di test disponibile. Sono gli stessi fattori che determinano sia la durata sia il costo. Per questo si parte da uno scoping che fissa obiettivi, tempi e preventivo prima dell'avvio: la presenza di agenti e l'assenza di un ambiente di staging sono ciò che incide di più.
Ogni quanto va ripetuto il test?
A ogni cambio significativo: nuovo modello o fornitore, modifiche al system prompt, nuove integrazioni o strumenti collegati, nuove fonti di dati indicizzate. Ognuno di questi interventi riapre la superficie d'attacco. L'assessment iniziale produce una baseline su cui impostare regression test ricorrenti, mirati su ciò che è cambiato invece di ripartire da zero.
Il report vale per l'AI Act o per i vendor assessment dei nostri clienti?
Non è una certificazione di conformità, ma è un'evidenza tecnica utile in entrambi i casi. I risultati sono mappati sulla OWASP Top 10 for LLM Applications (ed. 2025), riferimento internazionale riconosciuto: il report è spendibile nelle due diligence dei clienti enterprise e come documentazione tecnica a supporto della gestione del rischio dei sistemi AI, da inquadrare nel percorso di conformità insieme al servizio Compliance AI Act di CyberQuake.