Nel settembre 2026 il prompt injection resta, tra i temi di intelligenza artificiale seguiti dalla nostra redazione, il problema di sicurezza più discusso tra chi costruisce agenti AI. Una meta-analisi di 78 studi pubblicata a fine maggio da particula.tech misura tassi di successo degli attacchi (ASR, attack success rate) tra il 50% e l’84% sui modelli linguistici più diffusi, con punte oltre l’85% quando l’attacco è adattivo e fino al 97,6% con catene di attacco composite. Di fronte a numeri così alti, i team di sicurezza si dividono in due scuole di pensiero: rafforzare il modello con il fine-tuning avversariale, oppure filtrare input e output con sistemi esterni come PromptArmor o PromptGuard. Questo confronto mette a terra entrambe le strade con dati verificabili, benchmark reali e una guida pratica per chi deve decidere oggi come proteggere un chatbot, un agente di navigazione o un sistema RAG aziendale.
Il punto di partenza è scomodo: nessuna delle due strategie elimina il rischio. Lo confermano sia l’analisi di Axis Intelligence su agenti web reali sia la guida OWASP aggiornata alla categoria LLM01:2025. Il tema si inserisce in un trend più ampio: il report Unit 42 2026, che analizziamo nel nostro approfondimento sugli incident response, segnala che l’89% delle violazioni informatiche oggi passa da problemi di identità e accesso, categoria in cui rientra anche un agente AI dirottato tramite prompt injection per eseguire azioni con privilegi che non gli appartengono. Il confronto che segue non cerca quindi un vincitore assoluto, ma la combinazione più efficiente per ogni scenario, con cifre su riduzione dell’ASR, latenza aggiunta e costo di implementazione.
Cos’è il prompt injection e perché nel 2026 è ancora irrisolto
Il prompt injection è una tecnica che inserisce istruzioni malevole dentro l’input di un modello linguistico, spingendolo a ignorare le regole originali del sistema. Esiste in due varianti principali: diretta, quando l’utente scrive l’istruzione avversaria nella chat, e indiretta, quando l’istruzione è nascosta in un documento, una pagina web o un’email che il modello legge durante il proprio lavoro. La seconda variante è la più pericolosa perché l’attaccante non ha bisogno di accesso diretto al sistema: basta che l’agente AI visiti una pagina compromessa. Per chi arriva dal mondo delle applicazioni web tradizionali, l’analogia più immediata è quella con la SQL injection: in entrambi i casi un motore che esegue istruzioni riceve dati che non dovrebbero contenere comandi, con la differenza che un modello linguistico non ha una sintassi rigida da cui distinguere “dato” e “comando”, il che rende il filtraggio molto più difficile che con una query parametrizzata.
I numeri del 2026 raccontano un problema che cresce insieme alla diffusione degli agenti autonomi. Lo studio StakeBench di Axis Intelligence, pubblicato a luglio, ha eseguito 3.168 run avversari su due architetture di agenti browser, NanoBrowser e BrowserUse, basate su GPT-5 e Gemini-2.5-Flash. Il risultato: gli attacchi diretti hanno successo in oltre il 79% delle configurazioni testate, quelli indiretti tra il 41,67% e il 68,16%. Lo stesso studio conclude che nessuna combinazione testata raggiunge quella che i ricercatori chiamano la “regione di comportamento robusto”, cioè una configurazione che blocca in modo affidabile tutte le categorie di attacco.
Microsoft, nella propria documentazione ufficiale di sicurezza, non promette un blocco totale. Consiglia invece di “implementare una strategia di difesa in profondità che sovrapponga più mitigazioni probabilistiche e deterministiche per ridurre rischio e impatto del prompt injection indiretto”, frase che riassume bene dove si trova oggi lo stato dell’arte: non prevenzione assoluta, ma riduzione stratificata del rischio. La categoria LLM01:2025 della guida OWASP alla remediation delle vulnerabilità applicative inquadra il prompt injection come un rischio distinto dalle iniezioni classiche, ma con la stessa logica di fondo: input non fidato che raggiunge un motore di esecuzione senza validazione sufficiente.
Due strategie a confronto: filtri esterni contro fine-tuning avversariale
La prima famiglia di difese lavora fuori dal modello. Un filtro, spesso un secondo LLM più piccolo o una pipeline di classificatori, analizza il prompt in entrata e talvolta anche l’output in uscita, cercando pattern sospetti prima che raggiungano il modello principale. PromptArmor e PromptGuard appartengono a questa categoria. Il vantaggio è che non serve toccare i pesi del modello di produzione: si aggiunge un livello, si misura la latenza, si distribuisce.
La seconda famiglia agisce dentro il modello. Il fine-tuning avversariale addestra il sistema su esempi di attacco reali, insegnandogli a riconoscere e rifiutare istruzioni iniettate anche quando arrivano mascherate da contenuto legittimo. SecAlign e ReasAlign sono gli esempi più citati nella letteratura 2026, insieme al caso InjecAgent su GPT-4 che vedremo più avanti. Il vantaggio qui è l’assenza di overhead in inferenza: la difesa è già “cotta” nei pesi del modello, quindi non aggiunge millisecondi a ogni richiesta.
Nessuna delle due strade è gratuita. I filtri aggiungono latenza e, nel caso di un secondo LLM come giudice, raddoppiano il costo di inferenza. Il fine-tuning richiede un ciclo di addestramento, un dataset avversariale curato e va ripetuto ogni volta che emergono nuove tecniche di attacco, perché un modello allineato oggi non è automaticamente allineato contro le tecniche del prossimo trimestre.
Tabella comparativa: le tecniche di difesa dal prompt injection nel 2026
La tabella seguente raccoglie dieci tecniche di difesa attive nel 2026, con il benchmark su cui sono state misurate, la riduzione dell’ASR o l’ASR residuo riportato e la latenza aggiunta quando disponibile.
| Tecnica | Tipo | Benchmark | Risultato ASR | Latenza aggiunta | Anno |
|---|---|---|---|---|---|
| PromptArmor | Filtro basato su LLM | AgentDojo | Riduzione >99%, falsi positivi/negativi <1% | 200-600 ms | 2026 (ICLR) |
| PromptGuard (4 livelli) | Filtro multi-layer | PromptBench / InjectBench | Riduzione 67%, F1 0,91 | <8 ms | 2026 |
| PromptGuard2 (backend GPT-5-mini) | Filtro + LLM di supporto | Benchmark open-ended proprio | ASR 0,00 sulla propria suite sintetica | Non riportata | Febbraio 2026 |
| SecAlign | Fine-tuning allineato | Attacchi basati su ottimizzazione | Circa 10% ASR residuo | Nessuna (in inferenza) | Riferimento consolidato |
| ReasAlign | Fine-tuning con reasoning | Benchmark open-ended | 3,6% ASR | Nessuna (in inferenza) | Gennaio 2026 |
| Fine-tuning avversariale (caso InjecAgent, GPT-4) | Fine-tuning su esempi di attacco | InjecAgent | 3,8% ASR, contro il 47% della versione solo a prompt | Nessuna (in inferenza) | 2026 |
| Prompt Sandwiching | Tecnica solo a prompt | Attacco adattivo (arXiv:2510.09023) | 1% ASR dichiarato, oltre 95% sotto attacco adattivo | Minima | Rif. Nasr et al. |
| Classificatore regex + NLP classico | Filtro statico | PromptBench | Riduzione 18% | <5 ms | Baseline storica |
| Difesa in profondità (architettura + human-in-the-loop) | Combinazione di livelli | Linee guida Microsoft / OWASP | Nessun ASR unico misurato, riduzione cumulativa dell’impatto | Variabile | 2026 |
| Architettura dual-LLM (privilegio separato) | Isolamento architetturale | Non normalizzato su un singolo benchmark | Riduce la superficie d’attacco, non elimina l’ASR | Overhead architetturale | 2026 |
Un dato salta subito all’occhio: il Prompt Sandwiching, tecnica che si limita a “incorniciare” il prompt utente tra istruzioni di sistema, dichiara un ASR dell’1% nei test originali ma crolla oltre il 95% quando l’attaccante adatta la strategia, secondo i dati citati da frenchydigital.com. È la prova più diretta che i numeri di un benchmark statico non bastano da soli: vanno sempre letti insieme al tipo di attacco testato.
I benchmark che contano davvero: AgentDojo, PromptBench e StakeBench
Confrontare difese diverse richiede benchmark comuni, ma nel 2026 il settore non ne ha ancora uno standard condiviso. Tre banchi di prova dominano la letteratura citata dai team di sicurezza.
AgentDojo è il benchmark usato dal paper di PromptArmor, presentato a ICLR 2026 (arXiv 2507.15219). Simula agenti che eseguono compiti reali, come gestire email o calendari, mentre ricevono documenti contaminati con istruzioni nascoste. È il terreno su cui PromptArmor riporta la riduzione superiore al 99%.
PromptBench e InjectBench misurano invece la robustezza a livello di singolo prompt, con attacchi più vari ma meno legati a un contesto agentivo end-to-end. Su questi due banchi PromptGuard riporta una riduzione del 67% con un F1 di 0,91, un compromesso più prudente ma con latenza quasi nulla.
StakeBench, pubblicato da Axis Intelligence a luglio 2026, sposta il test su agenti browser reali (NanoBrowser e BrowserUse) invece che su ambienti simulati. È lo scenario più vicino a un’applicazione di produzione e, non a caso, è anche quello con i risultati peggiori: 79% di successo per gli attacchi diretti.
| Benchmark | Fonte | Configurazione testata | Tasso di successo attacco (ASR) | Data |
|---|---|---|---|---|
| Meta-analisi di 78 studi | particula.tech | LLM comuni, attacchi standard/adattivi/compositi | 50-84% standard, >85% adattivo, 97,6% composito | Maggio 2026 |
| AgentDojo | Paper PromptArmor, ICLR 2026 | Agenti con filtro LLM attivo | <1% ASR residuo (riduzione >99%) | 2026 |
| StakeBench | Axis Intelligence | NanoBrowser/BrowserUse su GPT-5 e Gemini-2.5-Flash | 79% diretto, 41,67-68,16% indiretto | Luglio 2026 |
| Benchmark open-ended dinamico | arXiv 2602.03117 | PromptGuard2 su backend GPT-5-mini | 0,00 sulla suite sintetica propria | Febbraio 2026 |
| Studio sulla fuga di dati di training | tianpan.co | 50 applicazioni reali su una piattaforma AI diffusa | 68% di estrazione del system prompt | Maggio 2026 |
La lettura corretta di questi numeri richiede prudenza. Un ASR vicino allo zero riportato su una suite sintetica creata dallo stesso team che ha sviluppato la difesa (come nel caso di PromptGuard2) va trattato con più scetticismo di un ASR misurato su un benchmark indipendente come AgentDojo o StakeBench. La differenza tra “funziona nei nostri test” e “funziona in produzione contro un attaccante motivato” resta il problema centrale del settore.
PromptArmor: come funziona il filtro basato su LLM
PromptArmor usa un secondo modello linguistico come giudice. Prima che il prompt raggiunga il modello principale, un classificatore basato su LLM analizza il testo in cerca di istruzioni incoerenti con il contesto atteso. Il meccanismo si può schematizzare così:
input_utente -> [Filtro LLM: "questo testo contiene istruzioni anomale rispetto al task?"]
-> se SOSPETTO: blocca o richiede conferma umana
-> se PULITO: passa al modello principale
output_modello -> [Filtro LLM: "l'output rivela dati sensibili o esegue azioni non richieste?"]
-> se ANOMALO: blocca la risposta
-> se PULITO: consegna all'utenteIl doppio controllo, in entrata e in uscita, spiega perché la riduzione dell’ASR misurata su AgentDojo superi il 99%, con falsi positivi e falsi negativi sotto l’1%. Il prezzo da pagare è la latenza: ogni richiesta passa attraverso due chiamate aggiuntive al modello filtro, per un overhead misurato tra 200 e 600 millisecondi. Per un chatbot conversazionale è un costo accettabile. Per un’API che deve rispondere in tempo reale a migliaia di richieste al secondo, può diventare un collo di bottiglia.
PromptGuard risolve parte di questo problema con un’architettura a quattro livelli più leggera, che scende sotto gli 8 millisecondi di overhead. Paga il compromesso con una riduzione dell’ASR più contenuta, il 67% contro il 99% di PromptArmor, misurata però su un benchmark diverso (PromptBench/InjectBench invece di AgentDojo), il che rende il confronto diretto tra i due numeri indicativo più che rigoroso.
SecAlign e ReasAlign: quando la difesa entra nei pesi del modello
SecAlign resta uno dei riferimenti più citati per il fine-tuning orientato alla sicurezza. Secondo la guida di Sysdig aggiornata al 2026, SecAlign “manca circa un attacco su dieci basato su ottimizzazione”, cioè lascia un ASR residuo di circa il 10% contro le tecniche di attacco più sofisticate, quelle che cercano sistematicamente il percorso più debole nel modello.
ReasAlign, pubblicato a gennaio 2026, migliora questo risultato portando l’ASR al 3,6% su un benchmark open-ended. La differenza tecnica principale è l’integrazione del ragionamento esplicito nel processo di allineamento: il modello non impara solo a rifiutare pattern noti, ma a spiegare a sé stesso perché un’istruzione è sospetta prima di eseguirla. Anche in questo caso, però, i risultati arrivano da benchmark statici, non da scenari con un avversario che adatta l’attacco in tempo reale come accade in StakeBench. Per chi vuole replicare questi esperimenti su un modello open-weight, framework come quelli confrontati nel nostro approfondimento su LLaMA-Factory, Axolotl e Hugging Face offrono già le pipeline di training necessarie per costruire un dataset avversariale e lanciare il fine-tuning senza scrivere l’infrastruttura da zero.
Il vantaggio strutturale del fine-tuning rispetto ai filtri è l’assenza di overhead in inferenza. Una volta addestrato, il modello non richiede una seconda chiamata LLM per ogni richiesta. Lo svantaggio è la rigidità: aggiornare le difese significa ripetere un ciclo di training, non semplicemente aggiornare le regole di un filtro. Per un’azienda che deve reagire a una nuova tecnica di attacco scoperta oggi, un filtro si aggiorna in ore, un modello fine-tuned richiede giorni o settimane.
Il caso InjecAgent: fine-tuning avversariale e riduzione del 92%
Il dato più citato a favore del fine-tuning avversariale arriva dall’esperimento InjecAgent, riportato da Axis Intelligence. Un GPT-4 sottoposto a fine-tuning su esempi avversari ha raggiunto un ASR del 3,8%, contro il 47% della versione che si affidava solo a istruzioni di sistema senza addestramento specifico. La riduzione relativa è superiore al 92% (calcolata come (47-3,8)/47), più di dodici volte inferiore al punto di partenza.
Il paradosso interessante è che la stessa tecnica, applicata al contrario, funziona anche per rompere l’allineamento. Gli autori dello studio “Fine-tuning Aligned Language Models” spiegano che “per esempio, disattiviamo le protezioni di sicurezza di GPT-3.5 Turbo facendo fine-tuning su appena 10 esempi di questo tipo, a un costo inferiore a 0,20 dollari tramite le API di OpenAI, rendendo il modello disponibile a rispondere praticamente a qualsiasi istruzione dannosa”. È la prova che il fine-tuning è un’arma a doppio taglio: la stessa economicità che rende conveniente addestrare un modello a resistere agli attacchi rende altrettanto economico addestrarne uno a cedere.
Questo dato ha una conseguenza pratica diretta per chi gestisce modelli open-weight: se un modello scaricabile può essere de-allineato con meno di un dollaro di calcolo, qualsiasi garanzia di sicurezza costruita durante il training originale va considerata provvisoria nel momento in cui il modello lascia i server del produttore e finisce in mano a terzi che possono fare fine-tuning in autonomia.
Quanto costano queste difese: tabella dei costi di implementazione
Non esiste un listino prezzi ufficiale per queste tecniche, perché la maggior parte nasce da ricerca accademica o da implementazioni interne, non da prodotti commerciali con pricing pubblico. Si può però stimare il costo relativo osservando overhead di latenza, numero di chiamate LLM aggiuntive e impegno ingegneristico richiesto.
| Approccio | Costo di implementazione | Overhead latenza | Costo operativo in inferenza | Nota |
|---|---|---|---|---|
| Filtro LLM in stile PromptArmor | Medio-alto (serve un secondo modello come giudice) | 200-600 ms per richiesta | Raddoppia le chiamate LLM per richiesta | Riduzione ASR più alta misurata (>99% su AgentDojo) |
| Filtro multi-layer leggero (PromptGuard 4L) | Basso-medio | <8 ms | Overhead marginale | Miglior rapporto tra latenza ed efficacia |
| Fine-tuning avversariale (stile InjecAgent/SecAlign/ReasAlign) | Variabile: costo di training una tantum, dipende da dataset e GPU cloud usate | Nessuno in inferenza | Nessuno oltre l’inferenza normale del modello | Lo studio arXiv 2310.03693 mostra che con soli 10 esempi il fine-tuning costa meno di 0,20 $ via API: un indicatore di quanto sia economico anche il lato difensivo, se il dataset resta piccolo |
| Classificatore regex/NLP classico | Basso | <5 ms | Trascurabile | Riduzione limitata al 18%, utile solo come primo filtro grezzo |
| Difesa in profondità combinata | Alto (richiede coordinamento tra più team) | Somma degli overhead dei componenti scelti | Somma dei costi dei componenti scelti | Nessun sistema pubblico raggiunge ASR zero, nemmeno combinando tutto |
La lezione economica è semplice: i filtri costano in latenza e in chiamate LLM ripetute a ogni richiesta, il fine-tuning costa in fase di addestramento ma quasi nulla in produzione. Per applicazioni ad alto volume di traffico, dove ogni millisecondo e ogni chiamata API pesano sul conto cloud, il fine-tuning diventa più conveniente nel tempo, a patto di avere le competenze interne per ripeterlo quando emergono nuove tecniche di attacco.
5 casi reali di prompt injection e difese in azione
Dietro le percentuali dei benchmark ci sono scenari concreti che i team di sicurezza incontrano ogni giorno. Ecco cinque casi documentati nel 2026.
- Agenti di navigazione web compromessi. Nello studio StakeBench, agenti costruiti su NanoBrowser e BrowserUse, alimentati da GPT-5 e Gemini-2.5-Flash, hanno eseguito istruzioni malevole nascoste in pagine web nel 79% dei test con attacco diretto. Il rischio concreto: un agente che prenota voli o gestisce email aziendali può essere dirottato da una singola pagina compromessa durante una ricerca.
- Fuga di system prompt in applicazioni reali. Il test di tianpan.co su 50 applicazioni costruite su una piattaforma AI diffusa ha estratto il system prompt, spesso contenente logica di business proprietaria, nel 68% dei casi tramite query avversarie mirate. Molte aziende non sanno che le istruzioni interne del proprio prodotto sono recuperabili con poche domande ben formulate.
- Jailbreak a basso costo di modelli open-weight. Lo studio arXiv 2310.03693 dimostra che bastano 10 esempi e meno di 0,20 dollari di fine-tuning per disattivare le protezioni di GPT-3.5 Turbo. Chiunque scarichi un modello open-weight con licenza permissiva può replicare la stessa tecnica su hardware proprio, senza passare dalle API di un fornitore che potrebbe bloccare l’operazione.
- Filtri aggirati con attacco adattivo. Il Prompt Sandwiching, che dichiara un ASR dell’1% nei test originali, crolla oltre il 95% quando l’attaccante adatta la formulazione, secondo i dati citati da Nasr e colleghi (arXiv:2510.09023). È il promemoria che un numero positivo in laboratorio non garantisce nulla contro un avversario che itera sulla difesa specifica che sta affrontando.
- Difesa in profondità in ambito enterprise. Microsoft raccomanda ufficialmente, per Copilot e prodotti simili, una combinazione di controlli probabilistici e deterministici invece di affidarsi a un singolo layer. La logica: nessuna singola tecnica basta, ma la somma di più livelli riduce l’impatto anche quando un livello fallisce.
Guida alla migrazione: da un singolo prompt a una difesa in profondità
Molte aziende partono da un system prompt scritto a mano con qualche riga tipo “ignora istruzioni contrarie a queste regole”. I dati del 2026 mostrano che questa protezione da sola non regge: è la base di partenza del Prompt Sandwiching, che crolla sotto attacco adattivo. Ecco un percorso di migrazione in sei passaggi verso un’architettura più solida.
- Misura il punto di partenza. Esegui il tuo sistema attuale contro un benchmark pubblico come AgentDojo o PromptBench prima di cambiare qualsiasi cosa. Senza una baseline non puoi dimostrare che la nuova difesa migliora davvero le cose.
- Aggiungi un classificatore di input leggero. Parti da un filtro regex/NLP a bassa latenza (sotto i 5 ms) come primo scudo grezzo contro i pattern di attacco più noti e ripetuti.
- Introduci il controllo sull’output. Non basta filtrare l’input: verifica anche che la risposta del modello non riveli dati sensibili o esegua azioni non richieste, seguendo il modello a due controlli di PromptArmor.
- Valuta il fine-tuning avversariale per i componenti ad alto volume. Se la latenza dei filtri diventa un collo di bottiglia, sposta la protezione dentro il modello con un dataset di esempi avversari, seguendo l’approccio InjecAgent o SecAlign.
- Isola i privilegi con un’architettura dual-LLM. Separa il modello che legge contenuti non fidati (email, pagine web) da quello che esegue azioni con privilegi, così un’istruzione iniettata nel primo non può comandare direttamente il secondo.
- Aggiungi human-in-the-loop per le azioni ad alto impatto. Qualsiasi azione irreversibile, un pagamento, una cancellazione, un invio massivo, deve passare da una conferma umana finché non esiste un sistema che raggiunge in modo dimostrabile la “regione di comportamento robusto” citata da StakeBench.
Il punto chiave della migrazione è che i sei passaggi non sono alternativi tra loro. Le aziende che ottengono i risultati migliori nei report 2026 combinano più livelli, accettando che ognuno da solo lasci uno spiraglio.
Licenze open-weight: quali modelli si prestano davvero al fine-tuning di sicurezza
Il fine-tuning avversariale richiede accesso ai pesi del modello, quindi la scelta della licenza non è un dettaglio legale marginale ma una condizione tecnica di partenza. Con le API chiuse di fornitori come OpenAI o Anthropic si può fare fine-tuning solo tramite l’interfaccia offerta dal produttore, con vincoli su dataset e parametri. Con un modello open-weight, invece, il controllo è totale.
Secondo la mappatura delle licenze aggiornata da codersera.com, la maggior parte dei modelli open-weight più recenti ha abbandonato le licenze restrittive a favore di condizioni più semplici. DeepSeek V4, rilasciato il 23 aprile 2026, usa la licenza MIT, la stessa che copriva già DeepSeek V3. Gemma 4, Qwen 3.5 e Mistral Large 3 sono distribuiti sotto Apache 2.0, secondo lo stesso rapporto: sono anche tra i modelli che confrontiamo per capacità di ragionamento nel nostro test Mistral Small 4 contro Qwen3.8 Max, utile per chi deve scegliere non solo in base alla licenza ma anche alle prestazioni di base su cui costruire il fine-tuning di sicurezza. Datanorth.ai, in una guida separata, indica Qwen, DeepSeek V4 e GLM come “i default sicuri” quando la priorità è la pulizia della licenza, cioè l’assenza di clausole che limitano il fine-tuning commerciale.
Llama 5, al contrario, resta sotto la Meta Community License, che impone un limite di 700 milioni di utenti attivi mensili e vieta l’uso del modello per addestrare sistemi concorrenti, un vincolo che pesa soprattutto per le aziende che vogliono costruire un prodotto di sicurezza da rivendere ad altri. Per chi progetta una pipeline di fine-tuning avversariale interna, senza intenzione di rivendere il modello risultante, questi limiti pesano meno; per chi vuole offrire PromptArmor o SecAlign come servizio a terzi, la scelta della licenza di partenza diventa invece decisiva.
5 casi d’uso consigliati: quale difesa scegliere per ogni scenario
La scelta tra filtro esterno e fine-tuning avversariale, o la loro combinazione, dipende dal profilo di traffico, dal budget di latenza e dal livello di privilegio che l’agente AI possiede. Ecco cinque scenari concreti con la raccomandazione più coerente con i dati raccolti finora.
- Chatbot di assistenza clienti a basso volume. Un filtro in stile PromptArmor è la scelta più sicura: la latenza di 200-600 ms resta impercettibile in una conversazione testuale e la riduzione dell’ASR superiore al 99% protegge da tentativi di estrazione di dati sensibili o istruzioni interne.
- API con migliaia di richieste al secondo. Qui la latenza di un filtro pesante diventa un problema di scala. Meglio un filtro leggero come PromptGuard (sotto gli 8 ms) combinato con fine-tuning avversariale sul modello di base, per spostare la protezione principale fuori dal percorso critico di risposta.
- Agenti di navigazione web con accesso a email o calendari. I dati di StakeBench, con il 79% di successo degli attacchi diretti, impongono la combinazione più aggressiva: filtro su input e output, architettura dual-LLM che isola il componente che legge pagine non fidate, e conferma umana per ogni azione che modifica dati reali.
- Sistemi RAG aziendali con documenti riservati. Il rischio principale qui non è l’esecuzione di un’azione ma la fuga di informazioni, come mostra il 68% di system prompt estraibili nello studio di tianpan.co. Priorità al controllo sull’output e al monitoraggio del tasso di membership-inference (MIA), con soglia di allerta sopra un AUC di 0,65.
- Startup che fa fine-tuning su un modello open-weight per un prodotto verticale. Conviene partire da un modello con licenza pulita come DeepSeek V4 (MIT) o Qwen (Apache 2.0), includere fin da subito esempi avversari nel dataset di training seguendo l’approccio InjecAgent, e non affidarsi soltanto al comportamento ereditato dal modello base.
- Prodotti regolamentati (sanità, finanza, pubblica amministrazione). La combinazione raccomandata da Microsoft, mitigazioni probabilistiche più deterministiche sovrapposte, resta l’unica compatibile con requisiti di audit: un filtro da solo non basta a documentare perché una richiesta è stata bloccata, mentre un modello fine-tuned da solo non lascia una traccia ispezionabile riga per riga.
Pro e contro: filtri esterni contro fine-tuning avversariale
Riassumere i vantaggi e i limiti di ogni approccio aiuta a scegliere in base al proprio caso d’uso, più che seguire una moda tecnica.
- Filtri esterni (PromptArmor, PromptGuard), vantaggi: non richiedono di toccare il modello di produzione, si aggiornano rapidamente quando emergono nuovi pattern di attacco, funzionano con qualsiasi modello a monte incluse le API chiuse.
- Filtri esterni, limiti: aggiungono latenza (fino a 600 ms nel caso di PromptArmor), aumentano il costo di inferenza con chiamate LLM aggiuntive, restano vulnerabili se l’attaccante trova un modo per ingannare anche il filtro stesso.
- Fine-tuning avversariale (SecAlign, ReasAlign, InjecAgent), vantaggi: nessun overhead di latenza in produzione, protezione integrata nel comportamento del modello, riduzioni dell’ASR superiori al 90% nei casi meglio documentati.
- Fine-tuning avversariale, limiti: richiede un ciclo di addestramento per ogni aggiornamento delle difese, funziona solo su modelli di cui hai accesso ai pesi (non sulle API chiuse dei grandi fornitori), la stessa tecnica può essere usata da un attaccante per de-allineare il modello con un dataset piccolo ed economico.
Cosa dicono gli esperti sulla difesa dal prompt injection
Simon Willison, sviluppatore software e tra i primi a documentare il prompt injection nel 2022, descrive così la strategia più diffusa: “Ci sono due approcci proposti qui. Primo, puoi usare l’AI contro l’input prima di passarlo al tuo modello. Puoi chiedere: dato questo prompt, ci sono attacchi al suo interno? Cerca di capire se c’è qualcosa di sbagliato in quel prompt nei dati in arrivo che potrebbe sovvertire la tua applicazione. E l’altra cosa che puoi fare è far passare il prompt, e poi fare un altro controllo sull’output e chiedere: dai un’occhiata a quell’output. Sembra che stia facendo qualcosa di indebito? Sembra che sia stato sovvertito in qualche modo?” (simonwillison.net)
Willison sintetizza anche perché i filtri basati su AI sono diventati lo standard de facto: “Una delle soluzioni più proposte contro gli attacchi di prompt injection… è applicare più AI al problema” (simonwillison.net). Ma aggiunge subito un avvertimento diretto sui limiti dell’irrigidimento del system prompt: “Ma non è a prova di proiettile” (simonwillison.net), riferendosi al fatto che anche i system prompt più rigidi possono essere aggirati con abbastanza tentativi.
La documentazione ufficiale di sicurezza Microsoft conferma la stessa filosofia a livello enterprise, raccomandando di “implementare una strategia di difesa in profondità che sovrapponga più mitigazioni probabilistiche e deterministiche per ridurre rischio e impatto del prompt injection indiretto” (learn.microsoft.com).
Sul fronte del fine-tuning, i ricercatori dello studio “Fine-tuning Aligned Language Models” mostrano quanto sia sottile il confine tra difesa e attacco: “Per esempio, disattiviamo le protezioni di sicurezza di GPT-3.5 Turbo facendo fine-tuning su appena 10 esempi di questo tipo, a un costo inferiore a 0,20 dollari tramite le API di OpenAI, rendendo il modello disponibile a rispondere praticamente a qualsiasi istruzione dannosa” (arxiv.org).
Verdetto finale: quale approccio scegliere nel 2026
I dati raccolti in questo confronto portano a una conclusione precisa, non a un pareggio di comodo. Per applicazioni conversazionali a basso-medio volume, dove la latenza aggiuntiva è tollerabile, un filtro in stile PromptArmor offre oggi la riduzione dell’ASR più alta documentata su un benchmark indipendente, oltre il 99% su AgentDojo. È la scelta giusta quando la sicurezza pesa più della velocità di risposta.
Per applicazioni ad alto volume o con vincoli di latenza stretti, come API in tempo reale o agenti che eseguono decine di chiamate a catena, il fine-tuning avversariale in stile InjecAgent o ReasAlign è più sostenibile: nessun overhead in inferenza e una riduzione dell’ASR superiore al 92% nel caso meglio documentato. Il costo si sposta a monte, nella fase di addestramento, e va ripetuto periodicamente.
Per gli agenti che navigano il web o eseguono azioni con privilegi elevati, nessuno dei due approcci preso da solo basta: i dati di StakeBench, con il 79% di successo degli attacchi diretti anche su modelli di frontiera come GPT-5, dimostrano che serve la combinazione vista nella guida alla migrazione, filtro più fine-tuning più isolamento architetturale più conferma umana per le azioni irreversibili. Chi promette una difesa unica al 100% nel 2026 non sta guardando gli stessi dati raccolti in questo articolo: nessun sistema pubblico, secondo le fonti citate, ha ancora dimostrato un ASR pari a zero contro un avversario adattivo.
Domande frequenti sul confronto tra difese anti prompt injection
Cos’è un attacco di prompt injection?
È una tecnica che inserisce istruzioni malevole nell’input di un modello linguistico per fargli ignorare le regole originali del sistema. Può essere diretta, se scritta dall’utente in chat, o indiretta, se nascosta in un documento o una pagina che il modello legge durante il proprio lavoro.
Il fine-tuning avversariale rende un modello immune al prompt injection?
No. Anche i risultati migliori documentati, come il 3,6% di ASR di ReasAlign o il 3,8% del caso InjecAgent, restano sopra lo zero. Riducono drasticamente il rischio, non lo eliminano.
I filtri basati su LLM come PromptArmor rallentano l’applicazione?
Sì, in modo misurabile. PromptArmor aggiunge tra 200 e 600 millisecondi per richiesta perché passa attraverso due chiamate aggiuntive al modello filtro. Alternative più leggere come PromptGuard restano sotto gli 8 millisecondi, a fronte di una riduzione dell’ASR inferiore.
Esiste una difesa certificata al 100% contro il prompt injection?
No. Secondo le fonti raccolte in questo confronto, non esistono ancora difese certificate o dimostrabili crittograficamente contro il prompt injection alla data di pubblicazione. Ogni tecnica misurata riduce l’ASR, nessuna lo azzera in modo dimostrato contro un avversario adattivo.
Quanto costa implementare una difesa in stile PromptArmor rispetto al fine-tuning?
Il filtro costa soprattutto in produzione, con il raddoppio delle chiamate LLM per ogni richiesta e centinaia di millisecondi di latenza aggiunta. Il fine-tuning costa soprattutto in fase di addestramento: gli studi accademici mostrano che con dataset piccoli il costo può scendere sotto il dollaro per run, ma va ripetuto quando cambiano le tecniche di attacco.
Le aziende italiane devono considerare il prompt injection nella propria strategia di sicurezza?
Sì, soprattutto chi integra agenti AI con accesso a email, documenti interni o sistemi di pagamento. Il dato di tianpan.co, con il 68% di system prompt estraibili in applicazioni reali, mostra che anche prodotti già in produzione oggi possono esporre logica di business interna senza che il team se ne accorga.
Qual è la strategia migliore per chi lancia oggi un nuovo agente AI?
Partire dalla difesa in profondità fin dal primo giorno: un classificatore leggero sull’input, un controllo sull’output, isolamento dei privilegi tra il componente che legge contenuti non fidati e quello che esegue azioni, più conferma umana per qualsiasi azione irreversibile. Aggiungere il fine-tuning avversariale quando il volume di traffico rende insostenibile la latenza dei filtri.
Qual è la differenza tra ASR dichiarato su un benchmark proprietario e uno indipendente?
Un ASR misurato dallo stesso team che ha creato la difesa, su una suite di test sviluppata internamente, tende a essere più favorevole di quanto si osservi su benchmark indipendenti come AgentDojo o StakeBench. Il caso di PromptGuard2, con ASR pari a 0,00 sulla propria suite sintetica, va confrontato con cautela rispetto al 79% di successo degli attacchi diretti misurato da StakeBench su agenti reali.
