La prompt injection è una tecnica di attacco che sfrutta un limite strutturale dei modelli linguistici: l’incapacità di distinguere tra le istruzioni da eseguire e i dati da elaborare.

Per un LLM tutto ciò che entra nel contesto ha lo stesso peso: il prompt di sistema sviluppato da chi ha creato l’applicazione, la domanda dell’utente, un documento aziendale estratto via RAG e la risposta di un tool esterno. Poiché nessun input possiede un livello di privilegio superiore agli altri, qualsiasi frase formulata come comando può essere trattata come un’istruzione legittima. Da lì, l’attaccante può scavalcare le regole, accedere a informazioni riservate o far compiere all’agente azioni non autorizzate.

Non si tratta del difetto di un singolo modello, bensì del funzionamento stesso della GenAI. Per questo motivo, la difesa deve essere progettata a livello architetturale, non limitandosi a scrivere prompt più sicuri.

La prompt injection come proprietà architetturale degli LLM

Un’applicazione web tradizionale separa il codice dai dati: una query parametrizzata neutralizza la SQL injection perché il database sa cos’è istruzione e cos’è input utente. Un LLM non ha questo confine: system prompt, messaggio dell’utente, contenuto di un documento recuperato da un sistema RAG e output di un tool arrivano al modello come un unico flusso di token. Sebbene tecniche come la instruction hierarchy insegnino al modello a dare priorità alle istruzioni di sistema, si tratta di una preferenza statistica e non di un blocco di sicurezza garantito.

Questo spiega perché la prompt injection occupa da due edizioni consecutive (2023 e 2025) la posizione LLM01 nella OWASP Top 10 for LLM Applications, e perché non esiste una patch definitiva. 

Non si tratta di un difetto di implementazione di un vendor specifico: è il prezzo dell’interfaccia in linguaggio naturale. Le difese efficaci non eliminano la vulnerabilità, la contengono. Riducono il numero di istruzioni ostili che arrivano al modello e, soprattutto, il danno che possono fare quando ci arrivano comunque. Chi progetta partendo dal presupposto che qualche payload passerà sempre costruisce sistemi più robusti di chi cerca il filtro perfetto.

La conseguenza pratica per chi progetta architetture enterprise è che ogni input non fidato che raggiunge un LLM va trattato come codice potenzialmente eseguibile, non come testo.

Injection diretta vs indiretta: vettori d’attacco a confronto

Per comprendere le superfici d’attacco a cui sono esposti gli LLM, è fondamentale distinguere tra due principali vettori d’ingresso:

• Injection diretta: l’attaccante è l’utente stesso che inserisce il payload nella chat.
• Injection indiretta l’istruzione ostile è nascosta in contenuti letti automaticamente dal sistema (ticket di supporto, email, PDF, pagine web). Si tratta della forma più pericolosa perché scala facilmente e può usare elementi invisibili all’occhio umano (testo bianco su fondo bianco, caratteri unicode trasparenti, alt text di immagini o tracce audio).

Nella tabella seguente mettiamo a confronto i principali vettori d’attacco, evidenziandone la modalità d’ingresso, l’obiettivo e la complessità di rilevamento:

Il jailbreaking punta a far ignorare le policy di contenuto al modello (generando output inappropriati). L’injection indiretta su un agente collegato a sistemi aziendali punta invece a causare un vero e proprio data breach.

Agentic Risk: quando il testo diventa azione

L’agentic risk emerge quando un modello non si limita a generare testo, ma invoca strumenti ed esegue azioni per conto dell’utente (leggere email, interrogare database, aggiornare CRM).

Alcune vulnerabilità reali, scoperte da ricercatori di sicurezza in prodotti in produzione, dimostrano la portata del problema.

• EchoLeak (CVE-2025-32711): Una singola email malevola ha permesso l’esfiltrazione automatica di dati da Microsoft 365 Copilot. Il payload ha eluso i filtri e sfruttato link Markdown per inviare informazioni all’esterno.
• CurXecute (CVE-2025-54135): Un’injection su agenti di coding ha portato all’esecuzione di codice arbitrario sulla macchina dello sviluppatore tramite file di configurazione MCP alterati.
• ForcedLeak (Salesforce Agentforce): Prompt nascosti in form web-to-lead hanno esposto e inviato dati clienti verso domini esterni.

Il problema si amplifica con l’adozione del Model Context Protocol (MCP) e dei sistemi di tool calling: ogni server o tool collegato diventa infatti una potenziale superficie d’attacco (tool poisoning).

Per mitigare l’impatto delle vulnerabilità nei sistemi AI, è fondamentale applicare il principio noto come ‘lethal trifecta’ di Simon Willison: un agente non dovrebbe mai combinare accesso a dati sensibili, esposizione a contenuti non fidati e capacità di comunicare verso l’esterno o modificare sistemi.

Data exfiltration e protezione dei dati PII

Nelle architetture GenAI enterprise, la fuoriuscita di dati sensibili è un fattore strutturale, non accidentale: ogni chiamata a un LLM di terze parti trasferisce il contesto del prompt fuori dai confini aziendali. Questo aspetto riguarda la data residency e il trattamento dei dati, e va gestito sia sul piano contrattuale (DPA, policy zero data retention) sia su quello tecnico.

L’esfiltrazione tramite injection rappresenta però un problema diverso: l’attaccante manipola il modello per fargli inserire informazioni riservate (Knowledge Base, cronologia chat o output di tool) in un canale liberamente accessibile.

