Spedire un''applicazione LLM significa spedire un sistema i cui modi di fallimento non sono eccezioni o tracce di stack ma output — un chatbot che perde il suo prompt di sistema, un agente che può essere persuaso a chiamare uno strumento che non dovrebbe, un assistente di supporto che confida di inventare una politica di rimborso. Nessuno di questi genera un errore. I test tradizionali, che asseriscono che una funzione restituisce un valore atteso, non possono esprimere la maggior parte di essi. La disciplina che è emersa per colmare quel divario è il red teaming LLM: attaccare deliberatamente il tuo modello e la tua applicazione per trovare gli input che producono comportamento inaccettabile, prima che qualcun altro lo faccia.
Nel 2026 questo è maturato da esperimenti di prompt ad hoc in un panorama di strumenti con strati distinti. Questa guida mappa quel panorama — garak e PyRIT a livello di modello, DeepTeam e promptfoo a livello di applicazione, Agentic Security per il fuzzing di endpoint black-box, e Giskard e Inspect per la scansione e la valutazione rigorosa. Il filo conduttore è che questi strumenti non sono concorrenti: catturano diverse classi di fallimento e eseguire solo uno lascia divari prevedibili.
Quello che stai effettivamente testando
Prima degli strumenti, aiuta nominare le classi di fallimento, perché richiedono test diversi. I jailbreak e l''iniezione di prompt sono i titoli: far ignorare al modello le sue istruzioni, sia attraverso manipolazione diretta ("ignora le istruzioni precedenti") che indirettamente attraverso il contenuto che recupera — un documento avvelenato che porta istruzioni che il modello quindi segue. L''iniezione indiretta è la variante più seria nei sistemi RAG e agenti, perché l''attaccante non tocca mai la casella di prompt.
La perdita di dati copre l''estrazione del prompt di sistema, della PII che il modello ha visto in contesto o dei dati di addestramento. L''agenzia eccessiva è la classe di fallimento che diventa più pericolosa quando gli agenti guadagnano strumenti: il modello che intraprende un''azione che dovrebbe aver rifiutato, o che concatena strumenti in un modo che supera la sua autorità intesa. Il contenuto dannoso è la conformità diretta alle richieste che l''applicazione dovrebbe rifiutare. E l''allucinazione — la fabbricazione fiduciosa — è spesso il rischio commerciale di frequenza più alta anche se è il meno drammatico.
Ognuno di questi vive a un livello diverso. La suscettibilità al jailbreak è largamente una proprietà del modello. L''agenzia eccessiva e la perdita di prompt sono proprietà dell''applicazione — il suo prompt di sistema, i suoi strumenti, le sue guardrail. L''allucinazione è una proprietà della pipeline, specialmente della qualità del recupero. Questo strato è esattamente il motivo per cui gli strumenti si dividono nel modo in cui lo fanno.
Scanner a livello di modello: garak e PyRIT
garak (da NVIDIA) è la cosa più vicina a nmap per LLM. Esegue una grande libreria di probe contro un modello — famiglie di jailbreak, iniezione di prompt, tossicità, perdita di dati, attacchi di codifica — e riporta quali hanno avuto successo. Lo indirizza a un modello (un modello HuggingFace, un endpoint OpenAI, un server locale) e funziona attraverso il suo catalogo. Il suo valore è la larghezza e il basso sforzo: impari rapidamente a quali famiglie di attacco conosciute il tuo modello è suscettibile, senza progettare nulla da solo.
PyRIT (da Microsoft) si rivolge a un problema più difficile: gli attacchi multi-turn e multimodali. Molti veri jailbreak non funzionano in un singolo messaggio; funzionano stabilendo il contesto su più turni ed escalation graduale. PyRIT fornisce orchestrazione per questo — strategie di attacco come crescendo (escalation lenta) e TAP (albero di attacchi con potatura) che si adattano in base alle risposte del modello. È più un SDK che uno scanner: componi orchestratori, target, convertitori e scorer. Questo la rende più lavoro per iniziare e più potente per la ricerca in attacchi che una singola probe non può trovare.
Il limite condiviso è che entrambi testano principalmente il modello, non la tua applicazione. Un modello che resiste alle probe di garak in isolamento può comunque essere banalmente compromesso dentro la tua app, perché il tuo prompt di sistema, il tuo recupero e i tuoi strumenti creano una superficie di attacco che la scansione a livello di modello non ha mai visto.
Suite a livello di applicazione: DeepTeam e promptfoo
È qui che si adattano DeepTeam e promptfoo. Entrambi testano la tua applicazione distribuita, avvolgendo qualunque cosa la tua app effettivamente sia — prompt, recupero, strumenti, guardrail — e attaccano quel'intera assemblea.
DeepTeam, dal team di DeepEval, esprime il red teaming in Python: fornisci un model_callback che chiama la tua app, dichiari quali vulnerabilità testare (perdita di PII, agenzia eccessiva, bias, perdita di prompt) e quali attacchi usare, e genera ed esegue i casi avversariali. I suoi miglioramenti di attacco sono la parte interessante — lo stesso attacco di base riscritto come base64, in un''altra lingua, come roleplay o scalato su più turni, che è come i veri attaccanti evadono i filtri ingenui. Perché è codice, cade in una suite di test ed esegue in CI.
promptfoo viene da essa dalla valutazione: è una CLI guidata da configurazione per testare gli output LLM che è cresciuta in una sostanziale capacità di red-teaming, generando automaticamente prompt avversariali su dozzine di plugin di attacco e mappando i risultati ai framework di conformità. Il suo punto di forza è l''integrazione CI e il fatto che lo stesso strumento copre sia le valutazioni di qualità che i test di sicurezza, in modo che un''unica imbracatura serva entrambi gli scopi.
Per la maggior parte dei team che spediscono un prodotto LLM, questo livello importa più del livello di modello, perché testa la cosa che hai effettivamente distribuito. La cattura è che richiede di definire cosa "inaccettabile" significa per la tua applicazione — gli strumenti generano gli attacchi, ma tu fornisci il giudizio su quali output sono fallimenti.
Approcci black-box e scansione
Due altre forme meritano di essere conosciute. Agentic Security tratta il tuo endpoint come una scatola nera e lo fuzza agenticamente — generando probe, osservando risposte, adattandosi — con la utile aggiunta del test di stress dell''API. Questa ultima parte è sottovalutata: una quota significativa di distribuzioni LLM fallisce su limiti di rate, esaurimento di token e abuso di risorse prima di fallire sulla sicurezza dei contenuti, e la maggior parte degli strumenti di red teaming ignora completamente questo.
Giskard inverte il flusso di lavoro usuale. Invece di richiedere di specificare cosa testare, scansiona il modello — usando la tua descrizione di cosa fa l''app per generare probe rilevanti al dominio — e produce un report di vulnerabilità rilevate, che può quindi convertire in una suite di test riutilizzabile. Quel modello di scansione-allora-testifica è prezioso precisamente perché la parte più difficile del red teaming è sapere cosa cercare. Giskard trova i problemi che non avevi pensato di testare, quindi li blocca come test di regressione.
Infine, Inspect dall''UK AI Safety Institute si siede leggermente apartato: è un framework di valutazione rigorosa piuttosto che uno strumento di attacco, ma la sua struttura (dataset, solver, scorer) e l''eccellente visualizzatore di trascrizione lo rendono la scelta giusta quando hai bisogno di misurazione difendibile e riproducibile — incluso del comportamento agentico — piuttosto che di un elenco di vulnerabilità.
Costruire una pratica stratificata
La conclusione pratica è che questi strumenti si compongono. Una pratica ragionevole del 2026 appare così.
Quando selezioni o aggiorni un modello di base, esegui uno scanner a livello di modello — garak per larghezza, PyRIT se la robustezza multi-turn importa al tuo profilo di rischio. Questo informa la scelta del modello e ti dice cosa la fondazione resiste da sola.
Durante lo sviluppo, esegui uno strumento in stile scansione come Giskard contro la tua applicazione effettiva per scoprire le classi di fallimento che non avevi anticipato e converti i suoi risultati in test.
In CI, ad ogni cambio di prompt, modello o strumento, esegui una suite a livello di applicazione — DeepTeam o promptfoo — come un gate. Questa è l''automazione di valore più alto, perché i prompt e le definizioni di strumenti sono la superficie di controllo di un''app LLM e cambiano costantemente. Una modifica del prompt che sembra inoffensiva può rimuovere la frase che stava prevenendo un jailbreak.
Prima del rilascio, aggiungi fuzzing black-box contro l''endpoint distribuito, incluso il test di stress, per catturare i problemi a livello di distribuzione che i test a livello di codice perdono.
E mantieni umani in esso. Ogni strumento automatizzato testa le famiglie di attacco conosciute. I nuovi attacchi — quelli specifici al tuo dominio, ai tuoi dati e ai tuoi strumenti — vengono da una persona che comprende la logica di business pensare in modo avversariale. L''automazione alza il pavimento; non sostituisce il soffitto.
Iniezione indiretta: l''attacco che rompe il modello
Una classe di attacco merita un trattamento separato perché sconfigge l''intuizione con cui la maggior parte dei team inizia. L''iniezione di prompt diretta — un utente che digita "ignora le tue istruzioni" — è ciò che tutti testano per primo, ed è la metà più facile. L''iniezione indiretta è quando le istruzioni maligne arrivano attraverso il contenuto che il sistema recupera: un documento nella tua knowledge base, una pagina web che l''agente naviga, un''email che riassume, un commento di codice che legge. L''attaccante non interagisce mai con la tua casella di prompt affatto.
Questo importa enormemente per i sistemi RAG e gli agenti, perché l''intera loro proposta di valore è consumare il contenuto esterno. Un assistente di supporto che risponde dalla tua documentazione seguirà fedelmente le istruzioni incorporate in un documento se qualcuno riesce a inserire un documento nel corpus — attraverso un wiki pubblico, un ticket inviato da un cliente o una pagina raschiata. Un agente che legge un problema di GitHub può essere istruito da quel problema. Il limite di fiducia che le persone immaginano ("gli utenti non sono fidati, i nostri dati sono fidati") non regge una volta che qualsiasi parte del corpus è influenzabile.
Testare per questo è più difficile che testare l''iniezione diretta, perché richiede di simulare contenuto avvelenato, non prompt avvelenati — devi posizionare testo avversariale dove il recupero lo troverà e verificare che il modello non agisca su di esso. Gli strumenti a livello di applicazione gestiscono questo meglio che gli scanner a livello di modello, poiché la pipeline di recupero fa parte di ciò che esercitano, ma spesso richiede di costruire lo scenario deliberatamente.
Le mitigazioni sono architettoniche piuttosto che basate su prompt. Tratta tutto il contenuto recuperato come input non fidato, nello stesso modo in cui tratti l''input dell''utente. Non permettere al testo recuperato di raggiungere una posizione in cui può essere interpretato come istruzioni se puoi evitarlo strutturalmente. Vincola quali strumenti un agente può chiamare durante l''elaborazione di contenuto non fidato e richiedi conferma per azioni consequenziali. E mantieni la provenienza: sapere quale documento ha prodotto una risposta errata è ciò che trasforma un incidente in una correzione.
Cosa il red teaming non ripara
Un avvertimento che vale la pena affermare chiaramente: trovare una vulnerabilità non è la stessa cosa che ripararla, e le vulnerabilità LLM spesso non sono completamente riparabili. Non puoi patchare un modello nel modo in cui patchi un buffer overflow. Le risposte realistiche sono la mitigazione piuttosto che l''eliminazione: prompt di sistema più stringenti, guardrail di input e output come LLM Guard, autorizzazioni di strumenti vincolate, approvazione umana per azioni consequenziali e monitoraggio del comportamento anomalo.
Questo cambia ciò che significa un rapporto di red team. Nella sicurezza tradizionale, un risultato implica una correzione. Nella sicurezza LLM, un risultato spesso implica una decisione di rischio: questo attacco ha successo a un certo tasso, qui è la mitigazione, qui è il rischio residuale, è accettabile per questo caso d''uso? I team che si aspettano che il red teaming produca un certificato di pulizia saranno perpetuamente delusi. I team che lo usano per quantificare e accettare consapevolmente il rischio ottengono valore reale.
Il corollario è che l''architettura batte l''ingegneria del prompt per i fallimenti che importano di più. Un agente che non può essere ingannato a trasferire denaro perché strutturalmente manca quell''autorizzazione è più sicuro di uno che si affida al modello a rifiutare. L''agenzia eccessiva è meglio affrontata dando meno agenzia. L''output più utile del red teaming è spesso la realizzazione che una capacità non avrebbe dovuto essere esposta in primo luogo.
Il fondo della linea
Il red teaming LLM è diventato una vera disciplina perché i fallimenti LLM sono output piuttosto che errori, e i test ordinari non possono esprimerli. Lo tooling del 2026 si divide per livello, e quella divisione è la chiave per utilizzarla bene: garak e PyRIT probe il modello, DeepTeam e promptfoo attaccano l''applicazione che hai effettivamente distribuito, Agentic Security fuzza l''endpoint inclusi i suoi limiti di risorsa, e Giskard scopre i problemi che non sapevi di cercare. Esegui più di uno, fai il gate di CI sul livello di applicazione dove i prompt cambiano di più, mantieni il pensiero avversariale umano nel ciclo e tratta i risultati come decisioni di rischio piuttosto che come bug in attesa di un patch — quindi correggi ciò che puoi nell''architettura piuttosto che nel prompt.
Riferimenti e Risorse
Strumenti
Background e analisi
- Best LLM Vulnerability Scanners 2026: Garak, PyRIT, Promptfoo
- LLM Red Teaming Guide 2026: Tools, Attacks & Methodology — AppSec Santa
- LLM Red Teaming Tools Compared — QAwerk
- awesome-ai-security-tools
Cheatsheet correlati di 1337skills