Corso di formazione Sviluppare applicazioni AI sicure

Modulo 1 — Come si verificano i guasti nelle applicazioni AI

Laboratorio: nessuno – trattasi di una panoramica architetturale e discussione aperta.

Un modello mentale utile per lo sviluppatore riguardo alle superfici di attacco.

Argomenti trattati:

• Architetture LLM, RAG e agenti viste dallo sguardo dello sviluppatore
• Ciclo di richiesta/risposta tipico di una funzionalità AI
• Fluxo dei prompt: messaggi da sistema, da sviluppatore, dall'utente e dagli strumenti utilizzati
• Punti in cui i dati non attendibili raggiungono il modello o l'output del modello entra nel codice dell'applicazione
• Confini di fiducia stabiliti dallo sviluppatore o ereditati da altri sistemi
• Perché gli attacchi AI sono semantici piuttosto che sintattici
• Correlazione tra la classifica OWASP LLM Top 10 e il codice effettivo da scrivere

Considerazione chiave: ogni istante in cui testi non attendibili entrano nel modello – o viceversa – costituisce un confine di sicurezza da monitorare.

Modulo 2 — Injection di prompt per gli sviluppatori

Laboratorio: Laboratorio 01 — 01-Prompt-Injection

È l'equivalente dell'injection SQL nel mondo AI – ma è impossibile eliminarlo del tutto.

Argomenti trattati:

• Distinguiamo tra injection di prompt diretta e indiretta
• Presenza di istruzioni nascoste all'interno di documenti, pagine web o output provenienti dagli strumenti utilizzati
• Meccanismi di "jailbreak" e confusione delle identità del modello
• Perché è indispensabile separare istruzioni e dati utilizzati nel prompt
• Progettazione difensiva dei prompt: utilizzo di delimiter, struttura logica e limitazione delle autorità concesse al modello
• Perché la prevenzione totale non è possibile – occorre quindi limitarne gli effetti negativi

Esercitazioni pratiche:

• Tentativo di attacco contro il proprio chatbot
• Elusione di un filtro di base implementato nel sistema
• Ristrutturazione del prompt per ridurre la portata dei danni possibili da un eventuale attacco

Modulo 3 — Considerare l'output del modello come input non attendibile

Laboratorio: Laboratorio 02 — 02-Output-Handling

Il problema di sicurezza spesso sottovalutato dagli sviluppatori.

Argomenti trattati:

• L'output del modello deve essere considerato come input non attendibile per il resto dell'app
• Gestione impropria degli output (LLM02): rischi di XSS, SSRF o injection di comandi/SQL nei passaggi successivi del codice
• Non si deve mai valutare, eseguire o renderizzare ciecamente l'output grezzo prodotto dal modello
• Uso di output strutturati e validazione tramite schemi JSON predefiniti
• Codifica degli input generati dal modello e impiego di liste bianche per i valori accettabili
• Rendering sicuro dei contenuti generati in contesti web o UI

Attività pratiche:

• Rilevamento e correzione di un errore legato alla gestione non sicura degli output del modello
• Aggiunta di una validazione mediante schema JSON alle risposte generate dal modello

Modulo 4 — Sicurezza delle pipeline RAG

Laboratorio: Laboratorio 03 — 03-RAG-Security

Una nuova e vastissima superficie di attacco – che però dipende direttamente dalla nostra capacità di progettazione.

Argomenti trattati:

• Rischi legati ai database vettoriali e al processo di recupero delle informazioni
• Sanificazione dei dati durante la fase di ingestimento iniziale
• Provenienza documentale e attribuzione della fiducia ai contenuti analizzati
• Delimitazione dell'ambito di ricerca tramite metadati specifici e suddivisione degli spazi dati
• Presenza di istruzioni nascoste nei testi recuperati dal modello – si tratta di un tipo indiretto di injection di prompt
• Rischio di fuoriuscita non autorizzata di informazioni sensibili tramite il recupero dei dati

Attività pratiche: - Introduciamo un contenuto malevolo in una pipeline RAG per verificare la sua vulnerabilità; poi procediamo con la sanificazione e l'imposizione di limitazioni di ricerca per renderla più sicura

Modulo 5 — Sicurezza degli agenti e dei loro strumenti associati

Laboratorio: Laboratorio 04 — 04-Agent-Safety

Qui un errore nella progettazione si traduce in effetti tangibili e attivi.

Argomenti trattati:

• Agenzia eccessiva concessa agli agenti (LLM06) e possibilità di abuso dei relativi strumenti utilizzati
• Applicazione del principio del minor privilegio per gli agenti stessi
• Solo certi tipi di input o determinati parametri sono consentiti, grazie all'impiego di liste bianche e validazioni specifiche degli argomenti dei comandi eseguiti
• Introduzione di passaggi aggiuntivi per la richiesta di autorizzazione esplicita da parte dell'utente o del supervisore umano<\/li>
• Sandboxing rigoroso dei processi generati dagli agenti durante l'esecuzione dei comandi
• Assegnazione a ciascun agente di credenziali limitate nel tempo e strettamente circoscritte al loro ambito d'operatività
• Limitazioni riguardo al numero massimo di cicli autonomi ripetibili o catene complesse tra più azioni eseguite dall'agente stesso

