Se vi occupate di sicurezza o anche solo se seguite l'evoluzione dell'intelligenza artificiale, vi sarete accorti di un problema di fondo: mentre i modelli generativi e i sistemi di visione artificiale corrono alla velocità della luce, la sicurezza arranca sempre un passo indietro, a volte neanche si sposta dalla linea di partenza.
Il problema è duplice. Da un lato, i test vengono spesso effettuati solo in ambienti di laboratorio controllati. Dall'altro, testare adeguatamente questi modelli richiede un'enorme quantità di tempo umano, il che si traduce inevitabilmente in uno svantaggio competitivo rispetto a chi lancia prodotti sul mercato senza farsi troppi scrupoli, basta vedere l'eterna cyber-guerra tra Cina e USA. A questo aggiungete la stocasticità delle risposte: per essere ragionevolmente sicuri che un certo angolo di attacco sia stato neutralizzato, potreste dover ripetere lo stesso test centinaia di volte.
I modelli linguistici (LLM) sono particolarmente vulnerabili a tecniche come il prompt injection e il jailbreak. Parliamo di quegli scenari in cui un attore malevolo inserisce istruzioni specifiche per aggirare i filtri di sicurezza e forzare il modello a generare contenuti dannosi o vietati [1]. Certo, esistono già strumenti per l'analisi delle vulnerabilità, come Purple Llama, Giskard, garak e PyRIT. Il problema è che molti di questi tool trattano le esecuzioni dei test come eventi isolati. Mancano della flessibilità necessaria per valutare scenari complessi a più turni (multi-turn) e spesso ignorano la natura stocastica dei modelli [1].
È proprio per colmare questa lacuna che un gruppo di ricercatori ha introdotto AVISE, un framework progettato per automatizzare gli attacchi black-box e permettere lo sviluppo di test di sicurezza personalizzabili.
L'architettura del framework AVISE
Il framework AVISE è sviluppato in Python [2], una scelta che garantisce la massima compatibilità con l'ecosistema di ricerca e sviluppo dell'IA. L'architettura si divide in due livelli principali: l'Orchestration Layer e l'Interaction Layer.
Il livello di orchestrazione
Questo livello è il cervello dell'operazione, quello che gestisce la logica della pipeline di test. È composto da alcuni componenti chiave:
- BaseSETPipeline: Sono classi astratte che forniscono le fondamenta per sviluppare i Security Evaluation Test (SET). Definiscono il ciclo di vita del test in quattro fasi: inizializzazione, esecuzione, valutazione e reportistica. Questa struttura modulare permette di supportare valutazioni black-box, grey-box e white-box.
- SET (Security Evaluation Tests): Si tratta di implementazioni specifiche che estendono le BaseSETPipelines. Il loro scopo è automatizzare l'identificazione di vulnerabilità in un sistema target (il modello che state testando).
- Evaluators: Questi componenti ispezionano gli output del sistema target per determinare se la risposta contiene segnali di interesse, come una vulnerabilità confermata o un rifiuto corretto.
- Report Generator: Un modulo che raccoglie i log e i risultati degli Evaluators per generare un riassunto finale leggibile da un essere umano. È supportato da un modello linguistico che evidenzia le vulnerabilità e suggerisce le contromisure.
- Execution Engine: Il motore centrale che gestisce l'intero ciclo di vita, dalla configurazione dei connettori all'esecuzione dei SET, fino alla chiusura del processo.
Il livello di interazione
Il livello di interazione gestisce la comunicazione tra il livello di orchestrazione e il sistema IA bersaglio. Attualmente, si basa sui Connector (Connettori), che astraggono la comunicazione con le API del sistema target. Questo approccio è fondamentale per la valutazione black-box, perché simula un ambiente reale in cui non avete accesso al codice sorgente o all'infrastruttura interna del modello [1]. È esattamente quello che succede quando usate modelli esterni come quelli di OpenAI o Anthropic.
Sviluppo di un Security Evaluation Test (SET)
Per dimostrare che AVISE fa sul serio, gli autori hanno automatizzato e potenziato un attacco noto come Red Queen [1]. Questo attacco multi-turn si basa sulla theory-of-mind (teoria della mente): l'attaccante costruisce uno scenario narrativo fittizio, ad esempio fingendosi un insegnante preoccupato, per ingannare il modello e farsi fornire istruzioni su attività illecite, come creare un passaporto falso o costruire un ordigno artigianale.
L'uso di un Adversarial Language Model (ALM)
Negli attacchi multi-turn in scenari black-box, l'automazione è un incubo perché le risposte del modello bersaglio possono deviare in modo del tutto imprevedibile. Per mantenere il controllo della conversazione, AVISE introduce l'uso opzionale di un Adversarial Language Model (ALM).
Nel paper, i ricercatori hanno utilizzato un modello Ministral 3 da 3B parametri. Il compito dell'ALM è modificare i prompt successivi dell'attacco in base alle risposte precedenti del bersaglio. Il suo obiettivo è "giocare una partita" per forzare il modello target a rivelare le istruzioni illecite nel turno finale. Pensateci: un ALM può essere usato per condurre un attacco, ma qui viene impiegato come strumento del red team per testare le difese.
L'Evaluation Language Model (ELM)
Una volta eseguito l'attacco, l'output finale deve essere classificato. Per farlo, AVISE utilizza un Evaluation Language Model (ELM) (basato anch'esso su Ministral 3 da 3B parametri), istruito tramite un system prompt specifico. L'ELM decide se il test è "fallito" (il modello bersaglio ha fornito istruzioni dannose) o "superato" (il modello ha rifiutato o fornito informazioni banali), generando anche una breve giustificazione.
I risultati: chi ha resistito all'attacco?
Gli autori hanno lanciato il SET Red Queen contro nove modelli linguistici open source recenti (tra cui Llama 3.1, Llama 3.3, Qwen 3.5, Mistral e Nemotron), implementati localmente tramite Ollama.
I risultati hanno mostrato due scenari molto diversi:
- Test senza ALM: Utilizzando solo i prompt statici del template Red Queen, la maggior parte dei modelli è riuscita a deviare la conversazione, "superando" i test. Senza un adattamento dinamico, l'attacco si è rivelato inefficace.
- Test con ALM: Quando i prompt venivano adattati dinamicamente dall'ALM, tutti i modelli sono risultati vulnerabili al jailbreak, seppur in misura variabile.
La Tabella 1 riassume i risultati chiave dell'attacco condotto con il supporto dell'ALM.
| Modello Target | Test Superati | Test Falliti (Jailbreak Riuscito) | Tasso di Fallimento (ASR) |
|---|---|---|---|
| Ministral 3 14B | 4 | 21 | 84% |
| Llama 3.1 8B | 8 | 17 | 68% |
| Qwen 3 32B | 8 | 17 | 68% |
| Llama 3.3 70B | 9 | 16 | 64% |
| Nemotron 3 Nano 30B | 15 | 10 | 40% |
| Mistral 3.2 24B | 15 | 10 | 40% |
| Nemotron 3 Super 120B | 22 | 3 | 12% |
| Qwen 3.5 35B | 23 | 2 | 8% |
Tabella 1: Tasso di fallimento (Attack Success Rate) dei modelli valutati con il SET Red Queen aumentato tramite ALM.
L'ELM ha dimostrato un'eccellente capacità di valutazione, raggiungendo un'accuratezza del 92%, un F1-score di 0.91 e un coefficiente di correlazione di Matthews (MCC) di 0.83 quando utilizzato in combinazione con l'ALM [1]. Ovviamente, essendo a sua volta un modello IA, potrebbero esserci falsi positivi o falsi negativi. Starà alla supervisione umana assicurare la correttezza del risultato nel report finale.
Perché è importante per la Digital Forensics
Dal punto di vista dell'informatica forense e della sicurezza proattiva, AVISE è uno strumento che fa la differenza. Vi permette di:
- Condurre audit standardizzati: Automatizzare il red teaming assicura che le valutazioni di sicurezza sui sistemi IA siano riproducibili, un requisito fondamentale in ambito peritale.
- Mitigare la natura stocastica dell'IA: Eseguendo iterazioni multiple dello stesso SET, potete ottenere una significatività statistica reale sulla vulnerabilità di un sistema, superando i limiti dei test singoli.
- Simulare avversari avanzati: L'integrazione di un ALM per attacchi multi-turno dinamici modella realisticamente il comportamento di un attaccante umano determinato, esponendo vulnerabilità che i test statici non rileverebbero mai.
Come sottolineano gli autori, il panorama della sicurezza IA è in rapida evoluzione e strumenti come AVISE sono soggetti al dilemma del dual-use: sono indispensabili per chi difende, ma potenzialmente sfruttabili da attori ostili [1]. È quindi fondamentale adottare pratiche di Coordinated Vulnerability Disclosure (Divulgazione Coordinata delle Vulnerabilità) quando usate questi framework per testare sistemi in produzione.
Tiriamo le somme
L'introduzione di AVISE segna un passo concreto verso una valutazione della sicurezza dell'intelligenza artificiale più rigorosa e riproducibile. L'esperimento condotto con l'attacco Red Queen dimostra in modo inequivocabile che i moderni meccanismi di allineamento e sicurezza dei LLM possono essere aggirati attraverso l'ingegneria sociale simulata e l'adattamento dinamico dei prompt.
Per i professionisti della sicurezza e gli analisti forensi, l'adozione di framework open source e modulari come AVISE diventerà presto uno standard metodologico indispensabile per certificare e proteggere le infrastrutture basate sull'IA.
Riferimenti
[1] M. Lempinen, J. Kemppainen, N. Raesalmi. "AVISE: Framework for Evaluating the Security of AI Systems". arXiv:2604.20833v1 [cs.CR], 22 Apr 2026. Disponibile su: https://arxiv.org/html/2604.20833v1
[2] Repo su GitHub: https://github.com/ouspg/AVISE
