Prompt Injection nei chatbot per siti web: protezione per RAG, tool e dati

Un chatbot per siti web non elabora soltanto domande innocue. I visitatori possono tentare di riscrivere le sue regole, rivelare istruzioni interne o attivare azioni non autorizzate. Ancora più difficili da individuare sono i comandi non inclusi direttamente nella chat, bensì nascosti all'interno di una pagina web sottoposta a crawling, un documento caricato o un sistema di terze parti collegato.

Chi desidera limitare la prompt injection nei chatbot per siti web non può affidarsi unicamente a un prompt di sistema particolarmente severo. È necessaria un'architettura a più livelli: input e fonti vengono trattati come non affidabili, i permessi vengono limitati a livello tecnico, gli output vengono verificati prima dell'elaborazione e le azioni a rischio vengono confermate da codice deterministico o da un operatore umano.

Cosa significa prompt injection per un chatbot per siti web

OWASP descrive la prompt injection come un input che modifica in modo non intenzionale il comportamento o l'output di un modello linguistico. Una prompt injection diretta proviene direttamente dall'utente, ad esempio sotto forma di richiesta di ignorare le regole precedenti. Una prompt injection indiretta si nasconde invece in contenuti esterni recuperati successivamente dal sistema: pagine web, documenti di conoscenza, e-mail, dati sui prodotti o file.

Questa distinzione è fondamentale per i gestori di siti web. Un semplice chatbot per FAQ ha una superficie di attacco ridotta rispetto a un sistema che esegue continuamente il crawling di pagine web, cerca nei documenti interni, legge dati CRM o può eseguire funzioni. La Retrieval-Augmented Generation (RAG) migliora il fondamento informativo delle risposte, ma non elimina il rischio di injection. Anche una raccolta di fonti ben curata può contenere istruzioni manipolate o fraintese.

Valutare il rischio in base alle funzionalità anziché al nome del modello

La domanda decisiva non è solo: "Quale modello stiamo usando?", bensì: "Quale impatto può avere una risposta manipolata?". Create una semplice mappa delle funzionalità e dei dati per il chatbot:

• Quali fonti pubbliche e interne può leggere?
• Quali dati personali, confidenziali o critici per il business sono accessibili?
• Può solo generare testo o anche creare ticket, lead, e-mail, appuntamenti o ordini?
• Quali azioni modificano i sistemi esterni?
• Quali decisioni vengono adottate automaticamente senza una verifica humana?

Più aumentano i diritti di lettura, di scrittura e il grado di automazione, più diventano importanti i confini tecnici esterni al modello. La panoramica esistente sugli errori comuni nei chatbot IA aiuta nel censimento generale. Per la prompt injection occorre inoltre documentare i flussi di dati, i confini di fiducia e i permessi d'azione.

Separare chiaramente quattro zone di fiducia

Un modello di sicurezza pratico distingue quattro zone, anche se elaborate tecnicamente nella stessa applicazione.

Zona 1: Regole di sistema e linee guida

Qui si definiscono ruolo, scopo consentito, limiti delle risposte e regole di escalation. Queste regole orientano il modello, ma non costituiscono un controllo degli accessi affidabile. OWASP mette espressamente in guardia dal trattare i prompt di sistema come un segreto o un meccanismo di sicurezza. Credenziali, chiavi di connessione e informazioni interne sensibili non devono farne parte.

Zona 2: Input dei visitatori

Ogni messaggio di chat va considerato non affidabile. Limitate la lunghezza, i tipi di file e le funzionalità consentite; normalizzate gli input per l'elaborazione tecnica e contrassegnateli chiaramente nel prompt come dati utente. Un filtro può rilevare pattern di attacco noti, ma non deve bloccare indiscriminatamente le domande legittime. Un visitatore che cerca "ignore previous instructions" nella documentazione sulla sicurezza potrebbe avere una richiesta del tutto legittima.

Zona 3: Fonti recuperate e contesto RAG

Anche i contenuti sottoposti a crawling, i PDF e i risultati di servizi esterni rimangono dati, non istruzioni. Separate visibilmente il loro contenuto dal contesto di controllo, salvate la provenienza e la data di recupero, e consentite solo fonti autorizzate. L'articolo sul mantenimento aggiornato della knowledge base del chatbot IA mostra come interagiscono inventario delle fonti, frequenza di crawling e QA.

