Vai al contenuto

Dominio e progetto sono disponibili per l’acquisizione. Vedi la scheda

sicurezzainformatica.ai

Guide · AI e sicurezza

Prompt injection: cos’è e come difendere chatbot e assistenti AI

È l’attacco che trasforma un testo qualunque, un’email, una pagina web, un PDF, in un ordine per l’intelligenza artificiale. Nessun filtro lo elimina del tutto: quello che si può fare è limitare il danno.

Pubblicata il . Lettura: 6 minuti. Come verifichiamo le fonti.

Indice della guida
  1. Che cos’è la prompt injection
  2. Diretta e indiretta: la differenza che conta
  3. Un caso reale: EchoLeak
  4. Perché non basta un filtro
  5. Il danno dipende dai permessi
  6. Cinque difese che lavorano insieme
  7. Sei domande da fare prima di attivare un assistente AI
  8. Domande frequenti
  9. Fonti

Che cos’è la prompt injection

Un assistente AI lavora leggendo testo. Una parte di quel testo sono le istruzioni di chi lo ha configurato, per esempio «rispondi ai clienti e non rivelare i prezzi riservati». Un’altra parte è il materiale su cui lavora: la domanda dell’utente, un’email, un documento, una pagina web. Per il modello, però, è tutto testo nello stesso flusso. Se nel materiale compare una frase che somiglia a un ordine, il modello può eseguirla come se arrivasse da chi lo gestisce.

La prompt injection è questo: un testo costruito per far cambiare comportamento a un’applicazione basata su un modello linguistico, in un modo che chi l’ha sviluppata non voleva. OWASP, il progetto di riferimento per la sicurezza applicativa, precisa che il contenuto malevolo non deve nemmeno essere visibile a una persona: basta che il modello lo legga.

Chi conosce la sicurezza web riconosce lo schema della SQL injection, in cui dei dati vengono interpretati come comandi. Con una differenza scomoda: nei database esiste un modo pulito per tenere separati i due piani, nei modelli linguistici ancora no.

Diretta e indiretta: la differenza che conta

Nella forma diretta è l’utente stesso a scrivere il testo che devia il modello: per esempio chiede a un chatbot di assistenza di ignorare le regole ricevute e di mostrare informazioni riservate. Il jailbreak è un caso particolare, in cui l’obiettivo è far saltare al modello le sue regole di sicurezza.

Nella forma indiretta l’istruzione è nascosta in un contenuto che l’assistente legge per conto dell’utente: una pagina web da riassumere, un allegato, un’email in arrivo, un invito in calendario. La vittima non scrive nulla di sbagliato. Chiede un riassunto, e nel testo da riassumere c’è una riga, magari in caratteri bianchi su fondo bianco, che dice all’assistente di fare altro.

Per un’azienda il rischio serio è il secondo. Chiunque possa far arrivare un testo all’assistente, cioè chiunque possa mandarvi un’email, diventa un potenziale attaccante.

Un caso reale: EchoLeak

A giugno 2025 i ricercatori di Aim Labs hanno reso pubblica EchoLeak, una vulnerabilità di Microsoft 365 Copilot registrata come CVE-2025-32711 e classificata critica, con punteggio CVSS 9,3. Bastava un’email preparata ad arte: quando l’assistente la elaborava insieme al resto della posta, le istruzioni nascoste lo portavano a far uscire dati interni, senza che la persona colpita dovesse aprire o cliccare nulla.

Microsoft ha corretto il problema sui propri server prima della divulgazione e ha comunicato che ai clienti non era richiesta alcuna azione. Il caso resta un riferimento perché mostra il meccanismo in un prodotto di uso comune: un contenuto esterno, un assistente con accesso ai dati aziendali, un canale per far uscire le informazioni.

Perché non basta un filtro

La tentazione è compilare un elenco di frasi vietate. Non funziona: lo stesso ordine si può riformulare in mille modi, scrivere in un’altra lingua, spezzare in più parti, nascondere in un’immagine. OWASP lo scrive apertamente: data la natura probabilistica dei modelli, non è chiaro se esista un metodo di prevenzione a prova di errore, e tecniche come il RAG o il fine-tuning non risolvono il problema.