Le tecniche utilizzate sono note:

• Immagini Markdown malevole: il modello viene istruito a generare un’immagine il cui URL contiene i dati da esfiltrare, che il client richiede automaticamente al caricamento.
• Abuso dei tool di rete: il sistema viene indotto a invocare uno strumento di ricerca web includendo dati sensibili nella query.
• Risposte non autorizzate: il modello fornisce direttamente informazioni che l’utente non avrebbe il permesso di visualizzare.

In tutti questi casi, il traffico in uscita appare legittimo se non viene opportunamente ispezionato. Per mitigare il rischio servono tre contromisure: sanificazione o allowlist degli URL e delle immagini nell’output, Content Security Policy (CSP) restrittive sul client ed egress allowlist per i tool aziendali.

Come prevenire la prompt injection: una difesa in profondità

Proteggere i workflow GenAI in ambienti enterprise richiede un cambio di paradigma. La sicurezza non può affidarsi a un singolo filtro: deve adattarsi a uno scenario di minaccia dinamico e stratificato. 

Per evitare che un input ostile comprometta i sistemi aziendali, una difesa efficace combina quindi la verifica del traffico all’ingresso e all’uscita con un’architettura che limita drasticamente l’impatto di un’eventuale violazione.

Possiamo riassumere le contromisure in alcuni pilastri fondamentali:

• Filtraggio e anonimizzazione del traffico: bloccare i pattern noti con regole deterministiche, usare modelli verificatori (LLM-as-a-judge) per le minacce semantiche e pseudonimizzare le PII (es. sostituendo codici fiscali e IBAN con segnaposto) sia nei prompt che nelle risposte.
• Separazione tra istruzioni e dati: isolare i contenuti esterni dai comandi di sistema (es. tramite tag di delimitazione o architetture “Dual LLM”) per evitare che dati non fidati vengano interpretati come istruzioni eseguibili.
• Minimo privilegio e isolamento delle azioni: limitare il raggio d’azione dell’agente (es. richiedendo l’approvazione umana prima di inviare email o chiamare API) e sanificare gli output prima di passarli ai sistemi a valle.

La gestione di questi pilastri non è soltanto una sfida tecnica: diventa rapidamente una priorità di governance con dirette implicazioni legali e regolatorie.

Governance e compliance

Nei comitati di rischio la domanda fondamentale riguarda l’accountability. Se un agente aziendale manipolato invia dati personali all’esterno, si configura un data breach ai sensi del GDPR, con l’obbligo di notificarlo all’autorità di controllo entro 72 ore da quando se ne ha conoscenza, salvo che il rischio per gli interessati sia improbabile

L’AI Act rafforza questo quadro: per i sistemi ad alto rischio, dal dicembre 2027 l’assenza di controlli sugli input e di log renderà difficile dimostrare la conformità agli obblighi di robustezza e tracciabilità automatica degli eventi.

Questo scenario sposta l’attenzione dal controllo applicativo alla protezione a livello di piattaforma. Implementare guardrail sparsi nelle singole applicazioni genera coperture disomogenee, complesse da auditare e difficili da aggiornare. Al contrario, centralizzare le difese interponendo un AI Gateway sull’infrastruttura garantisce policy uniformi e un unico punto di manutenzione.

È in questo contesto che si inserisce il Radicalbit AI Gateway, progettato per offrire un livello unificato di controllo e protezione:

• Centralizzazione dei controlli: intercetta tutto il traffico verso i provider LLM applicando guardrail bidirezionali sull’input e sull’output, tra cui de-identificazione PII (sfruttando motori come Microsoft Presidio per NER, regex, codici fiscali e P.IVA), valutazione semantica e controllo degli accessi.
• Audit e tracciabilità in tempo reale: espone metriche aggregate per policy, fornendo immediatamente i dati necessari agli audit senza dover ricostruire i log dai singoli microservizi.
• Gestione dei consumi: applica tetti di rate limit, budget e token per progetto direttamente sul punto di passaggio.
• Sicurezza On-Premise e Data Residency: installandosi direttamente sull’infrastruttura aziendale, mantiene il piano di governo e di controllo totalmente all’interno del perimetro privato, anche quando si utilizzano modelli esterni.

Nessuna soluzione elimina del tutto la prompt injection, e il Radicalbit AI Gateway non fa eccezione. Tuttavia, sposta la difesa in un punto centrale dove risulta misurabile, auditabile e aggiornabile con un’unica operazione per tutta l’azienda.

La soluzione è disponibile anche in versione open source su GitHub, mentre il team Radicalbit è a disposizione per valutazioni dedicate in contesti enterprise.

Domande frequenti sulla prompt injection

Key takeaways

• La prompt injection è un limite architetturale degli LLM che non si risolve con una patch: richiede infatti difese progettate a livello di sistema.
• L’injection indiretta è la minaccia più pericolosa perché sfrutta fonti dati considerate fidate, senza richiedere un’azione dell’utente.
• Nei sistemi agentici il rischio diventa operativo, trasformando un input manipolato nell’esecuzione non autorizzata di azioni e chiamate API.
• La sicurezza richiede una strategia multilivello che combini filtri deterministici, anonimizzazione PII, controlli semantici e privilegi minimi per gli agenti.
• L’adozione di una soluzione come il Radicalbit AI Gateway centralizza la governance aziendale, permettendo di gestire e aggiornare le policy di protezione in un unico punto.