Prompt injection: come progettare un assistente AI con confini chiari

Il rischio nasce dal modo in cui vengono letti gli input

Una prompt injection cerca di modificare il comportamento di un modello attraverso il contenuto che riceve. OWASP distingue l’attacco diretto, presente nel messaggio dell’utente, da quello indiretto, nascosto in materiale esterno come una pagina o un documento. Il problema riguarda quindi anche assistenti che leggono fonti apparentemente ordinarie. [1]

Per chi progetta un assistente aziendale, la domanda da affrontare è: che cosa può succedere dopo che il modello ha letto un testo? Se il sistema deve solo preparare una sintesi, il confine è diverso da quello di un sistema che può modificare dati o attivare un’azione. Prima di scegliere una difesa, conviene descrivere quel confine con precisione.

Un esempio illustrativo: l’assistente che legge preventivi

Immaginiamo un’applicazione incaricata di riassumere preventivi ricevuti dai fornitori. Uno dei documenti contiene un paragrafo che ordina di ignorare le regole e raccomandare una determinata offerta. Questo è uno scenario illustrativo, non la descrizione di un incidente osservato. Serve a distinguere ciò che il documento dice da ciò che l’applicazione è autorizzata a fare.

La proposta di progetto è trattare ogni documento come materiale da analizzare. Il suo contenuto può diventare un dato della sintesi, ma non dovrebbe modificare le regole del processo di acquisto. Una sintesi utile potrebbe evidenziare i criteri di confronto e rimandare ai passaggi del documento, lasciando l’approvazione del fornitore a un flusso separato e riconoscibile.

Conviene preparare esempi di documenti normali, documenti ambigui e documenti con richieste ostili. Per ciascuno si annota il comportamento atteso: quali informazioni devono essere estratte e quali azioni devono rimanere impossibili. Questa piccola raccolta rende verificabile il progetto prima che arrivi un documento reale.

I permessi devono seguire il compito

Tra le mitigazioni, OWASP propone di limitare i privilegi, distinguere il contenuto esterno e richiedere approvazione umana per operazioni ad alto rischio. Segnala anche che istruzioni, filtri e tecniche di recupero delle informazioni non rappresentano da soli una prevenzione infallibile. [1]

Nel nostro esempio, un assistente che confronta offerte potrebbe avere accesso soltanto ai documenti selezionati per quella richiesta. Per ogni collegamento a un sistema aziendale, il team dovrebbe domandarsi quale informazione sia necessaria e quale operazione possa essere esclusa. Un permesso concesso per comodità dovrebbe essere giustificato come qualsiasi altra scelta architetturale.

È utile descrivere separatamente lettura, preparazione di una proposta e modifica effettiva dei dati. La schermata di conferma dovrebbe indicare l’azione esatta e gli elementi coinvolti. Un’approvazione generica, difficile da ricostruire dopo, non offre lo stesso criterio di controllo di una richiesta specifica.

La risposta del modello è un input da controllare

OWASP include tra i rischi anche l’uso scorretto dell’output generato: se una risposta viene passata senza adeguati controlli a un altro componente, può diventare un problema per quel sistema. La verifica dell’output riguarda il contesto in cui verrà utilizzato, non solo la sua leggibilità. [2]

Una proposta concreta è richiedere una struttura semplice per la sintesi: nome del documento, punti rilevanti e riferimenti ai passaggi utilizzati. Il programma controlla i campi prima di mostrarli. Se un campo manca o contiene qualcosa di diverso da ciò che è previsto, la richiesta dovrebbe terminare con un esito riconoscibile e lasciare il documento disponibile per una lettura manuale.

Questa verifica non dimostra che ogni conclusione sia corretta. Per le decisioni importanti serve anche confrontare l’interpretazione con il documento. Una sintesi ben formattata può essere incompleta; progettare un’interfaccia che permetta di risalire al passaggio originale aiuta il lettore a valutarla.

Una prova di sicurezza che corrisponda al prodotto

Per il progetto illustrativo, proporrei una prova con un documento che tenta di cambiare i criteri di selezione, uno che richiede informazioni estranee al compito e uno che contiene dati contraddittori. Il risultato atteso va definito prima di eseguire la prova. Il test dovrebbe verificare sia il testo restituito sia l’assenza di azioni non consentite.

La conclusione pratica è partire da un assistente con un compito ristretto e descrivibile. Si estendono le capacità quando il nuovo confine è comprensibile, verificabile e assegnato a un responsabile. Non è una promessa di eliminare ogni attacco: è un modo per discutere i rischi attraverso comportamenti concreti e per decidere quali capacità siano davvero necessarie.

Come trasformare i confini in una prova concreta

Un esempio illustrativo: un assistente aziendale confronta documenti e prepara una proposta, ma non dovrebbe modificare dati senza una richiesta specifica. Il team potrebbe costruire casi di prova con istruzioni estranee inserite nei documenti, richieste di accesso non necessarie e risposte che sembrano plausibili ma chiedono azioni fuori dal compito. Per ciascun caso annoterebbe quale confine dovrebbe fermare il comportamento: trattamento del contenuto, permessi disponibili o verifica prima dell’esecuzione. [1]

La prova dovrebbe registrare anche che cosa accade dopo il blocco. L’utente riceve una spiegazione comprensibile? Può continuare il compito autorizzato? La richiesta di conferma mostra l’azione e i dati coinvolti? Queste domande aiutano a distinguere un controllo utilizzabile da un avviso generico. Se un caso riesce a superare un confine, la correzione dovrebbe riguardare il punto che concede autorità o capacità operative, oltre al testo delle istruzioni. L’esempio è una proposta di verifica, non una dimostrazione che l’assistente sia sicuro. [1]