Prompt injection: come proteggere gli agenti IA

Un'email letta dall'agente non deve diventare un'autorizzazione a inviarne un'altra, esportare dati dei clienti o modificare una trattativa. È questo il confine da proteggere dagli attacchi di prompt injection, che l'Open Worldwide Application Security Project (OWASP) colloca alla voce LLM01 della sua Top 10 per le applicazioni LLM. Per chi sviluppa, la risposta concreta è limitare ciò che l'applicazione può fare anche quando il modello segue l'istruzione sbagliata. Oggi nessuna difesa risolve completamente il problema.

Verificato sulle indicazioni aggiornate di OWASP e Anthropic il 26 ottobre 2026. Gli scenari relativi a posta elettronica e CRM descritti di seguito sono esempi progettuali, non risultati osservati in sistemi in produzione.

Che cos'è la prompt injection?

Si parla di prompt injection quando un input spinge un modello linguistico a deviare dalle istruzioni previste. Un modello linguistico di grandi dimensioni, o LLM, interpreta il linguaggio per produrre risposte e proporre azioni. Il problema nasce quando un contenuto che dovrebbe limitarsi a leggere diventa qualcosa a cui obbedisce.

Immaginiamo un dipendente che esamina una lettera di un fornitore. La lettera può descrivere un problema con una consegna; non può autorizzare il fornitore ad accedere al database dei clienti. Anche un agente deve distinguere tra informazione e autorità, e spetta ai controlli dell'applicazione far rispettare questa distinzione.

In LLM01:2025 Prompt Injection, OWASP individua come punti di ingresso sia l'input diretto dell'utente sia i contenuti esterni che arrivano per via indiretta. Il confine decisivo riguarda chi può definire il compito e i permessi, non quanto sembri professionale il testo sospetto.

Una risposta sbagliata non è automaticamente il risultato di un'iniezione. Il modello può inventare un fatto anche senza manipolazioni esterne. La prompt injection implica invece un input che ne orienta il comportamento. Entrambi i problemi possono provocare danni, ma un filtro che cerca istruzioni ostili non intercetta tutti gli errori ordinari del modello.

Come funziona la prompt injection nell'IA generativa?

Il modello legge insieme le istruzioni e i materiali necessari al compito, e può attribuire a questi ultimi un'autorità che non dovrebbero avere. Ruoli ed etichette che identificano le fonti aiutano a distinguerli, ma non sostituiscono i controlli di accesso.

Con un agente si aggiunge un passaggio dalle conseguenze concrete: l'applicazione trasforma l'azione proposta in una chiamata a uno strumento. Uno strumento è una funzione che opera al di fuori della conversazione, per esempio cercando record o inviando un messaggio. Se l'applicazione esegue qualsiasi proposta del modello usando credenziali con ampi permessi, un errore nell'interpretazione del linguaggio può trasformarsi in un'azione aziendale.

È il limite con cui si scontra ogni agente che usa strumenti: capire una richiesta non significa aver accertato che sia autorizzata.

Esempi di prompt injection: attacchi diretti e indiretti

La differenza sta nel canale attraverso cui arriva l'istruzione ostile. Questi esempi descrivono il comportamento che l'attaccante cerca di ottenere, senza pubblicare il testo dell'attacco.

Prompt injection diretta

Un cliente scrive a un assistente di supporto e cerca di convincerlo a rivelare le note dell'account di un altro cliente, fingendo che la richiesta goda di una speciale autorizzazione interna. L'attaccante usa direttamente il canale di input dell'applicazione.

Tra le difese deve esserci un servizio di accesso ai record che verifichi i permessi del cliente autenticato. Anche se il modello crede alla storia, il servizio deve negare l'accesso al record altrui. Un'istruzione di rifiuto nel system prompt è un'indicazione utile; è il controllo sui record a far rispettare il confine.

Prompt injection indiretta

Un fondatore che segue le vendite chiede a un agente di riassumere l'email di un potenziale cliente e suggerire il passo successivo. L'email contiene materiale concepito per indurre l'agente a esportare contatti estranei alla richiesta dal sistema di gestione delle relazioni con i clienti (CRM) verso un destinatario esterno. La richiesta del fondatore è legittima; l'istruzione ostile arriva dall'email da elaborare.

