C’è stato un momento, non molto tempo fa, in cui la prompt injection era considerata un problema accademico. Interessante da esplorare in ricerca, preoccupante in teoria, ma difficile da sfruttare davvero in produzione.
Nel 2026, quel momento è finito.
Perché gli agenti cambiano la categoria del rischio
Un chatbot manipolato produce testo sbagliato. Un agente manipolato produce azioni sbagliate: file modificati, credenziali esposte, software installato, dati esfiltrati verso sistemi esterni.
La differenza non è di grado. È di natura. E richiede un approccio alla sicurezza completamente diverso.
I due vettori principali
Prompt injection significa che istruzioni malevole vengono inserite negli input dell’agente — o nei contenuti che l’agente legge durante la sua esecuzione — per farlo deviare dal comportamento previsto.
Jailbreak significa aggirare i vincoli del modello stesso.
Nel contesto degli agenti, la prompt injection è spesso più pericolosa del jailbreak: perché non richiede di “rompere” il modello. Basta convincere il sistema a chiamare un tool nel modo sbagliato, e il danno è fatto.
Incidenti reali, non scenari ipotetici
Nel 2025–2026 abbiamo documentazione concreta di agenti di coding open-source sfruttati tramite prompt injection per eseguire installazioni non autorizzate sulle macchine degli utenti. Abbiamo ricerche che mostrano prompt injection indirette attraverso contenuti web apparentemente innocui — una pagina, un’issue, un documento — che portano l’agente ad attivare tool con privilegi eccessivi.
Il pattern è sempre lo stesso: l’agente legge testo non fidato, lo interpreta come istruzione, e poi agisce con permessi che non avrebbe mai dovuto avere.
Dove stanno i punti deboli reali
Tool con descrizioni inadeguate. Se un tool è descritto male, l’agente lo usa in modo imprevedibile. Se la descrizione è stata manipolata, il rischio è operativo.
Connettori troppo permissivi. Filesystem + shell + rete + credenziali è una combinazione che non dovrebbe mai esistere senza policy esplicite.
Modalità “always allow”. Ogni automazione che riduce le frizioni di conferma aumenta proporzionalmente la superficie d’attacco.
Contesto contaminato. Un documento, un’issue, una pagina web possono contenere istruzioni nascoste. Se l’agente le tratta come input fidati, le esegue.
Come si difende seriamente un sistema agentico
Least privilege: tool minimi, scope minimi, write separato da read. Non è un suggerimento, è un requisito.
Policy enforcement fuori dal modello: un layer che valida ogni tool call indipendentemente da cosa il modello voglia fare. Allowlist di comandi, limiti su path, blocco egress quando non necessario.
Sandbox: esecuzione in container o VM, filesystem isolato, nessun accesso ai segreti per default.
Classificazione delle fonti: tutto ciò che arriva dal web o da input non controllati è “untrusted” fino a prova contraria. Non può diventare istruzione operativa senza passare un filtro esplicito.
Two-person rule per azioni critiche: deploy, pagamenti, cancellazioni, invii verso l’esterno richiedono approvazione umana o un secondo agente verifier indipendente.
Segreti fuori dal prompt: usa secret manager e token short-lived. Un agente non dovrebbe mai vedere credenziali in chiaro nel contesto.
Observability: logging di ogni tool call, tracing end-to-end, alerting su pattern anomali — aumento improvviso di egress, accesso a file sensibili, comandi insoliti.
La conclusione pratica è scomoda ma necessaria: più un agente è utile, più richiede governance. L’alternativa è costruire un sistema che funziona finché nessuno prova a romperlo. E nel 2026, qualcuno ci proverà.