La prompt injection è un problema di permessi

La prompt injection viene spesso trattata come un problema del modello: bisogna rendere il modello più bravo a riconoscere istruzioni ostili. Serve. Non basta.

Un agente che legge e-mail, pagine web, documenti, ticket o repository incontrerà testo che prova a orientarlo. Non sarà sempre il rozzo «ignora le istruzioni precedenti». Sempre più spesso assomiglia al social engineering: urgenza, autorità apparente, un processo aziendale plausibile e un link dall’aria utile. OpenAI descrive questo cambiamento e sostiene che filtrare gli input da solo non limita l’impatto quando la manipolazione riesce.¹

La conclusione è semplice: la prompt injection è soprattutto un problema di permessi.

Non conta soltanto se l’agente crede a una frase malevola. Conta cosa può fare dopo averci creduto.

Se può solo riassumere una pagina, il fallimento è imbarazzante. Se può inviare dati a un nuovo destinatario, approvare un pagamento, cambiare un deployment o eseguire codice in un ambiente privilegiato, lo stesso fallimento ha un prezzo.

Il modello non è il confine di sicurezza

Nella stessa finestra di contesto un modello non ha un modo crittograficamente affidabile per distinguere l’intento dell’utente da istruzioni ostili nascoste nel materiale che deve elaborare. Etichettare la provenienza e addestrare una gerarchia delle istruzioni aiuta. Non trasforma testo arbitrario in un canale di autorità sicuro.

Il confine rigido deve stare quindi fra l’azione proposta e il diritto di eseguirla.

Questo è il test che applico a ogni capacità dell’agente:

Se un documento non affidabile cambia idea all’agente, qual è la cosa peggiore che può fare prima che una persona o un motore di policy lo fermi?

Se la risposta è «tutto ciò che può fare il mio utente», non avete guardrail. Avete un’estensione del browser con un problema di negoziazione di ostaggi.

La OWASP Top 10 for Agentic Applications 2026 affronta questa classe di rischi perché gli agenti pianificano, agiscono e decidono lungo workflow complessi anziché limitarsi a generare testo.² Il pericolo non è una frase strana. È un ciclo capace di farle attraversare un confine di fiducia.

Quattro livelli da tenere separati

Contenuto non affidabile. Corpi delle e-mail, pagine web, documenti recuperati, commenti e output degli strumenti sono dati, non istruzioni. Un link estratto non è una destinazione approvata. Un testo che afferma di essere autorizzato non concede autorizzazione.

Intento. La richiesta dell’utente è l’obiettivo e va fissata prima che l’agente inizi a vagare. «Ricerca fornitori e prepara un confronto» non autorizza a contattarli, creare account o inoltrare note interne. Un piano rende visibile l’interpretazione; non è teatro.

Autorità. Gli strumenti necessitano di permessi stretti e tipizzati. Leggere non è inoltrare. Preparare una modifica non è distribuirla. Scrivere, inviare, acquistare, eliminare ed eseguire sono verbi differenti. Trattateli così. Anthropic definisce l’agente come un ciclo che pianifica, agisce, osserva e si adatta, mantenendo il controllo umano nei punti dove serve giudizio.³ Il checkpoint sensato è prima di un passaggio con conseguenze: nuovo destinatario esterno, operazione con segreti, scrittura irreversibile o salto di perimetro.

Verifica. Il livello d’azione deve controllare fatti che il modello non può auto-certificare: il destinatario è in allowlist? Il dominio è approvato? L’azione supera una soglia di spesa, eliminazione o pubblicazione? Corrisponde al piano dichiarato?

Il modello propone. Il motore di policy può rifiutare. Non è glamour, e proprio per questo funziona.

Tre regole da mettere in produzione questa settimana

Rendete l’esfiltrazione volutamente scomoda. Non date a un unico strumento sia accesso a dati sensibili sia destinazioni di rete arbitrarie. I nuovi destinatari richiedono una policy esplicita e, idealmente, una conferma.

Usate capability token, non potere ambientale. Concedete all’agente un’autorizzazione breve e circoscritta per il compito attuale. Non consegnate una credenziale ampia sperando che il system prompt resti ispirato.

Registrate le azioni proposte come dati strutturati. «L’agente pensava andasse bene» non è un controllo. Memorizzate obiettivo utente, origine dei parametri, strumento, destinazione, decisione di policy e stato della conferma.

Non esiste un classificatore magico che separerà per sempre istruzioni legittime e ostili. Il phishing umano lo dimostra da decenni. Gli agenti sono più difficili perché possono essere persuasi e autorizzati nello stesso turno.

La risposta è ingegneria noiosa: ridurre l’autorità predefinita, legare le azioni all’intento esplicito, limitare le destinazioni e verificare il passaggio dalle parole alle conseguenze.

I filtri miglioreranno. I modelli miglioreranno. Anche gli attaccanti.

I permessi sono la parte che controlliamo.

Fonti