Lo stesso meccanismo può passare da una pagina web, un documento, un allegato o il risultato di uno strumento. Il fatto che un contenuto sia archiviato internamente non rende affidabile ogni record: il testo ora presente nel CRM potrebbe essere stato fornito da un cliente. Anthropic, l'azienda che sviluppa il modello linguistico Claude, considera queste fonti di terze parti un modello di minaccia distinto nelle sue indicazioni sulle difese dalla prompt injection.

In un agente che gestisce la posta, chi invia l'email non deve mai ereditare i permessi del titolare della casella sugli strumenti solo perché quest'ultimo ha chiesto un riepilogo.

Prompt injection e jailbreak: qual è la differenza?

Un jailbreak tenta di aggirare le restrizioni di sicurezza del modello. La prompt injection può colpire anche il normale compito dell'applicazione o i suoi permessi. Un riepilogo commerciale alterato o l'aggiornamento non autorizzato di un contatto possono sembrare innocui a un sistema di moderazione dei contenuti, pur violando le regole dell'azienda.

Servono sia misure di protezione sui contenuti sia controlli delle autorizzazioni. Rispondono a domande diverse.

Perché gli attacchi di prompt injection sono un rischio per l'azienda

Il danno cresce con i dati e le azioni a cui l'agente può accedere. Nelle sue indicazioni dedicate all'Excessive Agency, OWASP identifica un eccesso di funzionalità, permessi e autonomia tra le cause dei comportamenti dannosi degli agenti.

Per un sistema di posta o un CRM, le conseguenze si traducono in problemi aziendali ben riconoscibili:

• Escono dati riservati. Un output, un allegato, una richiesta in uscita o un messaggio contengono informazioni che il destinatario non dovrebbe ricevere.
• I record vengono modificati senza autorizzazione. L'agente modifica un account, cancella uno storico utile o cambia la fase di una trattativa perché un testo recuperato ne ha deviato il comportamento.
• Una decisione viene distorta senza dare nell'occhio. Un potenziale cliente appare più qualificato, un reclamo scompare dal riepilogo oppure un fornitore riceve una raccomandazione ingiustificata.

L'accesso in sola lettura concede meno possibilità rispetto alla scrittura, ma non impedisce la fuoriuscita di dati riservati. Se l'applicazione recupera record privati e può divulgarli tramite una risposta o una connessione in uscita, la riservatezza va comunque protetta.

In una ricerca pubblicata il 3 marzo 2026, Unit 42 di Palo Alto Networks ha documentato istruzioni malevole inserite in contenuti web online. Individuare un tentativo non dimostra che tutti i sistemi bersaglio lo abbiano seguito. Mostra però perché i contenuti esterni devono rientrare nel modello di minaccia prima che un agente possa agire.

Chi fonda l'azienda deve approvare il danno massimo che un flusso di lavoro può causare. Chi sviluppa deve rendere quel limite applicabile nei punti di accesso ai dati e agli strumenti. Chi gestisce il sistema deve poter sospendere l'esecuzione e indagare quando quei confini vengono messi alla prova.

Come evitare che la prompt injection diventi un incidente

Progetta il sistema mettendo in conto che un attacco possa superare le difese. Quello che segue è un modello di controllo consigliato per un agente di posta o CRM, che applica a un flusso concreto le indicazioni di OWASP su privilegi e approvazioni. Non è un benchmark di prodotto né una garanzia di immunità.

Parti dai permessi effettivi dello strumento. Una funzione chiamata «riassumi la posta in arrivo» non è limitata ai riepiloghi se le credenziali che usa consentono di inviare messaggi e cancellare email. Verifica la configurazione dell'account e del servizio sottostanti, non soltanto il nome della funzione.

Poi controlla i dati che escono dall'applicazione. Una allowlist di rete, cioè un elenco di destinazioni consentite, aiuta a ridurre i canali attraverso cui le informazioni possono essere divulgate. Consentire un servizio di posta, però, non autorizza qualsiasi destinatario; consentire il dominio di un CRM non autorizza qualsiasi account o esportazione. Valida anche la richiesta all'interno del servizio ammesso.

