AI Penetration Test: come si verifica davvero la sicurezza di un sistema di AI aziendale

Un AI penetration test mette alla prova un sistema di intelligenza artificiale in condizioni avversarie, cercando i comportamenti che chi lo ha costruito non aveva previsto. Il bersaglio è il sistema aziendale nel suo insieme, dai system prompt ai permessi concessi agli agenti.

Il 23 marzo 2026 il Center for AI Standards and Innovation del NIST ha pubblicato i risultati di una competizione di red teaming condotta insieme a Gray Swan e allo UK AI Security Institute. Oltre 400 partecipanti hanno lanciato più di 250.000 tentativi di attacco contro tredici modelli di frontiera in scenari agentici, dagli assistenti che usano strumenti esterni agli agenti di scrittura codice fino a quelli che controllano un computer.

1. Che cos’è un AI penetration test
2. Cosa si testa davvero in un AI penetration test
3. Le vulnerabilità che emergono e il caso EchoLeak
4. Come si svolge un AI penetration test
5. Cosa chiede la normativa

Tutti e tredici hanno ceduto almeno una volta. Il dettaglio che merita attenzione riguarda una correlazione mancante: la sicurezza di un modello non seguiva la sua capacità, quindi i sistemi più potenti non risultavano i più difficili da aggirare.

Per un’azienda che ha portato l’intelligenza artificiale nei propri processi, quel numero ha una lettura pratica. Il modello scelto è soltanto uno dei pezzi. Quello che decide la tenuta del sistema è il modo in cui lo avete collegato ai dati, agli strumenti interni e ai permessi di chi lo usa. Da qui nasce l’AI penetration test, l’attività che verifica in condizioni avversarie un sistema di AI aziendale nel suo insieme. Vediamo cosa comprende, quali standard lo governano, come si svolge e cosa chiede la normativa europea, pienamente applicabile dal 2 agosto 2026.

Ma come sempre, andiamo con ordine e affrontiamo per gradi l’argomento.

Che cos’è un AI penetration test

Un AI penetration test è un’attività autorizzata di sicurezza offensiva che mette alla prova un sistema basato su intelligenza artificiale, con l’obiettivo di indurlo a comportamenti che chi lo ha progettato non aveva previsto. Appartiene alla famiglia più ampia dell’AI red teaming e ne condivide il metodo, con una differenza di perimetro. Il penetration test lavora su un bersaglio delimitato e concordato, mentre il red teaming simula una campagna avversaria completa che coinvolge anche la capacità di rilevamento del team di sicurezza.

La distanza da un penetration test classico sta nella natura delle falle. Una vulnerabilità tradizionale nasce da un errore di programmazione oppure da una configurazione sbagliata, quindi esiste una firma che la identifica. Una falla di un sistema AI nasce spesso da un comportamento del modello, che resta conforme al codice mentre esegue qualcosa che nessuno desiderava. Poiché manca una firma da cercare, gli strumenti di scansione automatica passano oltre senza segnalare nulla.

C’è poi un equivoco da sciogliere subito, dato che condiziona l’intera attività. Il bersaglio del test è il vostro sistema, ossia i system prompt che avete scritto, le integrazioni con gli strumenti aziendali, la pipeline RAG collegata ai vostri documenti, i guardrail impostati e il modello di permessi che regola cosa l’AI può raggiungere. I modelli di base forniti da OpenAI, Anthropic oppure Google vengono già messi alla prova dai provider stessi, con squadre dedicate e risorse fuori portata per qualsiasi azienda cliente.

Cosa si testa davvero in un AI penetration test

Un sistema di AI aziendale si compone di livelli distinti, ognuno con debolezze proprie. Un test completo li attraversa tutti, poiché la falla più costosa nasce di solito nel punto di contatto fra due livelli.

• Il modello e i suoi guardrail. Si verifica la tenuta dei filtri di sicurezza sotto attacchi diretti e multi-turno, comprese le tecniche che manipolano la cronologia della conversazione come il sockpuppeting.
• Il livello di integrazione. Comprende le API di accesso al modello, le chiamate a strumenti esterni, i plugin e i server MCP. Qui si controlla se un utente riesce a iniettare contenuto in ruoli che non gli appartengono oppure a far invocare strumenti oltre l’intenzione originale.
• Il livello dei dati. Riguarda gli archivi documentali collegati al sistema, i database vettoriali e gli embedding. Un solo documento ostile inserito nella base di conoscenza può orientare le risposte, con una dinamica vicina a quella dell’AI poisoning.
• I confini dell’agente. Per i sistemi che compiono azioni si misura fin dove l’agente può arrivare, quali operazioni irreversibili ha il potere di eseguire e cosa accade quando un contenuto esterno riscrive il suo obiettivo a metà del compito.
• L’applicazione tradizionale attorno. Autenticazione, autorizzazione, gestione dell’output e isolamento fra utenti restano temi classici. Un sistema AI perfettamente allineato resta vulnerabile se il portale che lo espone mostra a un utente la sessione di un altro.

Le vulnerabilità che emergono e il caso EchoLeak

Le vulnerabilità che un AI penetration test porta a galla hanno una classificazione consolidata. La OWASP Top 10 for LLM Applications nell’edizione 2025 colloca la prompt injection al primo posto e ha introdotto due voci nuove, ossia il System Prompt Leakage e le debolezze su vettori ed embedding. Nella stessa revisione Overreliance è diventata Misinformation, Model DoS si è allargata in Unbounded Consumption ed Excessive Agency ha visto ampliato il proprio perimetro. Per i sistemi che agiscono esiste dal 2026 una lista dedicata, la OWASP Top 10 for Agentic Applications, dove la prompt injection indiretta è la prima categoria di rischio.