Esercitazioni pratiche:

• Limitazione delle facoltà di un agente dotato di troppi privilegi iniziali
• Inserimento di una lista bianca insieme a passaggi aggiuntivi di controllo e approvazione per uno strumento molto potente ma rischioso da usare

Modulo 6 — Chiavi segrete, identità utente e costi delle operazioni

Laboratorio: Laboratorio 05 — 05-Secrets-and-Cost

Gli errori operativi generano danni immediati e facilmente misurabili.

Argomenti trattati:

• Gestione sicura delle chiavi API e delle informazioni riservate – evitare di inserirle mai nei prompt, nel codice o nei log utilizzati
• Identificazione utente affidabile per tutte le richieste legate alle funzionalità AI implementate
• Riconduzione della provenienza utente anche in contesti di accesso ai dati tramite strumenti o chiamate verso risorse esterne
• Gestione del "denial-of-wallet": imposizione rigorosa sui limiti massimi di token e costi utilizzabili da un utente particolare
• Impostazione tempestiva di tetti d'uso, limitazioni temporali per l'esecuzione dei processi e controlli sul volume totale delle richieste avviate
• Escuzione sicura dei log – occorre evitare in ogni modo la pubblicazione accidentale di chiavi o dati sensibili

Esercitazioni pratiche:

• Estrazione completa delle informazioni riservate dalle sequenze di prompt e dal codice per trasferirle in posizioni più sicure del sistema
• Definizione precisa dei tetti di spesa consentiti per ogni singolo utente insieme a limiti fissi relativi alla frequenza d'uso

Modulo 7 — Librerie di sicurezza (Guardrail)

Laboratorio: Laboratorio 06 — 06-Guardrails

Quando acquistare librerie pronte all'uso e quando implementarne le funzionalità da zero.

Argomenti trattati:

• Cosa fanno – e cosa invece non possono fare – i framework dedicati alla sicurezza del testo generato da modelli AI
• Sicurezza degli input: rilevamento di injection, informazioni sensibili o contenuti potenzialmente problematici
• Sicurezza degli output prodotti dal modello: controllo e validazione rigorosi nonché verifiche di coerenza e autenticità delle affermazioni formulate
• Scelte pratiche sulla fattibilità dell'adozione di tali controlli: è meglio un layer standardizzato o implementare una logica personalizzata?
• Miscelazione equilibrata tra questi strati aggiuntivi e altre misure difensive già previste nei moduli precedenti del corso
• Analisi imparziale dei loro vantaggi e svantaggi: prestazioni, percentuale di falsi positivi o negativi rilevati e situazioni in cui tali strumenti risultano inefficienti

Esercitazioni pratiche:

• Aggiunta manuale di un layer protettivo sui contenuti in entrata o uscita per la funzionalità AI considerata
• Determinazione rigorosa dei loro risultati, sia positivi che negativi, ossia degli elementi effettivamente rilevati e invece quelli trascurati dal sistema

Modulo 8 — Esecuzione del Red-Teaming sull'applicazione creata

Laboratorio: Laboratorio 07 — 07-Red-Teaming

Facciamo in modo che il codice venga testato come se un aggressore fosse già riuscito a infiltrarlo.

Argomenti trattati:

• Progettazione pratica di pacchetti di test mirati alle vulnerabilità tipiche dei modelli AI e dei sistemi software affini
• Sviluppo di procedure di test automatiche volte a rilevare eventuali casi di injection di prompt o meccanismi jailbreak attivabili da un utente malintenzionato
• Verifica e mantenimento della robustezza dei livelli aggiuntivi previsti per limitare rischi tramite test di regressione periodici
• Integrazione tempestiva di strumenti di verifica della sicurezza AI all'interno del processo CI (Continuous Integration) tipico delle procedure automatizzate
• Gestione attenta e tracciabilità affidabile non solo dei modelli, ma anche delle rispettive dipendenze e librerie necessarie a generare le funzionalità AI previste
• Realizzazione di una lista dettagliata di controlli preliminari da effettuare su qualsiasi soluzione basata sull'AI prima del suo rilascio finale

Esercitazioni pratiche:

• Sviluppo e messa a punto di routine automatizzate di verifica legate alla sicurezza da applicare alle funzionalità AI create
• Integrazione stabile e immediata di tali test in un sistema CI predisposto per l'attivazione continua delle procedure di controllo

Modulo 9 — Valutazione della sicurezza AI: il framework SAIS-100

Laboratorio: nessuno – si tratta solo di un'attività valutativa (utilizziamo l'app del progetto finale).

Tutti gli elementi appresi durante il corso vengono ora tradotti in una metrica misurabile.

Argomenti trattati:

• Il Hexagono della Sicurezza AI: 6 interrogazioni fondamentali al posto di una vaga domanda tipo "è sicuro?"
• Suddivisione chiara del sistema in sei categorie diverse da valutare: Dati, Prompt, Agenti, Supply Chain, Controllo e Governance dei dati prodotti
• Definizione rigorosa di un sistema a 100 punti con relativa ripartizione precisa delle priorità assegnate
• Interpretazione dettagliata degli intervalli che classificano la qualità o l'efficacia della protezione complessiva e delle eccezioni previste per singole categorie di controllo
• Il SAIS-100 rappresenta il nome commerciale attribuito a questo metodo replicabile che consente verifiche strutturate nel tempo
• Calcolo misurabile della differenza tra i livelli di sicurezza prima e dopo interventi specifici volti al miglioramento del sistema

Esercitazioni pratiche:

• Stima puntuale delle prestazioni del progetto finale secondo la scala centesimale prevista dal framework SAIS-100
• Individuazione e descrizione chiara dell'unico intervento apportabile in grado di aumentare concretamente tale valore

Riflessione chiave: i tre elementi che ottengono più importanza statistica nel sistema corrispondono proprio a quei confini di fiducia direttamente controllabili dagli sviluppatori; ne consegue che il punteggio rispecchia perfettamente quanto trattato in questo percorso formativo.

Progetto finale

I partecipanti modificano ed estendono un'applicazione AI originariamente piena di vulnerabilità, rendendola finalmente robusta e adeguata a essere distribuita in produzione.

La versione base fornita comprende:

• Un prompt suscettibile a injection malevolo
• Mancanza di misure adeguate per la gestione corretta dei contenuti prodotti dal modello AI
• Pipeline RAG priva di qualsiasi controllo sulle informazioni importate o recuperate
• Agente potenziato con privilegi ampiamente superiori a quanto necessario
• Presenza di chiavi segrete e dati sensibili nei testi inseriti nel sistema per simulare operazioni reali
• Ausenza totale dei limiti fissati sui costi massimi per ogni utente

Tra gli interventi attesi da parte degli sviluppatori figurano:

• Riformulazione intelligente dei prompt utilizzati, volti a limitare danni e attacchi successivi
• Mantenimento rigoroso della validazione strutturale dei testi generati dal modello AI, unitamente alla loro codifica adeguata per evitare rischi ulteriori
• Attuazione puntuale delle procedure di sanificazione e suddivisione temporanea o spaziale nei documenti recuperati dall'apparato RAG utilizzato
• Controlli aggiuntivi di autorizzazione previsti per l'accesso ai privilegi concessi all'agente, imponendo al tempo stesso controlli manuali di approvazione
• Separazione netta dei dati sensibili e delle credenziali dai testi inseriti e messa in atto rigorosa dei meccanismi per limitare l'uso complessivo da parte degli utenti finali
• Aggiunta di ulteriori componenti dedicati alla protezione del flusso dati, così come sviluppo tempestivo di routine automatiche volte al controllo della sicurezza e a test tipici del red-teaming generale

Il risultato finale da presentare consiste nell'applicazione ormai protetta, insieme a una breve valutazione personale effettuata con i criteri stabiliti dalla classificazione OWASP LLM Top 10.

Mappatura moduli/laboratori

I laboratori vengono eseguiti in sequenza logica e rispecchiano l'ordine cronologico dei nove moduli previsti. Abbiamo complessivamente 7 sessioni sperimentali: i primi due moduli sono solo illustrativi dal punto di vista architetturale, mentre il nono prevede solamente valutazioni misurate senza ulteriori sessioni pratiche.

• Laboratorio 01 - 01-Prompt-Injection: Analisi delle modalità di injection su chatbot e adozione di contromisure efficaci (Modulo 2)
• Laboratorio 02 - 02-Output-Handling: Correzione attenta di un malfunzionamento legato alla gestione non sicura dei contenuti generati dall'IA (Modulo 3)
• Laboratorio 03 - 03-RAG-Security: Test di vulnerabilità introducendo dati nocivi e successivamente attivazione degli strumenti di protezione necessari per una corretta pipeline RAG (Modulo 4)
• Laboratorio 04 - 04-Agent-Safety: Limitazione delle capacità operative esagerate concesse a un determinato agente software (Modulo 5)
• Laboratorio 05 - 05-Secrets-and-Cost: Implementazione di una corretta protezione per le chiavi API e imposizione rigorosa dei vincoli finanziari richiesti (Modulo 6)
• Laboratorio 06 - 06-Guardrails: Inserimento di una barriera addizionale per proteggere sia input che output generati dal sistema AI scelto (Modulo 7)
• Laboratorio 07 - 07-Red-Teaming: Creazione e applicazione tempestiva di routine automatiche per verificare la sicurezza tramite simulazioni offensive tipiche del red-teaming (Modulo 8)

Il Modulo 1 (“Come si verificano i guasti nelle applicazioni AI”) non contempla sessioni sperimentali, in quanto basato esclusivamente su una panoramica architetturale e un confronto aperto; il Modulo 9 è stato invece sviluppato per stimare la sicurezza dell'app con l'ausilio del sistema SAIS-100, non prevedendo laboratori manuali di verifica.