Le indicazioni di Anthropic per una distribuzione sicura descrivono come tenere le credenziali fuori dall'ambiente dell'agente, limitare l'accesso alla rete e validare le richieste tramite un proxy. Un proxy è un intermediario che può applicare regole prima di inoltrare una richiesta. In un'integrazione di posta ospitata su un server, il confine equivalente può essere il servizio che mette a disposizione i tuoi strumenti: custodisce le credenziali e rifiuta le operazioni fuori dall'ambito consentito.

Per una panoramica più ampia dei controlli su input, output ed esecuzione, consulta la guida ai guardrail per l'IA.

Come applicare le indicazioni di Anthropic ai contenuti recuperati

Anthropic consiglia di passare i materiali di terze parti in blocchi tool_result, identificarne la fonte, definire esplicitamente come trattare i contenuti non attendibili e codificare le stringhe in JSON invece di inserirle in istruzioni in testo libero. Le sue indicazioni prevedono anche controlli sugli output degli strumenti e il monitoraggio del comportamento. Vedi le indicazioni aggiornate per Claude.

Nell'esempio commerciale, il corpo dell'email del potenziale cliente deve restare riconoscibile come un messaggio di quel mittente. Non copiarlo in un'istruzione privilegiata solo perché un passaggio precedente del modello lo ha riassunto. Conserva il riferimento alla fonte quando trasferisci le informazioni estratte a un altro passaggio.

JSON è un formato per dati strutturati. Applicare correttamente l'escape al testo impedisce che questo rompa la serializzazione che lo contiene; non impedisce al modello di lasciarsi convincere dal suo significato. La codifica è un livello di difesa, mentre le autorizzazioni devono continuare a essere fatte rispettare altrove.

Vincola l'approvazione all'azione esatta

Un pulsante di approvazione protegge l'azienda solo se l'esecuzione dipende da ciò che la persona ha esaminato. «Continua a elaborare questo account» è un'indicazione troppo vaga per un agente che può inviare allegati o riscrivere i record dei clienti.

Consideriamo una proposta di risposta a un potenziale cliente accompagnata dall'aggiornamento di una trattativa. Chi deve approvarla ha bisogno di vedere il destinatario effettivo, il messaggio, l'elenco degli allegati, il record interessato e i valori dei campi prima e dopo la modifica. L'applicazione deve conservare la proposta approvata ed eseguire quella versione. Se in seguito il modello cambia il destinatario o un allegato, occorre una nuova revisione.

L'approvazione deve inoltre provenire da una persona autenticata con l'autorità necessaria. Un'affermazione contenuta in un'email secondo cui qualcuno ha già approvato il lavoro resta un contenuto della fonte, non un evento di approvazione. Il modello non deve poter creare da solo la propria registrazione di approvazione né accedere a un secondo strumento che aggiri il controllo.

Mantieni l'azione in attesa se il revisore la rifiuta, se l'approvazione scade o se il sistema di revisione non è disponibile. Un timeout non deve trasformarsi silenziosamente in un permesso. Progetta i tentativi successivi in modo che un errore di consegna non provochi invii ripetuti dello stesso messaggio approvato.

Sono raccomandazioni per implementare il flusso di lavoro, non un'affermazione secondo cui la revisione umana intercetta ogni attacco. La guida all'IA con supervisione umana spiega come assegnare il personale alle code di revisione e gestire le escalation.

Una checklist essenziale per un agente di posta o CRM

Metti in produzione per primo il flusso più circoscritto che sia già utile. Usa questa checklist prima di abilitare azioni autonome verso l'esterno:

• Identità: Ogni lettura e modifica è limitata all'utente autenticato e all'account aziendale autorizzato. Il modello non può scegliere un'identità con più privilegi.
• Dati: Recupera solo i record e i campi necessari al compito. Tieni i segreti fuori dai contenuti visibili al modello e conserva l'origine dei testi provenienti da email, documenti e CRM.
• Strumenti: Lettura, preparazione delle bozze, invio, esportazione e modifica devono avere permessi separati. Rimuovi le funzionalità che il flusso non richiede.
• Uscita: Controlla risposte e argomenti degli strumenti prima che vengano trasmessi. Valida destinatari, allegati, destinazioni e modifiche consentite ai record.
• Approvazione: Le azioni ad alto impatto richiedono una revisione dell'azione esatta, resa obbligatoria dal codice applicativo. Se l'approvazione manca o cambia, l'azione resta in attesa.
• Gestione operativa: Conserva un registro delle azioni rispettoso della riservatezza, assegna un responsabile degli avvisi, prevedi un meccanismo di sospensione e prova l'intero flusso prima di ampliare l'accesso.