La conseguenza pratica: conviene dare per scontato che prima o poi il modello verrà ingannato, e progettare il sistema perché in quel momento possa fare pochi danni.

Il danno dipende dai permessi

Un chatbot che risponde a domande sul catalogo, se manipolato, può dire una sciocchezza. Un assistente che legge la posta, consulta il gestionale, naviga sul web e invia messaggi può fare molto di più: inoltrare documenti, modificare dati, eseguire operazioni a nome di qualcuno. Più strumenti e accessi si collegano al modello, più una prompt injection riuscita somiglia a un account compromesso.

Nell’edizione 2026 della classifica OWASP l’eccesso di autonomia concessa agli assistenti, in inglese excessive agency, è salito al terzo posto: il problema si sta spostando dalle risposte alle azioni.

Una regola utile prima di attivare qualunque assistente: immaginate che esegua alla lettera il peggior testo che potrà mai leggere. Quello che succederebbe in quel caso è il vostro rischio reale.

Cinque difese che lavorano insieme

Nessuna di queste misure basta da sola. Insieme riducono la probabilità di un attacco riuscito e soprattutto le sue conseguenze. Sono, riorganizzate per chi gestisce un’azienda, le misure che OWASP indica per questo rischio.

Permessi minimi

L’assistente accede solo ai dati che gli servono, in sola lettura dove basta, con credenziali separate per ogni funzione. È la misura che conta di più, perché decide quanto può costare un errore.

Una persona conferma le azioni che contano

Pagamenti, invii all’esterno, cancellazioni, modifiche a dati sensibili: l’assistente prepara, una persona approva.

I contenuti esterni restano non fidati

Email, pagine web e allegati vanno tenuti separati dalle istruzioni e presentati al modello come materiale da analizzare. Il rischio non sparisce, ma si riduce.

Controlli su ciò che entra e su ciò che esce

In ingresso, filtri per i tentativi più evidenti. In uscita, controlli che blocchino dati sensibili, link e immagini verso domini sconosciuti, che sono il canale tipico per far uscire informazioni. Il formato delle risposte va definito e verificato dal codice dell’applicazione.

Prove periodiche

Fate attaccare l’assistente da qualcuno di fiducia prima che lo faccia un estraneo, e ripetete la prova a ogni nuova integrazione. Tenete un registro delle azioni compiute dall’assistente: senza registro non c’è modo di ricostruire un incidente.

Sei domande da fare prima di attivare un assistente AI

  • A quali dati può accedere, e servono tutti?
  • Quali azioni può compiere senza che una persona confermi?
  • Legge contenuti che arrivano dall’esterno, come email, pagine web o allegati?
  • Può far uscire dati dall’azienda, anche solo caricando un link o un’immagine?
  • Esiste un registro di ciò che fa, e qualcuno lo guarda?
  • Il fornitore ha documentato come gestisce la prompt injection e come si segnala un problema?

Se a più di due domande la risposta è «non lo so», l’assistente non è pronto per i dati aziendali.

Domande frequenti

Un antivirus o un firewall proteggono dalla prompt injection?

No. L’attacco viaggia come testo normale dentro canali legittimi: un’email, un documento, una pagina web. Antivirus e firewall restano necessari, ma guardano altro.

Riguarda anche chi usa l’AI solo per scrivere testi?

Il rischio cresce quando l’assistente è collegato a posta, documenti, web o altri strumenti. Un uso senza collegamenti espone soprattutto a un altro problema: i dati aziendali che le persone incollano nelle conversazioni.

Esiste un prodotto che la risolve?

Esistono strumenti che riducono il rischio, e conviene usarli. Nessuno può garantire di bloccarla sempre, per le ragioni spiegate sopra: meglio diffidare di chi lo promette.

Fonti

Continua con queste guide

Phishing oggi: furto di sessione, MFA che non basta e passkey

I vecchi consigli, controllare gli errori e non cliccare, non bastano più. Questa guida spiega come si ruba una sessione anche con l’autenticazione a più fattori attiva, quali metodi resistono davvero e che cosa fare nei primi minuti dopo un clic sbagliato.

Truffe e inganni · 11 minuti di lettura