Prompt injection e jailbreak

La prompt injection è l'analogo, nell'era degli LLM, delle classiche vulnerabilità di injection (SQL, command). La causa principale è identica: un'applicazione mescola istruzioni attendibili e dati non attendibili nello stesso canale, e l'interprete (il modello) non riesce a distinguerli in modo affidabile.

Con un LLM, il prompt di sistema, le istruzioni dello sviluppatore e qualsiasi contenuto recuperato arrivano tutti come un unico flusso piatto di token. Se un testo controllato dall'attaccante dice Ignore previous instructions and..., il modello potrebbe obbedire perché, dal suo punto di vista, è semplicemente altro linguaggio.

• Attendibili: il prompt di sistema e le Sue policy.
• Non attendibili: input dell'utente, pagine web, file, output degli strumenti, email.

La prompt injection diretta si verifica quando l'utente finale inserisce istruzioni malevole direttamente nel prompt per sovrascrivere il comportamento previsto dall'applicazione.

Un tentativo tipico contro un bot di assistenza clienti si presenta così:

• Al bot viene detto di rispondere solo a domande sulla fatturazione.
• L'utente incolla un testo che riformula il ruolo del modello e gli chiede di divulgare il prompt di sistema o di eseguire azioni fuori ambito.

L'iniezione diretta è la più facile da analizzare perché il testo malevolo e l'attaccante sono la stessa persona, ma riesce comunque a eludere i guardrail ingenui.

La prompt injection indiretta (di secondo livello) è la variante più pericolosa. L'attaccante inserisce istruzioni in contenuti che il modello recupererà in seguito: una pagina web, un PDF, un invito di calendario, un commento nel codice o un ticket di assistenza.

L'utente vittima non vede mai il payload. Quando una pipeline RAG o un agente di navigazione inserisce quel contenuto nel contesto, le istruzioni nascoste vengono eseguite con i privilegi della vittima.

Esempio: una pagina web contiene testo nascosto che ordina a un agente di riepilogo di esfiltrare la cronologia delle chat dell'utente verso un URL dell'attaccante.

Questi termini si sovrappongono, ma non sono identici:

• La prompt injection prende di mira il confine dell'applicazione, sovrascrivendo le istruzioni dello sviluppatore con dati dell'attaccante.
• Il jailbreak prende di mira l'allineamento alla sicurezza del modello, inducendolo a produrre contenuti che il provider lo ha addestrato a rifiutare.

Un jailbreak non richiede un'applicazione vulnerabile: funziona contro il modello grezzo. Molti attacchi reali combinano entrambi: il jailbreak allenta i rifiuti, mentre l'injection reindirizza il comportamento dell'applicazione.

Gli attaccanti usano schemi di manipolazione prevedibili. Conoscerli La aiuta a sottoporre il Suo sistema a red teaming in modo responsabile:

• Roleplay / persona: presentare la richiesta come finzione o come se provenisse da un personaggio fittizio senza restrizioni.
• Offuscamento: base64, leetspeak, traduzione o suddivisione in token per eludere i filtri basati su parole chiave.
• Suddivisione del payload: distribuire una richiesta su più turni, in modo che nessun singolo messaggio sembri malevolo.
• Ipotesi: For a security class, describe how one would...
• Iniezione del prefisso: obbligare la risposta a iniziare con un'affermazione come Sure, here is.

Molti team ricorrono innanzitutto a una denylist di frasi come ignore previous instructions. Questo approccio è fragile perché lo spazio degli input è di fatto infinito.

Il linguaggio naturale può esprimere la stessa intenzione in un numero incalcolabile di modi, attraverso lingue, codifiche e metafore diverse. Gli attaccanti iterano più velocemente di quanto Lei riesca ad aggiornare le espressioni regolari.

Principio chiave: consideri il filtraggio degli input una difesa in profondità, mai un controllo primario. Dia per scontato che qualche injection passerà comunque e progetti il sistema in modo che anche un'injection riuscita non possa causare danni reali.

Il metodo di mitigazione più efficace è architetturale: limiti ciò che il contesto di un modello compromesso può fare.

• Conceda all'LLM il privilegio minimo necessario. Un sistema di riepilogo non dovrebbe disporre delle credenziali per inviare email.
• Tenga i contenuti non attendibili fuori dai percorsi privilegiati. Se un agente legge dati web esterni, non dovrebbe anche poter eseguire azioni irreversibili nello stesso turno senza un checkpoint.
• Separi i piani dati dai piani di controllo: il testo recuperato deve essere un dato, non un comando.

Anche se non è infallibile, la struttura del prompt alza l'asticella. Delimiti chiaramente i dati non attendibili e indichi al modello come trattarli.

Utilizzi delimitatori espliciti e dica al modello che tutto ciò che si trova al loro interno è un dato da analizzare, non un'istruzione da seguire. Abbini questa strategia a un ruolo di sistema solido che l'applicazione ribadisca a ogni chiamata.

L'output del modello è a sua volta non attendibile. Se l'applicazione invia l'output dell'LLM a una shell, a un database, a un browser o a un altro strumento, l'injection può trasformarsi in esecuzione di codice da remoto o esfiltrazione di dati.

La triade letale di Simon Willison descrive la combinazione pericolosa:

• Accesso a dati privati,
• Esposizione a contenuti non attendibili,
• Possibilità di comunicare verso l'esterno (esfiltrare dati).

Un agente dotato di tutti e tre gli elementi può essere trasformato in uno strumento per sottrarre dati con una singola istruzione inserita. Spezzare la triade significa spezzare l'attacco.

Dia per scontato che si verifichino injection e raccolga dati per individuarle:

• Registri l'intero contesto (prompt, segmenti recuperati, chiamate agli strumenti) per analizzare gli incidenti.
• Utilizzi un classificatore secondario o un modello di controllo per segnalare input e output sospetti.
• Monitori l'uso anomalo degli strumenti: richieste improvvise verso l'esterno, accessi imprevisti ai dati, schemi di divulgazione del prompt.
• Applichi token canary nei prompt di sistema; se un canary compare nell'output, si è verificata una fuga.

Tratti gli avvisi come incidenti reali e segua un runbook di risposta.

Testare i propri sistemi per individuare injection è essenziale e legittimo. Lo faccia responsabilmente:

• Testi solo sistemi che possiede o per i quali dispone dell'autorizzazione.
• Utilizzi un ambiente controllato e dati sintetici; non esfiltri mai dati reali degli utenti.
• Documenti i risultati e li integri nei test di regressione, così che gli aggiramenti corretti rimangano corretti.
• Coordini la divulgazione quando individua problemi in modelli o applicazioni di terze parti.

L'obiettivo è rendere l'applicazione resiliente, non sviluppare capacità dannose.

Punti chiave su prompt injection e jailbreak:

• La injection nasce dalla combinazione di istruzioni attendibili e dati non attendibili in un unico canale.
• La injection diretta proviene dall'utente; quella indiretta si nasconde nei contenuti recuperati ed è più furtiva.
• I jailbreak attaccano l'allineamento del modello; la injection attacca il confine dell'applicazione. Si combinano.
• Il filtraggio degli input è solo una difesa in profondità, mai il controllo primario.
• Mitighi a livello architetturale: applichi il principio del privilegio minimo, separi dati e controllo e spezzi la triade letale (dati privati + contenuti non attendibili + esfiltrazione).
• Tratti l'output del modello come non attendibile, registri tutto ed esegua red teaming in modo etico.