Un dipendente chiede al proprio assistente aziendale di controllare le email ricevute durante la mattinata, individuare quelle più urgenti e preparare una sintesi. È uno scenario sempre meno futuristico: gli strumenti di intelligenza artificiale stanno progressivamente uscendo dalla semplice finestra di chat e vengono collegati a posta elettronica, documenti, repository, browser, database e servizi esterni.
Tra le email analizzate, però, ce n’è una che contiene istruzioni pensate non per la persona che la riceve, ma per il sistema AI che potrebbe leggerla. Il dipendente non ha dato alcun comando particolare. È il modello ad averlo trovato nel contenuto che stava elaborando.
È in situazioni di questo tipo che la prompt injection smette di sembrare un curioso limite dei chatbot e comincia a diventare un vero problema di sicurezza informatica.
Indice degli argomenti
Prompt injection negli agenti AI: dalla risposta all’azione
Finché un modello si limita a ricevere una domanda e produrre una risposta, anche un comportamento anomalo tende a rimanere confinato alla conversazione: una risposta sbagliata, un contenuto indesiderato, magari la divulgazione di informazioni presenti nel contesto. Quando però lo stesso modello ha accesso a strumenti e sistemi esterni, il problema cambia scala. Può leggere file, interrogare servizi, usare API, preparare email, modificare informazioni o avviare azioni.
A quel punto non basta più chiedersi se un modello possa essere convinto a dire qualcosa che non dovrebbe. Bisogna chiedersi cosa succede quando può essere convinto a fare qualcosa che non dovrebbe.
Quando dati e istruzioni condividono il contesto
Una parte del problema nasce dal modo stesso in cui funzionano i modelli linguistici.
Nel software tradizionale siamo abituati a distinguere abbastanza chiaramente tra codice e dati. Il programma esegue istruzioni definite dallo sviluppatore e tratta gli input come informazioni da elaborare.
Con un Large Language Model questa separazione è molto meno intuitiva. Nel contesto del modello possono finire contemporaneamente le istruzioni definite dall’applicazione, la richiesta dell’utente, la cronologia della conversazione, documenti recuperati da un sistema RAG, pagine web, email, risultati restituiti da API o output prodotti da altri strumenti.
Per noi questi elementi non hanno lo stesso peso. Una direttiva interna dell’applicazione non dovrebbe valere quanto una frase trovata dentro un documento. Una mail ricevuta da un mittente sconosciuto non dovrebbe avere la stessa autorevolezza delle istruzioni impartite allo strumento da chi lo ha progettato.
Per il modello, però, tutto questo diventa comunque linguaggio da interpretare.
Ed è proprio qui che nasce una parte importante del rischio: contenuti che dovrebbero essere semplicemente letti possono cercare di comportarsi come istruzioni.
OWASP colloca infatti la prompt injection al primo posto nella propria Top 10 2025 dedicata alle applicazioni basate su modelli linguistici. Il rischio non riguarda soltanto input esplicitamente malevoli inseriti dall’utente, ma più in generale la possibilità che un contenuto alteri il comportamento previsto del sistema.
La forma più semplice è quella diretta. L’utente parla con il modello e prova a convincerlo a ignorare le istruzioni precedenti, cambiare comportamento, rivelare informazioni o superare determinati limiti. È il caso delle formule ormai note del tipo “ignora tutte le istruzioni precedenti”.
In questi casi il tentativo di manipolazione è evidente: l’attaccante sta interagendo direttamente con il sistema.
La situazione diventa però più interessante quando l’attaccante non parla affatto con l’AI.
Come la prompt injection indiretta raggiunge gli agenti AI
Nella prompt injection indiretta le istruzioni vengono inserite all’interno di una fonte esterna che il modello potrebbe consultare successivamente.
Può essere una pagina web, un PDF, un’email, un documento condiviso, un ticket di assistenza, un README o qualsiasi altro contenuto destinato a entrare nel contesto del sistema.
L’AI recupera quella fonte per svolgere un compito del tutto legittimo e, insieme alle informazioni utili, riceve anche il testo predisposto dall’attaccante.
È una differenza tutt’altro che marginale.
Nella prompt injection diretta l’attaccante deve interagire con il sistema. In quella indiretta può limitarsi a lasciare un contenuto in un luogo che il sistema potrebbe visitare in futuro.
Questo rende il problema particolarmente rilevante per tutti gli strumenti che lavorano in autonomia con dati esterni. Un agente incaricato di fare ricerche online, per esempio, può trovarsi a leggere pagine completamente fuori dal controllo dell’organizzazione che lo utilizza. Lo stesso vale per un assistente che analizza posta elettronica, repository o documentazione caricata dagli utenti.
Documenti, pagine web e sistemi RAG come vettori
E qui cambia anche il significato di “contenuto malevolo”.
Quando parliamo di un file pericoloso pensiamo normalmente a macro, script, exploit o allegati eseguibili. Nel caso della prompt injection non è necessario nulla del genere.
Un documento può essere perfettamente innocuo per il sistema operativo e allo stesso tempo essere problematico per il modello che lo legge.
Può essere un PDF normale. Un file di testo. Una pagina HTML senza codice dannoso.
Il bersaglio non è necessariamente il software che apre il documento. È il sistema che ne interpreta il contenuto.
Pensiamo a un’applicazione RAG utilizzata all’interno di un’azienda. Un dipendente pone una domanda, il sistema cerca i documenti più rilevanti, ne recupera alcuni passaggi e li inserisce nel contesto del modello affinché possa formulare una risposta.
È un’architettura ormai piuttosto comune.
Ma se uno dei documenti contiene istruzioni rivolte al modello, quel documento smette di essere soltanto una fonte di informazioni. Diventa anche un possibile tentativo di influenzare il comportamento del sistema.
Il retrieval, quindi, non rende automaticamente affidabile ciò che viene recuperato. Aumenta le informazioni a disposizione del modello, ma introduce anche nuovi contenuti che devono essere considerati potenzialmente non attendibili.
Privilegi e strumenti amplificano il rischio per gli agenti AI
La questione diventa molto più seria con gli agenti.
Un chatbot che genera soltanto testo ha un impatto relativamente limitato. Un agente, invece, può disporre di strumenti.
Può leggere una casella email, interrogare un database, accedere a un repository, consultare un CRM, navigare sul web o utilizzare API. In alcuni sistemi può anche modificare dati, inviare messaggi o avviare procedure.
A quel punto una prompt injection non cerca più soltanto di modificare la risposta prodotta dal modello. Può cercare di influenzare il modo in cui vengono usati gli strumenti.
Il rischio dipende quindi anche dai privilegi concessi all’agente.
Un modello isolato può essere manipolato, ma ha poche possibilità operative. Un agente che può leggere documenti riservati, comunicare all’esterno e usare servizi aziendali si trova in una situazione completamente diversa.
Dall’agent hijacking alle catene di permessi
Il NIST ha utilizzato il termine “agent hijacking” per descrivere scenari in cui contenuti controllati da un attaccante riescono a deviare il comportamento di un agente verso obiettivi non previsti.
Non è difficile capire perché questo passaggio sia importante. Se il modello sbaglia una risposta, abbiamo un problema di affidabilità. Se utilizza male un permesso, abbiamo anche un problema di sicurezza.
C’è poi un altro elemento che tende a essere sottovalutato: non bisogna guardare soltanto ai singoli privilegi, ma anche a come possono essere combinati.
Un agente può avere accesso in lettura ai documenti interni. Separatamente può avere accesso a Internet. Presi singolarmente, sono due permessi del tutto legittimi. Insieme, però, creano una nuova possibilità: leggere un’informazione dall’interno e trasmetterla verso l’esterno.
Lo stesso vale per altre combinazioni. Accesso a un repository e possibilità di eseguire codice. Lettura della posta e capacità di inviare messaggi. Accesso a un database e possibilità di chiamare servizi esterni.
In molti casi il rischio non sta nel singolo strumento, ma nella sequenza di strumenti che l’agente può mettere insieme.
Prompt injection e confused deputy: fiducia e privilegi
Da questo punto di vista, la prompt injection non introduce solo problemi completamente nuovi. Ne ripropone anche alcuni molto conosciuti.
Uno è il cosiddetto “confused deputy problem”: un sistema che possiede determinati privilegi viene convinto da un soggetto meno privilegiato a usarli in maniera impropria.
Un attaccante non ha accesso diretto a un database, ma l’agente sì. Non può leggere determinati documenti, ma l’agente può farlo. Il suo obiettivo non è necessariamente ottenere quei privilegi in prima persona, ma spingere il componente che li possiede a utilizzarli per suo conto.
Vista così, la prompt injection indiretta diventa molto più facile da collocare nel panorama della sicurezza informatica.
Il vero problema non è il linguaggio in sé. È il rapporto tra linguaggio, fiducia e privilegi.
Ed è qui che si vede anche il limite di una difesa basata soltanto sul prompt.
Si può dire al modello di non seguire istruzioni contenute nei documenti, di non fidarsi delle pagine web o di considerare prioritarie soltanto determinate fonti.
Sono accorgimenti utili, ma non possono diventare l’unico confine di sicurezza.
Stiamo infatti usando un’istruzione linguistica per dire al modello quali altre istruzioni linguistiche debba ignorare. È utile farlo, ma se da quella distinzione dipende l’invio di un file, la modifica di un database o l’uso di un account privilegiato, serve qualcosa di più.
Le difese contro la prompt injection negli agenti AI
È probabilmente questa una delle distinzioni più importanti nella progettazione degli agenti.
Il modello può decidere che una certa azione sia utile. Non dovrebbe però essere l’unico componente a stabilire se quell’azione sia effettivamente consentita.
Se un agente decide di inviare un’email con un allegato, l’applicazione dovrebbe verificare chi è il destinatario, che tipo di file sta per essere inviato, se l’utente possiede i permessi necessari e se l’operazione richiede una conferma.
Validazione dei tool e minimo privilegio
Lo stesso discorso vale per i parametri generati dal modello quando chiama un tool.
Il fatto che siano stati prodotti dall’AI non li rende automaticamente affidabili. Se il comportamento del modello può essere influenzato da un input esterno, anche quei parametri devono essere sottoposti ai normali controlli di sicurezza.
Tornano quindi principi che conosciamo già bene: validazione degli input, allowlist, controllo degli accessi, separazione dei privilegi, sandbox, restrizioni sui percorsi e sulle destinazioni.
La novità è che ora dobbiamo considerare il modello stesso come una possibile sorgente di input non affidabile.
Questo porta direttamente al principio del minimo privilegio.
Se un agente deve riassumere la posta, forse gli basta poter leggere i messaggi. Non è detto che debba anche cancellarli, inoltrarli o inviarne di nuovi.
Se deve consultare documenti, può essere sufficiente consentirgli di leggerli senza permettergli automaticamente di modificarli o condividerli.
Se deve monitorare un’infrastruttura, potrebbe aver bisogno di accedere ai log e alle metriche senza avere anche il potere di eseguire deploy o riavviare servizi.
La domanda da fare in fase di progettazione non è soltanto “di cosa ha bisogno l’agente per funzionare?”, ma anche “cosa potrebbe fare se qualcosa riuscisse a influenzarlo?”.
Supervisione umana con contesto e attenzione
Un’altra difesa naturale consiste nel mantenere una persona nel processo.
Per le operazioni più sensibili l’agente può proporre l’azione e chiedere conferma prima di eseguirla.
È una misura importante, ma non bisogna attribuirle più forza di quella che ha.
Se un dipendente riceve una richiesta di conferma ogni tanto, probabilmente la valuterà. Se ne riceve decine al giorno, tutte molto simili, finirà facilmente per cliccare senza leggere.
È un problema che conosciamo già con alert di sicurezza, cookie banner, finestre di autorizzazione e notifiche continue: quando tutto richiede attenzione, nulla riceve davvero attenzione.
Per questo la supervisione umana dovrebbe essere usata soprattutto nei punti in cui serve davvero e dovrebbe fornire abbastanza contesto per prendere una decisione.
“Confermi questa operazione?” dice poco.
“Questo file contenente dati interni verrà inviato a un dominio esterno” permette invece di capire cosa si sta autorizzando.
La presenza di una persona nel flusso non basta, se quella persona non dispone delle informazioni necessarie per valutare quello che sta succedendo.
Osservabilità delle azioni e delle sequenze
C’è infine un tema che diventerà sempre più importante: l’osservabilità.
Quando qualcosa va storto, bisogna poter ricostruire il percorso seguito dal sistema.
Quale documento è stato consultato? Quale contenuto ha influenzato la decisione? Quale strumento è stato utilizzato? Con quali parametri? Quali operazioni sono state eseguite dopo?
Nel software tradizionale siamo già abituati a registrare accessi, chiamate API, errori e modifiche ai dati. Con gli agenti sarà necessario estendere questo ragionamento anche al loro processo operativo.
Non significa salvare indiscriminatamente tutto, perché ci sono ovviamente problemi di privacy e protezione dei dati. Significa però avere abbastanza informazioni per distinguere un errore, una manipolazione e un comportamento legittimo.
Soprattutto perché, in un sistema agentico, una singola azione può sembrare innocua. È la sequenza complessiva a diventare sospetta.
Defense in depth per contenere la prompt injection
È probabilmente questo il punto su cui vale la pena essere più chiari.
Non esiste una singola soluzione alla prompt injection.
Un prompt migliore può aiutare. Un filtro può bloccare parte dei contenuti sospetti. Il principio del minimo privilegio limita l’impatto. Una conferma umana aggiunge un ulteriore controllo. La validazione dei tool impedisce che alcune decisioni del modello arrivino direttamente ai sistemi sottostanti.
Nessuna di queste misure, da sola, è sufficiente.
La strategia più realistica rimane quella della defense in depth: costruire più livelli indipendenti in modo che il fallimento di uno non coincida automaticamente con il fallimento dell’intero sistema.
È anche per questo che parlare di “eliminare” la prompt injection può essere fuorviante.
Come molte altre minacce informatiche, è più realistico considerarla un rischio da gestire. Si cerca di ridurre la probabilità che l’attacco riesca, di limitare l’impatto nel caso in cui avvenga e di rendere più difficile la propagazione verso altre parti del sistema.
In questo senso, un agente sicuro non è necessariamente un agente impossibile da manipolare. È un agente progettato in modo che una manipolazione del modello non si trasformi automaticamente nella compromissione dell’applicazione.
Il fallimento del modello non dovrebbe diventare il fallimento della sicurezza.
La prompt injection porta la sicurezza AI oltre la chat
Alla fine, la prompt injection racconta qualcosa di più ampio dell’attacco in sé.
Per molto tempo abbiamo discusso della sicurezza dell’intelligenza artificiale concentrandoci soprattutto sui contenuti che un modello poteva generare. Con gli agenti dobbiamo iniziare a guardare anche ai sistemi a cui può accedere.
Un modello collegato a email, file, database, browser e API non è più soltanto uno strumento che produce testo. Diventa un componente operativo dell’architettura.
E come qualsiasi componente operativo deve avere confini, privilegi, controlli e meccanismi di verifica.
In fondo, molti dei principi necessari non sono nuovi. Non fidarsi ciecamente degli input. Limitare i privilegi. Controllare le autorizzazioni. Separare i sistemi. Registrare le operazioni. Verificare prima di eseguire.
Quello che cambia è la natura dell’input.
Una frase presente in un documento può essere irrilevante per un software tradizionale e diventare significativa per un agente che interpreta il linguaggio e possiede gli strumenti per agire.
Ed è probabilmente questo il punto in cui la prompt injection diventa davvero interessante dal punto di vista della cybersecurity.
Non perché dimostri che possiamo far dire qualcosa di strano a un chatbot, ma perché mette in discussione il modo in cui stiamo costruendo sistemi AI sempre più autonomi.
La domanda, quindi, non è più soltanto se un modello possa essere convinto a dire qualcosa che non dovrebbe.
È cosa succede quando, dopo averlo convinto, gli abbiamo anche dato accesso ai sistemi su cui può intervenire.
Partecipa alla community