Prompt injection non è una vecchia storia 🧩

TL;DR: chiamare la prompt injection “la nuova SQL injection” è utile per ricordarsi che esiste un rischio. È dannoso se ti fa applicare la difesa sbagliata.

Dove l analogia si rompe 🔧

Con SQL puoi separare struttura e valore: query parametrizzate, parser, tipi. Un prompt è testo che un modello interpreta insieme a istruzioni, dati recuperati da un documento e input dell’utente. Un’istruzione ostile può arrivare in una pagina Web, in un PDF o nel record che il tuo RAG considera autorevole. Non è “l’utente malintenzionato nel campo da compilare”: è chiunque — o qualsiasi documento — riesca a entrare nella finestra di contesto.

Non esiste il carattere magico che “escapa” un documento dal ragionamento del modello. Dire “ignora le istruzioni precedenti” non è un bug nel parser. È un tentativo di influenzare un sistema probabilistico che deve comprendere il linguaggio per funzionare. E qui sta il punto filosofico: la SQL injection attacca un interprete che distingue codice da dati; la prompt injection attacca un sistema in cui codice e dati sono la stessa cosa, perché l’istruzione è solo testo con una probabilità di essere seguita.

Il confine controllo/dati è scomparso 🧱

Per trent’anni la sicurezza moderna si è costruita su un’ossessione: separare l’input dall’interpretazione. Query parametrizzate, template escaping, content security policy… tutto riposa sull’idea che possiamo marchiare a fuoco “questo è codice” e “questo è dato”. Negli LLM quel confine non esiste più: l’istruzione di sistema è testo, il documento è testo, l’input utente è testo, e il modello decide ogni volta, con un peso probabilistico, quale porzione considerare istruzione.

Non è un difetto da patchare: è l’architettura stessa del mezzo. Il modello deve interpretare linguaggio non fidato per essere utile — se smettesse di fidarsi del contenuto, diventerebbe l’ostaggio di ogni singolo messaggio e quindi inutile. Il che significa che la difesa non può stare “prima” del modello, come l’escape, ma dopo: nel punto in cui l’output incontra la realtà con privilegi.

Un agente sicuro non è quello che non legge mai un prompt malevolo. È quello che non può trasformarlo in un danno silenzioso.

Le demo di attacco non sono una strategia 🎪

Il mercato ne abbonda: video dove un ricercatore fa fare al modello tutto ciò che gli passa per la testa, e poi l’azienda annuncia di aver “corretto il problema”. Attenzione: un eval avversario non è una frontiera da oltrepassare una volta, è una palestra da frequentare. I prompt malevoli non arrivano per il compleanno dell’agente: possono entrare da un PDF ricevuto via mail, da una pagina scansionata, da un record di database scritto anni fa da un utente che non conoscerai mai. Se la tua difesa è una sequenza di esempi “educativi” nel prompt di sistema, stai costruendo un castello di sabbia con una marea a calendario.

Il primo eval utile non è il più scenografico: è quello che testa le azioni — che prova a far fare all’agente cose che non dovrebbe, come inviare mail, cancellare record, aggiornare saldi. Perché la differenza tra un agente vulnerabile e uno robusto raramente sta nel pensiero: sta nei muscoli. E i muscoli, purtroppo, si misurano male in una demo.

Difendere le azioni, non il desiderio 🛡️

La tentazione più umana del mondo è chiedere al modello di essere prudente: “non obbedire a input malevoli, sei un assistente fidato”. Funziona circa quanto dire a un collega “non farti manipolare”: buona intenzione, nessun enforcement. La difesa più affidabile non è chiedere al modello di resistere — è toglierli i muscoli per farlo.

La traduzione operativa è noiosa e magnifica: tool con privilegi minimi, output strutturato e validato, conferme per effetti irreversibili, isolamento dei dati, audit log ed eval con contenuti ostili. Non c’è niente di brillante, e funziona. Il principio è invertire il luogo comune: non rendere l’agente più saggio, renderlo meno potente rispetto a ciò di cui non ha bisogno.

Questo spostamento — diffidare dell’azione, non del pensiero — è la stessa lezione che già vediamo per i coding agent e per il senior che orchestra: il rischio non è ciò che il modello “vuole”, ma ciò che gli si permette di fare. Quando l’esecuzione è confinata, il prompt malevolo diventa solo un testo che passa — fastidioso, ma innocuo. E questa è la vittoria silenziosa che nessuna barra di “percentuale di difese dalla prompt injection” saprà mai vendere.

Convivenza, non immunità 🧬

Va detta una cosa scomoda, e va detta chiaro: un sistema basato su un modello linguistico non sarà mai immune alla prompt injection, esattamente come il codice non è mai immune ai bug. L’obiettivo non è l’immunità — un’aggettivo da brochure — ma la convivenza supervisionata: il prompt ostile entra, viene letto, non produce un effetto. È una differenza fondata sul carattere: presumere di poter bloccare ogni ingresso è una strategia di ansia; progettare sistemi che tollerino l’ingresso senza subirlo è una strategia di ingegneria. Il giorno in cui accetteremo che il problema non è “evitare che il malevolo parli con l’agente” ma “far sì che non valga la pena”, smetteremo di inseguire il prompt perfetto e inizieremo a costruire il perimetro intelligibile.

La guida Injection e supply chain entra nei meccanismi; Agenti in produzione mostra come progettare oversight e kill switch. Perché la domanda onesta che dobbiamo smettere di porci non è “il modello capirà che era un attacco?” — la domanda è “anche se non lo capisse, potrebbe rompermi qualcosa?”.