Cos’è il prompt injection?

Due forme: diretta e indiretta

L’injection diretta è qualcuno che digita istruzioni direttamente nella chat cercando di scavalcare il comportamento previsto del sistema — chiedendo al modello di ignorare le sue istruzioni, rivelare configurazioni nascoste, o agire fuori dal suo ambito previsto. L’injection indiretta è la forma con conseguenze maggiori: istruzioni piazzate in contenuti che il modello legge per tuo conto — una pagina web, un’email, un file, la risposta di un’API — che non erano mai destinate a essere trattate come comandi dal modello ma che il modello non ha modo affidabile di distinguere da essi.

Perché un modello più intelligente non risolve questo da solo

Il problema non è che i modelli non sono abbastanza intelligenti — è architetturale. Tutto ciò che un modello vede, che sia la tua richiesta o testo recuperato da una fonte non affidabile, diventa lo stesso tipo di sequenza di token una volta entrato nella finestra di contesto. Non esiste un canale separato e inviolabile per le "istruzioni fidate" contro il "contenuto da leggere". Un modello più capace può diventare migliore nel riconoscere formulazioni di injection comuni, ma un’istruzione sufficientemente camuffata — divisa nel testo, formulata indirettamente, nascosta nella formattazione — può comunque passare, perché l’architettura sottostante non ha un confine rigido da far rispettare.

Il rischio cresce nettamente non appena un modello può chiamare strumenti

Un chatbot che produce solo testo limita l’injection a un output scadente o fuorviante — fastidioso, ma contenuto. Non appena un modello può chiamare strumenti (vedi come funziona la chiamata di strumenti) — inviare un’email, eseguire un comando, modificare un file — un’injection riuscita può trasformarsi in un’azione reale indesiderata, non solo una frase sbagliata. Ecco perché i sistemi che combinano navigazione web o lettura di documenti con l’accesso a strumenti comportano un rischio di injection significativamente maggiore rispetto a un semplice chatbot.

Filtrare e limitare l’ambito riducono il rischio; nessuno dei due lo elimina

Scansionare il contenuto recuperato alla ricerca di pattern di injection noti cattura alcuni tentativi, ma qualsiasi lista fissa di pattern può essere elusa formulando l’istruzione in modo diverso — questo è un filtro, non una garanzia. Ciò che riduce il danno reale in modo più affidabile è limitare cosa a un modello è permesso fare indipendentemente da ciò che gli è stato detto: restringere strettamente l’accesso agli strumenti, richiedere un’approvazione prima di un’azione distruttiva o rivolta verso l’esterno, e non concedere mai a un modello permessi permanenti più ampi del compito specifico che ha davanti.

Il contenuto che un modello legge è un input non affidabile, non una fonte neutrale di fatti

Qualsiasi sistema che permette a un modello di leggere contenuto esterno — un risultato di ricerca, una pagina raccolta, un documento caricato da un utente — lo espone a istruzioni che nessuno ha richiesto. L’implicazione pratica è trattare quel contenuto come tratteresti un input utente non validato in qualsiasi altro software: presumere che possa contenere qualcosa di ostile, e progettare il sistema circostante in modo che un’injection riuscita abbia una portata limitata, invece di presumere che l’injection non accadrà.

Domande frequenti

Il prompt injection si può prevenire del tutto?

No, non con le architetture di modello attuali. Non esiste una separazione integrata e inviolabile tra le istruzioni di un utente e il testo che un modello legge altrove, quindi filtrare e limitare l’ambito riducono il rischio e contengono il danno, ma non possono garantire la prevenzione.

Il prompt injection è la stessa cosa del jailbreaking?

Si sovrappongono ma non sono identici. Il jailbreaking di solito significa un utente che cerca direttamente di far sì che un modello aggiri le proprie linee guida. Il prompt injection si riferisce più spesso a istruzioni nascoste in contenuto che il modello legge per conto dell’utente, a sua insaputa.

Il prompt injection conta per un chatbot che non può usare strumenti?

Il rischio è minore — un’injection riuscita può produrre una risposta fuorviante o manipolata, ma non può compiere un’azione oltre generare testo. Il rischio cresce sostanzialmente non appena un modello può chiamare strumenti che fanno qualcosa al di fuori della conversazione.

Scansionare il contenuto alla ricerca di pattern di injection è protezione sufficiente?

Cattura tentativi noti e riconoscibili, ma qualsiasi lista fissa di pattern può essere elusa riformulando. Una protezione reale viene anche dal limitare cosa a un modello è permesso fare — ambito ristretto degli strumenti e approvazione richiesta per azioni con conseguenze — non solo dalla rilevazione.