Zona 4: Tool, azioni e output

Le chiamate di funzione non devono essere eseguite per il solo fatto che il modello genera il testo corrispondente. Un controller deterministico verifica il nome della funzione, i parametri, i permessi, il contesto di sessione e i sistemi di destinazione consentiti. Gli output del modello che verranno successivamente utilizzati come HTML, Markdown, SQL, percorsi di file o parametri API necessitano di validazione e codifica adeguate a quel contesto specifico.

Il principio del minimo privilegio limita l'impatto

Allo stato attuale, la prompt injection non può essere esclusa in modo affidabile con una singola misura. Pertanto, l'applicazione deve essere progettata affinché un tentativo di manipolazione riuscito produca il minor impatto possibile. OWASP e Microsoft raccomandano a questo scopo il principio del minimo privilegio (Least Privilege).

• Utilizzate identità tecniche separate per la lettura e la scrittura.
• Concedete l'accesso solo ai dati strettamente necessari per lo scopo specifico del chatbot.
• Limitate le funzionalità a schemi di parametri ridotti e chiaramente definiti.
• Utilizzate permessi a breve termine quando un'azione li richiede.
• Richiedete una conferma esplicita per le operazioni a rischio o irreversibili.
• Non affidate mai l'autorizzazione al testo libero del modello.

Un chatbot di supporto può, ad esempio, preparare una bozza di ticket, ma non dovrebbe determinare automaticamente destinatari, priorità o diritti d'accesso interni arbitrari. Un chatbot per la generazione di lead può raccogliere dati di contatto strutturati senza ottenere con ciò diritti di lettura sull'intero CRM.

Verificare e isolare le fonti RAG

La prompt injection indiretta rende la pipeline delle fonti parte integrante dell'architettura di sicurezza. Una pagina manipolata può apparire visivamente innocua e contenere comunque testo che un modello interpreta come istruzione. Nei sistemi multimodali, anche le immagini o altri formati di file possono svolgere un ruolo.

Inserite quindi una procedura di acquisizione delle fonti con regole di approvazione: domini e sezioni di documenti consentiti, proprietari tracciabili, versionamento, scansione malware e file, oltre a una revisione dei contenuti nuovi o modificati in modo insolito. Contrassegnate chiaramente i passaggi recuperati nel contesto del modello come contenuto non affidabile (untrusted content). Un risultato della ricerca può fornire informazioni, ma non modificare le regole di sistema né i permessi dei tool.

Verificate inoltre se la risposta è effettivamente supportata dalle fonti. La guida sulla misurazione della qualità delle risposte dei chatbot IA con Golden Set e test RAG descrive la groundedness e la verifica delle fonti. Questa verifica della qualità integra i controlli di sicurezza, ma non li sostituisce.

I filtri di input e output sono un livello, non l'intera soluzione

Servizi di protezione specializzati possono rilevare tentativi di attacco diretti e indiretti. Microsoft Prompt Shields, ad esempio, distingue gli attacchi negli input dell'utente dalle istruzioni nascoste nei documenti. Nelle sue linee guida sulla sicurezza, anche Google raccomanda misure di protezione contro la prompt injection, compiti delimitati più rigorosamente, identificativi utente, limiti di quantità e supervisione umana in presenza di rischi più elevati.

Tali filtri forniscono segnali probabilistici. Pianificate quindi un comportamento graduato: bloccare, rispondere in modo sicuro, passare a una modalità ristretta o trasferire la conversazione a un operatore umano. Registrate la classe di decisione e la versione tecnica, ma evitate la memorizzazione non necessaria del testo integrale. In caso di dati personali, si applicano inoltre gli ambiti di verifica descritti nell'articolo su chatbot IA e GDPR. Questo articolo non costituisce una consulenza legale.

Validare gli output del modello prima dell'ulteriore elaborazione

Un input sicuro non garantisce un output sicuro. OWASP classifica la gestione insufficiente degli output come un rischio a sé stante: il testo del modello può finire in codice HTML, script, query di database o percorsi di file. Trattate quindi anche ogni output del modello iniziale come non affidabile.