Accanto a OWASP lavorano altri due riferimenti. MITRE ATLAS mappa tattiche e tecniche avversarie contro i sistemi di machine learning, con la stessa logica che ATT&CK applica alle infrastrutture tradizionali. Il NIST AI 100-2 E2025 definisce la tassonomia degli attacchi di adversarial machine learning, mentre il NIST AI 600-1 raccomanda il red teaming prima e dopo il rilascio su dodici categorie di rischio.

Il caso che ha reso concreta questa materia porta il nome di EchoLeak. Si tratta della vulnerabilità CVE-2025-32711 su Microsoft 365 Copilot, con punteggio CVSS 9.3, individuata dai ricercatori di Aim Labs e corretta da Microsoft con un intervento lato server. È il primo exploit zero-click confermato contro un agente AI in produzione: una singola email costruita ad arte poteva esfiltrare dati da posta, chat Teams e SharePoint senza alcuna interazione dell’utente.

Il valore didattico sta nella catena. L’attacco superava il classificatore XPIA di Microsoft, aggirava la redazione dei link usando Markdown in stile riferimento, sfruttava il caricamento automatico delle immagini e abusava di un proxy Teams già ammesso dalla content security policy. Nessuno di questi passaggi era una falla di intelligenza artificiale in senso stretto. Il risultato complessivo attraversava tutti i confini di fiducia del sistema.

Ma non si è trattato di un episodio isolato. Infatti, nell’agosto 2025, GitHub Copilot e Visual Studio Code sono risultati vulnerabili a esecuzione di codice remoto tramite prompt injection, con la CVE-2025-53773 e un punteggio CVSS di 7.8. Sul fronte delle indagini aziendali, il CISO AI Risk Report 2026 di Saviynt riporta che il 47% dei CISO ha osservato agenti AI con comportamenti non voluti, mentre soltanto il 5% si sente in grado di contenere un agente compromesso.

Come si svolge un AI penetration test

Un AI Penetration Test si suddivide in cinque fasi, riconoscibili in tutte le attività condotte con criterio.

• Ricognizione. Si ricostruisce l’architettura del sistema, dai modelli impiegati agli strumenti collegati, dalle fonti dati ai permessi concessi. Serve anche a definire con il cliente cosa è dentro il perimetro del test e quali azioni restano escluse, soprattutto per gli agenti capaci di operazioni irreversibili.
• Generazione degli attacchi. Si costruiscono i casi di prova sulle categorie di rischio pertinenti, con varianti a turno singolo e a più turni. Le tecniche multi-turno risultano quasi sempre più efficaci, poiché preparano il terreno prima della richiesta vera.
• Esecuzione. Gli strumenti automatici coprono l’ampiezza, dal PyRIT di Microsoft a Garak fino alle piattaforme di valutazione più recenti. Gli analisti umani coprono la profondità, che comprende gli abusi legati al dominio specifico dell’azienda e le catene di più passaggi.
• Validazione. Ogni risultato viene riprodotto e documentato con le prove raccolte, per separare i comportamenti effettivamente sfruttabili dalle risposte anomale prive di conseguenze.
• Correzione e nuovo test. Il documento finale indica gli interventi in ordine di priorità, con una verifica successiva che conferma la chiusura. Su questi sistemi conviene lasciare in eredità una batteria di test di regressione, da rieseguire a ogni cambio di modello, di system prompt oppure di strumenti collegati.

Quest’ultimo punto merita una precisazione. Un sistema di AI cambia comportamento anche senza che nessuno tocchi il codice, poiché basta un aggiornamento del modello lato provider. Una verifica annuale non regge il passo, mentre una batteria di test riutilizzabile trasforma il controllo in una pratica ripetibile.

Cosa chiede la normativa

Dal 2 agosto 2026 l’AI Act europeo è pienamente applicabile, con il regime sanzionatorio dell’articolo 99 che arriva a 35 milioni di euro oppure al 7% del fatturato mondiale annuo. Due articoli interessano da vicino chi si occupa di sicurezza. L’articolo 9 impone sistemi di gestione del rischio che comprendono test di robustezza avversaria. L’articolo 15 richiede resistenza ai tentativi di sfruttamento delle vulnerabilità da parte di terzi non autorizzati.

La lettura combinata dei due porta a una conclusione operativa. Per i sistemi ad alto rischio la verifica avversaria smette di essere una buona pratica volontaria e diventa un adempimento documentabile, con tutto quello che comporta in termini di prove da conservare.

Sul piano nazionale si aggiunge la Legge 132/2025, che all’articolo 3 comma 5 chiarisce di non introdurre obblighi ulteriori rispetto al regolamento europeo. La norma italiana lavora sugli spazi lasciati aperti, dalla individuazione delle autorità competenti alle procedure di controllo, rimandando a decreti attuativi la definizione delle procedure tecniche di valutazione e la ripartizione della governance tra AgID e ACN. Per le aziende questo significa muoversi oggi sui principi generali, con la prospettiva di requisiti più dettagliati nei prossimi mesi.

In conclusione

Un AI penetration test verifica quello che l’azienda ha costruito attorno a un modello, dai system prompt ai permessi concessi agli agenti. I risultati della competizione NIST di marzo 2026 e il caso EchoLeak indicano la stessa direzione: la tenuta di un sistema di AI dipende dalle scelte di integrazione più che dalla qualità del modello scelto.

Gli standard per condurre queste verifiche esistono e sono maturi, dalla OWASP Top 10 for LLM Applications a MITRE ATLAS fino alle tassonomie NIST. Gli strumenti automatici coprono la parte ripetitiva, mentre gli abusi legati al funzionamento specifico dell’azienda restano terreno di analisti in carne e ossa. Con l’AI Act pienamente applicabile, questa verifica entra anche nel fascicolo della conformità.