Un penetration tester di un grande istituto finanziario europeo ha scoperto a inizio 2026 che bastava una frase nascosta in un PDF per far esfiltrare a un assistente AI aziendale i riepiloghi dei conti dei clienti verso un webhook esterno. Nessun alert nel SIEM, nessun log sospetto. Solo a marzo, una banca europea ha perso oltre 4,7 milioni di euro dopo che una fattura PDF avvelenata ha convinto un agente AI addetto al KYC a bypassare un controllo sanzioni. Sono due dei tanti episodi che nel 2026 hanno spinto i team di sicurezza a chiedersi come si testa davvero un modello linguistico prima di metterlo in produzione. Tre strumenti open source dominano questa conversazione: Garak di NVIDIA, PyRIT di Microsoft e Giskard. Questo confronto mette a fianco specifiche, prezzi, benchmark di adozione e casi reali per capire quale scegliere, in che ordine e per quale scenario aziendale.
Perché il red teaming per l’AI è diventato una priorità nel 2026
Il quadro normativo europeo ha reso il red teaming un obbligo, non più una buona pratica. L’AI Act richiede test di robustezza contro attacchi avversari, incluso il prompt injection, per i sistemi ad alto rischio dell’Allegato III entro il 2 agosto 2026. Le aziende che gestiscono credito, sanità o infrastrutture critiche non possono più rimandare la scelta di uno strumento di test.
I numeri raccontano un settore che si muove in ritardo rispetto al rischio. Il report HiddenLayer 2026 sul panorama delle minacce AI segnala che solo il 16% delle organizzazioni ha mai sottoposto i propri modelli a un red team, mentre il 74% dichiara di aver già subito una violazione legata all’AI. Il sondaggio SANS 2025 aveva già rilevato che appena il 15% delle aziende usava l’AI generativa per attività di red teaming, la percentuale più bassa tra tutte le discipline di sicurezza analizzate. Nel giro di un anno la situazione è cambiata: l’aggiornamento SANS 2026 riporta che il 61% dei professionisti oggi usa l’AI nel lavoro di red team, contro il 33% del 2025.
Il mercato dei servizi di AI red teaming è cresciuto da 1,75 miliardi di dollari nel 2025 a 2,26 miliardi nel 2026, con una proiezione a 6,17 miliardi entro il 2030 secondo Business Research Company e Research and Markets. In questo contesto Garak, PyRIT e Giskard non sono tre opzioni intercambiabili. Coprono tre lavori diversi: scansione di vulnerabilità su un singolo modello, orchestrazione di campagne multi-turno, e test continui su agenti e pipeline RAG in produzione.
Chi lavora nella sicurezza applicativa da anni riconoscerà lo schema: prima arriva l’obbligo normativo, poi il mercato si consolida attorno a due o tre strumenti di riferimento. È già successo con gli scanner di vulnerabilità di rete negli anni 2000 e con i tool SAST/DAST dopo il PCI DSS. La differenza, questa volta, è la velocità: dal primo caso pubblico di prompt injection zero-click a un obbligo normativo europeo sono passati poco più di quattordici mesi.
Cos’è il prompt injection e perché fa paura alle aziende europee
Il prompt injection consiste nell’inserire istruzioni nascoste in un input, un documento o una pagina web che il modello elabora, per dirottarne il comportamento senza che l’utente se ne accorga. L’OWASP Top 10 per le applicazioni LLM del 2025 lo classifica come LLM01, la vulnerabilità più critica della lista. Secondo le analisi citate nel documento, gli attacchi di prompt injection riescono nel 50-84% dei tentativi e sono presenti in oltre il 73% delle implementazioni AI in produzione sottoposte a verifica.
La differenza rispetto a una SQL injection classica è che qui non esiste un parametro da sanificare in senso tradizionale: il canale di attacco è il linguaggio naturale stesso, nascosto in un’email, in un PDF o in un ticket di supporto. Un’analisi svizzera sulle difese OWASP LLM Top 10 riporta che il prompt injection è la debolezza più osservata nei penetration test su sistemi LLM, presente in 27 dei 31 progetti analizzati tra il 2025 e il 2026. Ecco perché uno strumento capace di simulare questi attacchi prima del rilascio è diventato indispensabile quanto uno scanner di vulnerabilità di rete lo è sempre stato per le applicazioni web.
Vale la pena distinguere due varianti che spesso vengono confuse. Il prompt injection diretto avviene quando l’attaccante scrive lui stesso l’input malevolo dentro la chat, ad esempio per aggirare un filtro di moderazione. Il prompt injection indiretto, molto più pericoloso nei casi aziendali documentati in questo articolo, nasconde le istruzioni in un documento, una pagina web o un’email che il modello elaborerà più tardi, senza che nessun umano legga mai quel testo prima. La pagina ufficiale dell’OWASP Top 10 per le applicazioni LLM descrive proprio questa seconda variante come il vettore più difficile da individuare con controlli manuali, perché il payload non passa mai per un’interfaccia utente sorvegliata.
Garak di NVIDIA: lo scanner di vulnerabilità open source
Garak nasce come progetto del team AI Red Team di NVIDIA e si comporta come un vero e proprio scanner: punta un modello, lancia un catalogo di probe avversari e restituisce un report su cosa ha ceduto. Le famiglie di probe coprono injection diretta e dirottamento delle istruzioni, jailbreak in stile DAN/STAN/DUDE, payload codificati in Base64, ROT13 o esadecimale per aggirare i filtri, leakage del prompt di sistema e dei dati di training, tossicità, allucinazioni e persino iniezioni XSS nell’output del modello.
Le versioni più recenti, tra la 0.16.0 e la 0.17.0 rilasciate nell’estate e inizio autunno 2026, hanno aggiunto annotazione delle tecniche e dell’intento, scansione sensibile al contesto, un generatore nativo per Anthropic e un probe di attacco adattivo. Il progetto è distribuito con licenza Apache 2.0, completamente gratuito, e secondo un report 2026 sulle statistiche di sicurezza AI ha raggiunto una base che va da oltre 7.300 stelle GitHub nel 2025 a circa 8.900 a metà 2026. Un articolo di approfondimento lo descrive come “la cosa più simile a un Nessus per i modelli linguistici” pensata per chi deve firmare che un chatbot è pronto per la produzione.
Il punto di forza è la semplicità operativa: da riga di comando, con output in JSON Lines e un riepilogo HTML, si integra facilmente come gate di rilascio in una pipeline CI/CD. Il limite è la copertura basata su un catalogo di probe predefiniti: attacchi specifici della logica di un’applicazione richiedono probe personalizzati scritti a mano.
L’installazione richiede Python 3.10 o superiore e le chiavi API del modello che si vuole testare, che sia ospitato su OpenAI, Anthropic o un endpoint locale. Il repository ufficiale su GitHub documenta ogni famiglia di probe con esempi pronti all’uso, il che riduce di molto il tempo necessario per il primo scan rispetto a scrivere test avversari da zero.
Microsoft PyRIT: l’orchestratore di red teaming multi-turno
PyRIT, acronimo di Python Risk Identification Toolkit, è nato come strumento interno che Microsoft usava per testare Copilot prima di renderlo pubblico su GitHub. Nel 2026 il repository è stato spostato da Azure/PyRIT a microsoft/PyRIT, un segnale della maturità raggiunta dal progetto. La versione 0.9.0 risale al 9 maggio 2025, la 1.0.0 stabile è arrivata nel corso del 2026, e la 1.1.0, l’ultima release, è uscita il 4 settembre 2026.
A differenza di Garak, PyRIT è pensato per campagne multi-turno: non un singolo probe isolato, ma scenari conversazionali che si evolvono nel tempo per testare jailbreak, estrazione di dati tramite comportamento del modello e generazione di contenuti dannosi. Include Prompt Shield, un endpoint di guardrail per rilevare jailbreak e prompt injection, e un set di detector lato output che cercano pattern sfruttabili come SSRF, server-side template injection, XXE, open redirect e LDAP injection nascosti nelle risposte del modello.
PyRIT è rilasciato con licenza MIT, gratuito, e nessuna fonte consultata menziona un’edizione enterprise a pagamento. È descritto come uno strumento agnostico rispetto a modello e piattaforma, capace di orchestrare test su sistemi generativi multimodali. La complessità operativa è più alta di Garak: bisogna configurare scorer, scenari e campagne, quindi è pensato per team già abituati a lavorare con framework Python strutturati piuttosto che per un test rapido da riga di comando.
Il trasferimento del progetto sotto l’organizzazione microsoft/PyRIT non è un dettaglio burocratico: segnala che Microsoft lo tratta ormai come infrastruttura di prodotto, non più come esperimento interno del team di sicurezza. Chi valuta PyRIT oggi eredita quindi una cadenza di rilascio più prevedibile rispetto ai primi anni del progetto, quando gli aggiornamenti arrivavano in modo più sporadico sotto il vecchio repository Azure/PyRIT.
Giskard: red teaming per agenti AI e sistemi RAG
Giskard parte da un presupposto diverso: non serve un secondo strumento per la sicurezza se la stessa libreria che valuta la qualità di un agente può anche metterlo sotto attacco. La libreria open source Giskard v3, disponibile da metà agosto 2026, include il comando giskard-scan, uno scanner di red teaming automatico che genera suite di test avversari sulle categorie di minaccia dell’OWASP LLM Top 10, sonde di prompt injection e valutazioni di qualità per pipeline RAG.
Il catalogo comprende oltre 50 attacchi avversari, tra varianti di prompt injection in stile DAN, esposizione di informazioni interne, esfiltrazione di dati privati tra sessioni diverse ed estrazione di dati di training. Secondo un blog dedicato alla versione 3, il repository giskard-oss conta circa 5.700 stelle su GitHub a metà 2026, con licenza Apache 2.0. Accanto alla libreria gratuita esiste Giskard Hub 3.0, la piattaforma enterprise per collaborazione tra team e red teaming continuo, con prezzi non pubblicati e negoziati caso per caso.
Il caso più citato riguarda BPCE, uno dei maggiori gruppi bancari francesi, che ha usato Giskard per testare tre assistenti AI rivolti ai clienti, individuando vulnerabilità di prompt injection già in fase di sviluppo. La libreria open source è inoltre usata nel corso “Red Teaming LLM Applications” di DeepLearning.AI, il che ne ha ampliato l’adozione tra professionisti in formazione.
Il repository è pubblico su GitHub all’indirizzo Giskard-AI/giskard, mentre la documentazione commerciale di Giskard Hub è raggiungibile dal sito ufficiale dell’azienda. Chi arriva da Garak o PyRIT nota subito una differenza di filosofia: Giskard non chiede di scegliere tra testare la qualità delle risposte e testarne la sicurezza, le due cose condividono la stessa pipeline di scansione.
Garak vs PyRIT vs Giskard: la tabella comparativa completa
Ecco un confronto diretto delle caratteristiche tecniche e operative dei tre strumenti, utile per capire a colpo d’occhio le differenze prima di scegliere quale integrare nella propria pipeline.
Le righe su licenza e adozione contano più di quanto sembri a prima vista: uno strumento con licenza permissiva e adozione alta, come Garak, ha più probabilità di ricevere patch rapide quando emerge una nuova tecnica di jailbreak, semplicemente perché più occhi lo osservano ogni giorno. Le righe su complessità di setup e interfaccia, invece, aiutano a stimare il costo reale di adozione per un team che parte da zero, indipendentemente da quanto lo strumento sia gratuito sulla carta.
| Caratteristica | Garak (NVIDIA) | PyRIT (Microsoft) | Giskard (OSS + Hub) |
|---|---|---|---|
| Ruolo principale | Scanner di vulnerabilità su singolo modello | Orchestratore di red teaming multi-turno | Test di agenti AI e pipeline RAG |
| Licenza | Apache 2.0 | MIT | Apache 2.0 (libreria); Hub commerciale |
| Ultima versione nota | v0.16.0 / v0.17.0 | v1.1.0 | Giskard v3 / Hub 3.0 |
| Data ultima release | Estate-autunno 2026 | 4 settembre 2026 | 15 agosto 2026 |
| Stelle GitHub (circa) | 7.300-8.900 | Non quotato nelle fonti | 5.700 |
| Attacchi coperti | Injection, jailbreak DAN, encoding bypass, leakage, tossicità, XSS | Jailbreak, injection diretta/indiretta, estrazione dati, SSRF/XXE/LDAP nell’output | 50+ attacchi: injection, jailbreak, leak privacy, estrazione training data |
| Ambito coperto | Modelli singoli, multi-provider | Sistemi generativi anche multimodali | Agenti, chatbot, RAG, servizi JSON |
| Interfaccia | CLI | Framework Python + scorer | Libreria Python + Hub con dashboard |
| Output report | JSONL + riepilogo HTML | Punteggi di rischio per scenario | Report programmatico; dashboard su Hub |
| Integrazione CI/CD | Alta, pensata come gate di rilascio | Media, richiede setup di scenari | Alta via CLI; continua su Hub |
| Complessità di setup | Bassa | Alta | Media (libreria), bassa (Hub) |
| Adozione tra aziende che fanno AI security testing | 34% | 28% | Non quotata; casi enterprise documentati |
| Caso enterprise noto | Non nominato nelle fonti pubbliche | Microsoft Copilot (uso interno) | BPCE (gruppo bancario francese) |
| Manutentore | NVIDIA AI Red Team | Microsoft | Giskard AI |
Benchmark e adozione: cosa dicono i report di settore 2025-2026
I dati di adozione che circolano nel settore arrivano da tre fonti distinte e concordano su un punto: Garak resta lo strumento più diffuso tra chi fa già test di sicurezza sull’AI, seguito da PyRIT. Un report 2026 sulle statistiche di sicurezza AI, che cita un’indagine Gartner del 2025, attribuisce a Garak un’adozione del 34% tra le organizzazioni che conducono AI security testing, contro il 28% di PyRIT.
DataIntelo, in un’analisi separata sul mercato globale dell’AI red teaming, riporta che la componente software rappresenta il 42,3% dei ricavi del settore e che il 34% delle grandi imprese aveva già integrato una qualche forma di red teaming automatizzato nelle proprie pipeline all’inizio del 2026, contro appena l’11% nel 2023. È una crescita di oltre tre volte in tre anni, che riflette la pressione normativa più che una scelta puramente tecnica.
Il divario tra chi dice di fare red teaming e chi lo fa con strumenti dedicati resta ampio. Il report HiddenLayer citato sopra parla di appena il 16% di aziende che hanno mai sottoposto i propri modelli a un test avversario strutturato, un numero che stride con il 74% che ammette di aver già subito un incidente di sicurezza legato all’AI. In altre parole, la maggioranza delle aziende scopre il problema dopo l’attacco, non prima.
Un’analisi accademica pubblicata su arXiv, intitolata “Insights and Current Gaps in Open-Source LLM Vulnerability Scanners”, ha confrontato proprio strumenti di questa categoria e ha evidenziato un problema strutturale: scanner diversi, puntati sullo stesso modello con probe nominalmente equivalenti, restituiscono spesso esiti diversi sulla stessa vulnerabilità. La conclusione pratica per un team di sicurezza è che un solo strumento raramente basta a coprire tutte le sfumature di un attacco, il che rafforza l’argomento a favore di combinare Garak, PyRIT e Giskard invece di sceglierne uno soltanto e considerare il lavoro concluso.
Prezzi e licenze a confronto
Tutti e tre gli strumenti nascono come progetti open source e restano gratuiti nella loro forma base. Le differenze emergono quando si guarda a cosa serve per portarli in produzione su scala, dove i costi nascosti sono più legati al tempo di ingegneria che alle licenze.
| Voce | Garak | PyRIT | Giskard |
|---|---|---|---|
| Libreria/CLI open source | Gratis, Apache 2.0 | Gratis, MIT | Gratis, Apache 2.0 |
| Edizione enterprise | Non documentata | Non documentata | Giskard Hub, prezzo su richiesta |
| Supporto commerciale | Assente nelle fonti pubbliche | Assente nelle fonti pubbliche | Incluso nel piano Hub |
| Costo stimato per un team interno | Solo tempo ingegneristico per setup CLI | Più alto: serve competenza su scorer e orchestrazione | Basso per la libreria, variabile per Hub |
| Adatto a budget limitati | Sì | Sì, ma con curva di apprendimento | Sì per OSS, da valutare per Hub |
Il messaggio per chi pianifica un budget 2027 è semplice: nessuno dei tre strumenti open source impone un costo di licenza, ma solo Giskard offre un percorso naturale verso una piattaforma enterprise con dashboard e collaborazione tra team, per chi supera la fase di test manuale e vuole un red teaming continuo integrato nel ciclo di rilascio. Per un CISO italiano che deve giustificare una riga di budget al CFO, questo cambia l’argomentazione: non si tratta di comprare uno strumento che prima non esisteva, ma di allocare ore ingegneristiche per integrare software già gratuito, più eventualmente un contratto enterprise se serve collaborazione multi-team su larga scala.
Cinque attacchi reali di prompt injection che hanno cambiato le regole del gioco
I casi seguenti spiegano meglio di qualsiasi benchmark perché queste categorie di strumenti sono passate da opzionali a obbligatorie nel giro di dodici mesi.
- EchoLeak (CVE-2025-32711) su Microsoft 365 Copilot. Aim Security ha reso pubblico l’exploit nel giugno 2025, descrivendolo come il primo caso documentato di prompt injection zero-click contro un sistema AI in produzione: bastava una singola email malevola per far accedere Copilot a file interni ed esfiltrarli verso un server controllato dall’attaccante, senza alcuna interazione dell’utente. Microsoft ha dovuto rilasciare una patch lato server d’urgenza, perché nessuna azione dell’utente finale avrebbe potuto prevenire l’attacco.
- Zero-click su Atlassian Rovo. Nell’agosto 2026 un riepilogo di sicurezza ha documentato un attacco di prompt injection zero-click contro Rovo capace di esfiltrare dati da Jira e Confluence, due strumenti presenti in gran parte delle software house europee. L’episodio conferma che il rischio non si limita ai grandi vendor: qualunque prodotto che colleghi un LLM a repository di documenti aziendali eredita la stessa superficie di attacco.
- Istituto finanziario europeo, inizio 2026. Un penetration tester ha scoperto che una singola frase incorporata in un PDF induceva l’assistente AI aziendale a esfiltrare riepiloghi dei conti clienti verso un webhook esterno, senza generare alcun alert nel SIEM. Il dettaglio più inquietante è proprio l’assenza di segnali: i log applicativi mostravano solo una richiesta legittima al modello, non un tentativo di intrusione riconoscibile.
- Banca europea, marzo 2026. Un’analisi svizzera sulle difese OWASP LLM Top 10 riporta una perdita superiore a 4,7 milioni di euro dopo che una fattura PDF avvelenata ha spinto un agente AI di KYC a bypassare un controllo sanzioni, tramite un attacco di prompt injection indiretto. Nessun umano ha mai letto il testo malevolo: è stato l’agente stesso a processarlo come parte del proprio flusso di verifica documentale.
- GitHub Copilot RCE (CVE-2025-53773). Analisi vettoriali sulle CVE collegate al prompt injection segnalano anche vulnerabilità di remote code execution legate a strumenti di sviluppo basati su AI, tra cui Copilot e ambienti come Cursor, a conferma che il rischio non riguarda solo i chatbot rivolti al pubblico ma anche gli strumenti che milioni di sviluppatori usano ogni giorno per scrivere codice.
Sul fronte opposto, il caso BPCE mostra cosa succede quando il test avviene prima del lancio: individuare le vulnerabilità di prompt injection durante la fase di sviluppo, come ha fatto la banca francese con Giskard, ha permesso di correggere i tre assistenti AI prima che diventassero un problema pubblico.
Quale strumento scegliere: 5 casi d’uso pratici
La scelta dipende meno dal budget e più dalla forma del sistema che va testato. Ecco cinque scenari ricorrenti nelle aziende italiane ed europee che stanno adottando questi strumenti.
- Team di sicurezza che deve firmare il rilascio di un chatbot. Garak, grazie all’output JSONL e alla logica da gate CI/CD, si inserisce come controllo automatico prima del deploy, simile a uno scanner di vulnerabilità tradizionale, senza richiedere che qualcuno scriva scenari di test da zero.
- Centro ricerca o vendor che testa modelli frontier prima del rilascio pubblico. PyRIT è pensato per campagne multi-turno su modelli generativi, incluso il multimodale, ed è la scelta naturale per chi deve valutare comportamenti che emergono solo dopo diversi scambi, come un modello che cede a un jailbreak solo dopo il quinto o sesto messaggio di un utente insistente.
- Banca o assicurazione con agenti AI a contatto con dati sensibili. Giskard copre lo scenario più vicino ai casi reali di perdita finanziaria descritti sopra, con probe specifici su leak di privacy e categorie OWASP LLM Top 10 applicate ad agenti e RAG, l’architettura più diffusa tra chatbot bancari e assicurativi.
- Azienda che deve rispettare la scadenza AI Act del 2 agosto 2026 per sistemi ad alto rischio. Una combinazione di Garak per la scansione del modello grezzo e Giskard per il contesto applicativo copre sia il livello tecnico sia quello documentale richiesto dall’Allegato III, con report esportabili da allegare al fascicolo di conformità.
- Team con budget limitato che vuole partire subito senza formazione lunga. Garak resta l’opzione con la curva di apprendimento più bassa: installazione da PyPI, Python 3.10+, chiave API del provider target e un primo scan in pochi comandi, senza bisogno di un budget dedicato o di un fornitore esterno.
Guida alla migrazione: dal test manuale a una pipeline di red teaming automatizzata
Per i team che oggi testano i propri modelli con verifiche manuali sparse, il passaggio a uno di questi strumenti segue di solito lo stesso percorso in sei fasi.
Una domanda che si pone quasi ogni azienda in questa fase è chi debba possedere la pipeline: il team di sicurezza applicativa o il team che costruisce i modelli e gli agenti. Nella pratica documentata dai casi citati sopra, come BPCE, il modello che funziona meglio è ibrido: il team ML integra lo scanner nella propria pipeline di training e deployment, mentre il team di sicurezza definisce le soglie di rischio accettabili e riceve i report per la firma finale prima del rilascio in produzione.
- Mappare gli endpoint AI in produzione (chatbot, agenti, pipeline RAG) e classificarli per livello di rischio secondo l’AI Act, dando priorità ai sistemi che toccano dati finanziari o sanitari.
- Installare Garak da PyPI, configurare un generatore per il provider del modello target e lanciare una prima scansione con le famiglie di probe di base (injection, jailbreak, leakage).
- Analizzare il report JSONL, isolare i probe che hanno avuto successo e correggere i guardrail o il prompt di sistema di conseguenza, documentando ogni fix per l’eventuale audit di conformità.
- Per agenti e sistemi RAG più complessi, aggiungere Giskard con giskard-scan per coprire le categorie OWASP LLM Top 10 specifiche del contesto applicativo, includendo test di leak tra sessioni.
- Se il caso d’uso richiede campagne multi-turno su modelli frontier o multimodali, integrare PyRIT per orchestrare scenari più lunghi e collegare l’output ai detector lato output per SSRF, XXE e injection secondarie.
- Pianificare una cadenza ricorrente degli scan, non un test una tantum: un modello aggiornato o un nuovo plugin collegato all’agente possono riaprire vulnerabilità già corrette in passato.
Il consiglio più ricorrente tra chi ha già completato questa transizione è di non trattare questi strumenti come sostituti dell’AppSec tradizionale. PyRIT stesso, nella documentazione del progetto, si definisce complementare ai test di sicurezza applicativa convenzionali, non un loro rimpiazzo.
Un errore comune nelle prime migrazioni è lanciare tutti i probe disponibili al primo giro e restare sommersi da centinaia di falsi positivi da triagiare. Meglio partire con due o tre famiglie di attacco (injection diretta, jailbreak DAN, leakage del prompt di sistema), stabilizzare il processo di remediation, e solo dopo allargare la copertura alle famiglie più esotiche come gli attacchi con suffissi avversari o la codifica Base64/ROT13.
Pro e contro di Garak, PyRIT e Giskard
Nessuno dei tre copre tutto. Ecco un riepilogo onesto dei compromessi di ciascuno strumento.
- Garak, pro: installazione rapida, licenza permissiva, output pronto per la CI/CD, adozione più alta del gruppo (34%). È l’opzione con il minor attrito tra decisione e primo report utilizzabile.
- Garak, contro: copertura limitata al catalogo di probe esistenti, meno adatto a test di logica applicativa personalizzata. Un’azienda con un flusso di lavoro molto specifico dovrà comunque scrivere probe su misura.
- PyRIT, pro: unico tra i tre a orchestrare campagne multi-turno, detector lato output per vulnerabilità a valle come SSRF e XXE, usato internamente su Copilot. Il supporto multimodale lo rende una scelta più a prova di futuro per chi lavora anche su immagini e audio generati.
- PyRIT, contro: setup più complesso, richiede competenza su scorer e scenari, non è un semplice comando da lanciare. I team piccoli rischiano di sottoutilizzarne le funzionalità più avanzate.
- Giskard, pro: unico a coprire nativamente agenti e pipeline RAG, oltre 50 attacchi avversari, caso enterprise documentato (BPCE), percorso naturale verso una piattaforma con dashboard. È lo strumento con il collegamento più diretto ai casi di perdita finanziaria reale descritti in questo articolo.
- Giskard, contro: prezzo dell’Hub non pubblico, la libreria open source da sola offre “solo capacità di test di base” secondo la stessa documentazione del progetto per chi cerca collaborazione multi-team. Serve quindi valutare un preventivo prima di impegnarsi su scala enterprise.
Integrazione in CI/CD e reportistica: chi si integra meglio nella pipeline
Sul fronte dell’automazione, Garak resta il candidato più immediato per chi vuole un gate binario prima del rilascio: il report JSONL con hit log nomina esattamente quali attacchi sono andati a segno, un formato pensato per essere letto da uno script prima ancora che da un umano.
PyRIT si adatta meglio a pipeline dove serve una valutazione scenario per scenario, con punteggi di rischio piuttosto che un semplice pass/fail, utile quando il team di sicurezza deve giustificare priorità di intervento a un comitato rischi. Giskard offre entrambi i mondi: la libreria si integra come test Python nella CI, mentre Giskard Hub aggiunge dashboard interattive e red teaming continuo, pensato per organizzazioni dove anche stakeholder non tecnici devono leggere i risultati.
Per un team DevSecOps che già usa strumenti come Trivy o Snyk per la scansione delle dipendenze, il salto concettuale non è enorme: si tratta di aggiungere un ulteriore step alla pipeline che, invece di controllare pacchetti vulnerabili, controlla se il modello risponde in modo pericoloso a un input avversario. La differenza pratica sta nel formato dei risultati: mentre uno scanner di dipendenze restituisce un elenco di CVE con severità numerica, questi strumenti restituiscono transcript di conversazioni che vanno letti per capire se un guardrail ha davvero retto o ha solo rimandato il problema a un turno successivo.
# Esempio di scan Garak in una pipeline CI
pip install garak
python -m garak --model_type openai --model_name gpt-4o \
--probes promptinject,dan,leakreplay \
--report_prefix ci_scan_$(date +%Y%m%d)
Il comando qui sopra lancia tre famiglie di probe (injection diretta, jailbreak DAN, leakage tramite replay) contro un modello indicato a riga di comando e salva il report con un prefisso datato, comodo per confrontare gli scan tra un rilascio e l’altro e capire se una modifica al prompt di sistema ha peggiorato o migliorato la resistenza del modello nel tempo.
Il verdetto: chi vince nel red teaming AI nel 2026
Non esiste un vincitore assoluto perché i tre strumenti rispondono a domande diverse. Se la domanda è “il mio modello resiste ai probe di attacco più noti”, Garak vince per adozione (34% contro il 28% di PyRIT), velocità di setup e output pronto per la CI. Se la domanda è “come si comporta il mio sistema in una conversazione lunga e articolata con un utente ostile”, PyRIT resta l’unico progettato per questo scopo, con il vantaggio di essere lo stesso strumento che Microsoft usa internamente su Copilot.
Se invece la domanda è “il mio agente AI che tocca dati bancari o sanitari può essere aggirato”, Giskard è quello con il caso d’uso più vicino agli incidenti reali documentati in questo articolo, dalla banca dei 4,7 milioni di euro persi al caso BPCE risolto prima del lancio. Per la maggior parte delle aziende europee che devono rispettare la scadenza AI Act di agosto 2026, la combinazione più pragmatica resta usare Garak per la scansione di base del modello e Giskard per il contesto applicativo, aggiungendo PyRIT solo quando il sistema richiede test multi-turno su scenari complessi.
Il filo conduttore di tutti i dati raccolti in questo confronto è che il rischio non aspetta che un’azienda scelga uno strumento. Con il 74% delle organizzazioni che ammette di aver già subito un incidente legato all’AI e solo il 16% che ha mai condotto un red team strutturato, la domanda giusta per un CISO europeo a fine 2026 non è più se testare i propri sistemi AI contro il prompt injection, ma con quale combinazione di Garak, PyRIT e Giskard iniziare questa settimana.
Domande frequenti
Garak, PyRIT e Giskard sono davvero gratuiti?
Sì, tutti e tre offrono una versione open source gratuita con licenza permissiva: Apache 2.0 per Garak e Giskard, MIT per PyRIT. Solo Giskard propone in aggiunta una piattaforma enterprise a pagamento, Giskard Hub, con prezzo su richiesta.
Qual è lo strumento più semplice da installare per iniziare subito?
Garak. Basta un’installazione da PyPI, Python 3.10 o superiore e una chiave API del provider del modello da testare per lanciare la prima scansione.
Questi strumenti sostituiscono un penetration test tradizionale?
No. La stessa documentazione di PyRIT chiarisce che il progetto è scoperto specificamente sui comportamenti generativi dell’AI e completa, senza sostituire, i test di sicurezza applicativa convenzionali su SQL injection, autenticazione e altre vulnerabilità classiche.
Quale strumento copre meglio i sistemi RAG e gli agenti AI?
Giskard, che nella versione 3 include lo scanner giskard-scan pensato specificamente per chatbot, sistemi RAG e agenti che comunicano tramite JSON, con copertura delle categorie OWASP LLM Top 10.
Serve un red teaming automatizzato per rispettare l’AI Act europeo?
Per i sistemi AI classificati ad alto rischio nell’Allegato III, l’AI Act richiede test di robustezza contro attacchi avversari entro il 2 agosto 2026. Uno strumento come Garak o Giskard fornisce evidenza documentabile di questi test, anche se la normativa non impone uno strumento specifico.
Quanto è diffuso davvero il prompt injection nelle aziende europee?
Un’analisi svizzera sulle difese OWASP LLM Top 10 lo ha rilevato in 27 dei 31 progetti di penetration test su sistemi LLM condotti tra il 2025 e il 2026, rendendolo la debolezza più osservata nel campione.
Posso usare più di uno di questi strumenti insieme?
Sì, ed è la pratica più comune tra le organizzazioni con maturità di sicurezza più alta: Garak per la scansione rapida del modello grezzo, Giskard o PyRIT per il red teaming contestuale su agenti e scenari multi-turno.
Chi mantiene questi progetti e sono a rischio di abbandono?
Garak è mantenuto dall’AI Red Team di NVIDIA, PyRIT da Microsoft (il repository è passato da Azure/PyRIT a microsoft/PyRIT nel 2026) e Giskard dall’omonima startup Giskard AI. Tutti e tre hanno rilasciato aggiornamenti nel corso del 2026, incluso il rilascio di PyRIT 1.1.0 il 4 settembre 2026.
Da dove parto se non ho mai fatto red teaming su un sistema AI?
Con un solo modello da testare e un budget limitato, la scelta più rapida resta Garak: installazione da riga di comando, probe già pronti per injection e jailbreak, e un report leggibile entro la prima ora di lavoro. Da lì si può decidere se servono anche PyRIT o Giskard in base a quanto emerge dal primo scan.