Per l'assistente commerciale di un fondatore, un punto di partenza ragionevole è leggere una conversazione selezionata con un potenziale cliente e proporre una bozza. Un'esportazione massiva, un invio automatico o un aggiornamento in blocco delle trattative devono essere funzionalità giustificate separatamente. Definisci i permessi in base al lavoro che vuoi offrire, non a tutto ciò che l'integrazione rende possibile.

Il playbook per limitare i danni degli agenti IA in produzione approfondisce l'architettura di contenimento nel suo insieme. Il termine «blast radius», o raggio d'impatto, indica quanto può propagarsi un guasto nei sistemi connessi.

Test di prompt injection: verifica gli effetti, non solo la risposta

Un test è superato quando l'esito vietato non si verifica. Un assistente può mostrare un rifiuto dopo che una chiamata a uno strumento ha già modificato un record. Ispeziona il servizio che esegue gli strumenti e lo stato risultante, non soltanto la trascrizione della chat.

Per una prova generale prima del lancio, usa contatti sintetici, caselle email di test e un ambiente controllato. Quello che segue è un piano di test dell'applicazione, non una raccolta di payload di attacco.

1. 1

   Definisci il funzionamento autorizzato di riferimento

   Esegui un normale compito di riepilogo su un potenziale cliente. Verifica che vengano recuperati i record corretti, che la bozza sia utile e che l'approvazione sia richiesta esattamente dove lo prevedono le regole. Il lavoro legittimo deve continuare a riuscire.

2. 2

   Metti alla prova entrambi i canali di ingresso

   Inserisci una richiesta non autorizzata nel canale di input dell'utente e un messaggio di terze parti che tenti di deviare il compito. Verifica che i record estranei restino inaccessibili e che le operazioni vietate sugli strumenti vengano negate.

3. 3

   Verifica approvazioni e gestione degli errori

   Prova a cambiare i dettagli dell'azione dopo l'approvazione, a rifiutare una revisione, a rendere indisponibile il servizio che applica le regole e a ripetere un tentativo di esecuzione. Verifica che l'applicazione metta in attesa o rifiuti l'azione ed eviti effetti duplicati.

4. 4

   Esamina le evidenze e gli avvisi

   Controlla lo stato finale del CRM, i messaggi in uscita, le destinazioni tentate, la registrazione dell'approvazione e il log delle decisioni dei controlli. Verifica che l'operatore possa identificare la fonte e fermare il flusso senza affidarsi alla spiegazione del modello.

Ripeti i test pertinenti quando cambiano prompt, modelli, recupero dei contenuti, strumenti o permessi. Un risultato vale per la configurazione provata; non certifica ogni versione futura.

Registra quanto basta per ricostruire la decisione, senza trasformare la traccia di audit in un'altra copia dell'intera casella di posta. Preferisci riferimenti stabili ai record, dettagli necessari dell'azione, versioni delle regole ed evidenze con accesso controllato. Assegna a qualcuno la responsabilità di indagare su destinazioni bloccate, esportazioni inattese e problemi ripetuti nelle approvazioni.

Quali promesse sono eccessive e cosa resta irrisolto?

Nessun modello, prompt, filtro o prodotto di guardrail va considerato una soluzione completa. OWASP precisa che la retrieval-augmented generation e il fine-tuning non mitigano completamente la prompt injection. La retrieval-augmented generation, o RAG, fornisce documenti per aiutare il modello a rispondere; non attribuisce a quei documenti l'autorità di cambiare il compito.

Un system prompt più robusto può migliorare il comportamento. Non può restringere i permessi di credenziali che ne concedono troppi. Un classificatore può segnalare contenuti sospetti. Non può decidere se un determinato dipendente abbia il diritto di divulgare uno specifico allegato. Un secondo modello che controlla il primo aggiunge una verifica, ma richiede comunque regole applicative indipendenti.