Per i processi automatizzati, richiedete un formato strutturato rigoroso e validatelo rispetto a uno schema. Utilizzate whitelist per i nomi delle funzioni e i sistemi di destinazione. Codificate il testo visibile per il rispettivo contesto di output. Scartate i campi inattesi, gli URL esterni e i parametri al di fuori dei valori consentiti. I dati sensibili dovrebbero passare attraverso un'ulteriore verifica delle policy prima di essere visualizzati o trasmessi.

Testare la prompt injection con un set di test di sicurezza

Integrate il Golden Set tecnico con casi di test avversari (adversarial). I test devono verificare il sistema effettivo in produzione, inclusi retrieval, tool e logica dei permessi, non soltanto il modello di base. Un set utile include:

• tentativi diretti di sostituire le regole o di richiedere le istruzioni interne;
• varianti multilingue, codificate e distribuite su più messaggi;
• domande specialistiche innocue contenenti parole chiave simili che non devono essere bloccate erroneamente;
• passaggi manipolati in una fonte di conoscenza di test;
• nomi di funzione non autorizzati, parametri aggiuntivi e indirizzi di destinazione estranei;
• tentativi di restituire dati confidenziali o contenuti di sessioni precedenti;
• test per output in HTML, Markdown e link;
• percorsi di interruzione, handoff e conferma per le azioni a rischio.

Non misurate soltanto se un filtro si attiva. Verificate il risultato finale: un'azione non autorizzata è stata impedita? I dati confidenziali sono rimasti protetti? Una richiesta legittima ha continuato a funzionare? Un caso anomalo è stato registrato nei log in modo tracciabile?

Piano pratico di implementazione per i team web

1. Definire l'ambito: documentare fonti dati, tool, permessi di scrittura e destinazioni esterne.
2. Separare le zone di fiducia: contrassegnare tecnicamente regole di sistema, input dell'utente, contenuti RAG e output di azione.
3. Ridurre i permessi: rimuovere gli accessi non utilizzati e scomporre le azioni di scrittura in piccole funzioni.
4. Aggiungere la validazione: introdurre limiti di input, output strutturati, whitelist e codifica specifica per contesto.
5. Stabilire la conferma: mettere in sicurezza le azioni a rischio e i flussi di dati sensibili con la supervisione umana (Human-in-the-loop).
6. Eseguire il set di test: verificare i casi di controllo diretti, indiretti e legittimi prima di ogni release rilevante.
7. Monitorare l'operatività: revisionare regolarmente eventi dei filtri, azioni negate, modifiche insolite alle fonti e falsi allarmi.

Checklist: protezione dalla prompt injection

• Il prompt di sistema non contiene segreti e non sostituisce l'autorizzazione.
• I testi degli utenti e le fonti esterne sono considerati non affidabili per impostazione predefinita.
• Le fonti RAG dispongono di approvazione, provenienza, versione e proprietari responsabili.
• I tool seguono il principio del minimo privilegio e accettano solo parametri validati.
• Le azioni a rischio richiedono una conferma tracciabile.
• Gli output del modello vengono verificati prima dell'invio a HTML, API, CRM o altri sistemi di destinazione.
• I filtri di sicurezza vengono valutati in base ai falsi positivi e falsi negativi.
• I test sugli attacchi diretti e indiretti vengono eseguiti regolarmente e dopo ogni modifica.

Conclusione

La prompt injection non è un mero problema di prompt engineering. Per i chatbot per siti web, una protezione solida nasce solo quando l'applicazione tratta input, fonti, output e azioni come zone di fiducia separate. I filtri possono rilevare gli attacchi, ma il principio del minimo privilegio, la validazione deterministica e la conferma humana limitano il loro potenziale impatto.

Iniziate con la mappa delle funzionalità e dei dati del vostro chatbot. Rimuovete i permessi non necessari, isolate i contenuti RAG e testate l'intero percorso fino all'azione esterna. In questo modo il chatbot rimarrà utile senza che il testo libero del modello decida sui permessi o su modifiche critiche per il business.

Fonti

• OWASP GenAI Security Project: LLM01:2025 Prompt Injection
• OWASP GenAI Security Project: LLM07:2025 System Prompt Leakage
• OWASP GenAI Security Project: LLM05:2025 Improper Output Handling
• NIST: Generative Artificial Intelligence Profile (NIST AI 600-1)
• Microsoft Learn: Defend against indirect prompt injection attacks
• Microsoft Learn: Prompt Shields in Azure AI Content Safety
• Google AI for Developers: Safety and factuality guidance