Non esiste nemmeno una percentuale universale di rilevamento che dica se il tuo agente di posta sia pronto. I limiti utili dipendono dal flusso: quali account può leggere, quali campi può modificare, dove possono andare i dati e quali azioni richiedono una revisione. Un risultato ottenuto da un fornitore su un compito diverso non dimostra che il tuo percorso di approvazione sia impossibile da aggirare.

L'affermazione sostenibile è più circoscritta e più utile: controlli su più livelli riducono l'esposizione e limitano le conseguenze, mentre test e monitoraggio fanno emergere i problemi. Resta un rischio residuo.

Intervieni subito se un agente legge già contenuti esterni e può divulgare informazioni riservate o modificare lo stato dei dati aziendali. Rimanda un'autonomia più ampia finché permessi, approvazioni e gestione degli errori non sono fatti rispettare dal sistema. Uno strumento che riassume documenti pubblici, senza dati privati né strumenti per agire, può causare conseguenze più limitate, ma richiede comunque protezione dalle risposte manipolate.

Domande frequenti

Come proteggersi dagli attacchi di prompt injection?

Limita l'accesso ai dati e agli strumenti, separa i contenuti non attendibili dalle istruzioni, valida output e azioni, richiedi una revisione per le operazioni ad alto impatto e monitora gli esiti. Fai rispettare i permessi al di fuori del modello: nessun singolo livello elimina il rischio.

Qual è un esempio di prompt?

«Riassumi l'email di questo potenziale cliente e prepara una bozza di risposta da sottoporre a revisione» è un normale prompt. L'email del potenziale cliente è materiale da elaborare, non un'autorizzazione a modificare la richiesta.

La SQL injection viene ancora usata?

Sì. La SQL injection resta rilevante per le applicazioni che costruiscono query al database in modo non sicuro. Richiede difese specifiche per i database, oltre agli eventuali controlli contro la prompt injection; consulta le indicazioni di OWASP sulla prevenzione delle injection.

Cosa significa injection in programmazione?

Nella sicurezza informatica, si parla di injection quando un input non attendibile modifica ciò che un interprete esegue o elabora. La prompt injection prende di mira il comportamento di un modello; altre vulnerabilità di tipo injection colpiscono query al database, comandi o codice eseguito nel browser.

Cos'è un'injection, in parole semplici?

È un input che oltrepassa un confine e viene trattato come un'istruzione che non aveva alcuna autorità di impartire.

Quali sono i diversi tipi di code injection?

Tra gli esempi ci sono SQL injection, iniezione di comandi del sistema operativo e iniezione di script. Le difese dipendono dall'interprete coinvolto. La prompt injection condivide il problema del confine di fiducia, ma non è un sinonimo di tutte le forme di code injection.

Quali sono i tipi di prompt injection?

La distinzione principale riguarda il canale di ingresso, diretto o indiretto: l'attacco arriva tramite l'input dell'utente oppure attraverso contenuti recuperati dall'applicazione. Anche il testo nelle immagini e in altri media può veicolare istruzioni; il canale di ingresso e il formato del contenuto sono dimensioni diverse.

Quali sono i 7 principali tipi di hacker?

Le etichette usate per classificare gli hacker non sono una base utile per definire i permessi di un agente. Basa i controlli su chi è autenticato, chi può influenzare i contenuti e a cosa l'applicazione può accedere o apportare modifiche.

Cosa sono DDoS e SQL injection?

DDoS significa negazione distribuita del servizio: un attacco alla disponibilità condotto tramite sorgenti distribuite. La SQL injection manipola le query al database. Sono problemi distinti dalla prompt injection; le indicazioni di OWASP sul denial of service trattano le difese a tutela della disponibilità.

Da dove partire lunedì

Scegli un flusso di posta o CRM già in uso ed elenca i dati, gli strumenti e le destinazioni esterne che può raggiungere. Rimuovi gli accessi superflui, mantieni in attesa le azioni con conseguenze concrete finché non vengono approvate nei loro dettagli esatti e dimostra che una proposta rifiutata non produce effetti esterni. Amplia l'autonomia soltanto quando funzionano sia il compito utile sia i percorsi di rifiuto.

Ricevi guide pratiche per costruire flussi di lavoro con l'IA nella newsletter.