Quanti di voi hanno sentito parlare di "Prompt injection", una vulnerabilità che colpisce i modelli di linguaggio e gli agenti di intelligenza artificiale? OpenAI stessa lo ha ammesso senza troppi giri di parole: la prompt injection non sarà mai completamente risolvibile. Nel loro blog la paragonano esplicitamente alle truffe online e alle tecniche di social engineering, sottolineando come sia improbabile eliminarla del tutto.
Il paragone non è casuale, né rassicurante. Truffe e social engineering non attaccano il software, ma le persone. Funzionano perché sfruttano fiducia, contesto, interpretazione. E soprattutto perché non esiste una patch per la psicologia umana.
Per decenni siamo stati abituati a un’idea diversa di sicurezza informatica. Il software era deterministico: a un input corrispondeva un output prevedibile. Gli attacchi sfruttavano bug, errori di implementazione, falle logiche che i programmatori cercavano di arginare o trovare rimedi: un "buffer overflow" si corregge, una "SQL injection" si previene, un "exploit", almeno in teoria, si chiude con una patch.
Con i modelli linguistici questa distinzione salta. Per la prima volta abbiamo software che non si “buca” soltanto con exploit tecnici, ma si inganna con il linguaggio. La prompt injection non forza il sistema: lo convince.
Nulla di davvero nuovo: Kevin Mitnick e gli anni Novanta
Se questo scenario suona inquietante, vale la pena ricordare che non è affatto una novità assoluta. Già negli anni Novanta Kevin Mitnick, uno dei più celebri hacker della storia, raccontava nel libro “Sulle tracce di Kevin” come fosse riuscito a entrare nei sistemi più protetti non grazie a sofisticate vulnerabilità tecniche, ma semplicemente parlando con le persone giuste.
Telefonate, email, pretesti credibili. Nessun exploit, nessun malware, ma solo parole. Mitnick non attaccava i server: attaccava il contesto umano che li circondava.
La Prompt injection funziona allo stesso modo. Manipola il contesto, sfrutta la fiducia implicita del sistema, inserisce istruzioni malevole all’interno di flussi apparentemente legittimi. Non viola le regole: le reinterpreta.
Quando il software diventa “truffabile”
OpenAI lo ha mostrato con una demo tanto semplice quanto inquietante. Un attaccante inserisce un’email nella inbox di una vittima (semplicemente manda una email). L’utente chiede a un agente IA di scrivere un messaggio di risposta automatica. L’agente analizza le email presenti, intercetta quella dell’attaccante e interpreta come legittime delle istruzioni nascoste nel testo. Il risultato? Non un messaggio automatico, ma una lettera di dimissioni inviata direttamente al CEO.
Il sistema non ha malfunzionato e non c’è stato alcun bug da correggere. Ha fatto esattamente ciò per cui è stato progettato: leggere, interpretare, agire.
La differenza è che, a differenza di un essere umano, un modello di IA non ha buon senso, contesto sociale, istinto di incoerenza. Non si chiede se quell’azione “ha senso” e quindi non prende decisioni autonome. Valuta solo la plausibilità linguistica e contestuale dell’istruzione.
Ed è qui che nasce il vero problema: il software è diventato truffabile.
Il vero rischio è il nostro approccio mentale
Il punto più critico, però, non è tecnico. È culturale. Continuiamo ad applicare ai sistemi di IA lo stesso approccio mentale che usavamo con il software tradizionale, pensando in termini di patch e correzioni. Ma se il paragone corretto è con il social engineering, allora le difese non possono essere solo tecniche, confermando l'importanza di adottare contromisure tipiche della sicurezza organizzativa e umana. Parlo di segregazione delle funzioni, principi di minimizzazione dei privilegi, verifica umana per i passaggi critici e "zero trust" sugli input, anche quelli testuali.
In altre parole, dobbiamo smettere di trattare l’IA come un semplice software e iniziare a considerarla come un attore che opera in un contesto socio-tecnico, con rischi simili a quelli di un collaboratore ingenuo ma estremamente veloce.
Diventa di conseguenza evidente che il problema non è più “insegnare all’IA a non sbagliare”, ma progettare sistemi in cui non possa sbagliare da sola.
Le regole, i filtri, gli esempi negativi e i guardrail sono utili, ma funzionano solo fino a un certo punto. Non perché l’IA sia “difettosa”, ma perché il linguaggio è ambiguo, il contesto è manipolabile e l’intenzione non è formalizzabile in modo deterministico.
Per questo le difese realmente efficaci non agiscono sull’interpretazione, ma sull’azione. L’AI può analizzare, suggerire, simulare scenari. Ma la decisione ultima deve rimanere all’utente.
È lo stesso principio che governa i processi aziendali da decenni: un dipendente può ricevere una mail che chiede un bonifico, ma non può eseguirlo senza una seconda verifica, una firma autorizzata, un controllo umano.
Uno schema architetturale "by-design" per l’IA agentica deve quindi prevedere una netta separazione tra interpretazione e azione e l'impossibilità di delegare il controllo finale a un sistema probabilistico. Perché il punto non è mettere in sicurezza l’IA come fosse un software tradizionale, ma governarla come un comportamento.
Un modello di Intelligenza artificiale non va messo in sicurezza come un software, ma governato al pari di un comportamento.
Il paragone non è casuale, né rassicurante. Truffe e social engineering non attaccano il software, ma le persone. Funzionano perché sfruttano fiducia, contesto, interpretazione. E soprattutto perché non esiste una patch per la psicologia umana.
Per decenni siamo stati abituati a un’idea diversa di sicurezza informatica. Il software era deterministico: a un input corrispondeva un output prevedibile. Gli attacchi sfruttavano bug, errori di implementazione, falle logiche che i programmatori cercavano di arginare o trovare rimedi: un "buffer overflow" si corregge, una "SQL injection" si previene, un "exploit", almeno in teoria, si chiude con una patch.
Con i modelli linguistici questa distinzione salta. Per la prima volta abbiamo software che non si “buca” soltanto con exploit tecnici, ma si inganna con il linguaggio. La prompt injection non forza il sistema: lo convince.
Nulla di davvero nuovo: Kevin Mitnick e gli anni Novanta
Se questo scenario suona inquietante, vale la pena ricordare che non è affatto una novità assoluta. Già negli anni Novanta Kevin Mitnick, uno dei più celebri hacker della storia, raccontava nel libro “Sulle tracce di Kevin” come fosse riuscito a entrare nei sistemi più protetti non grazie a sofisticate vulnerabilità tecniche, ma semplicemente parlando con le persone giuste.
Telefonate, email, pretesti credibili. Nessun exploit, nessun malware, ma solo parole. Mitnick non attaccava i server: attaccava il contesto umano che li circondava.
La Prompt injection funziona allo stesso modo. Manipola il contesto, sfrutta la fiducia implicita del sistema, inserisce istruzioni malevole all’interno di flussi apparentemente legittimi. Non viola le regole: le reinterpreta.
Quando il software diventa “truffabile”
OpenAI lo ha mostrato con una demo tanto semplice quanto inquietante. Un attaccante inserisce un’email nella inbox di una vittima (semplicemente manda una email). L’utente chiede a un agente IA di scrivere un messaggio di risposta automatica. L’agente analizza le email presenti, intercetta quella dell’attaccante e interpreta come legittime delle istruzioni nascoste nel testo. Il risultato? Non un messaggio automatico, ma una lettera di dimissioni inviata direttamente al CEO.
Il sistema non ha malfunzionato e non c’è stato alcun bug da correggere. Ha fatto esattamente ciò per cui è stato progettato: leggere, interpretare, agire.
La differenza è che, a differenza di un essere umano, un modello di IA non ha buon senso, contesto sociale, istinto di incoerenza. Non si chiede se quell’azione “ha senso” e quindi non prende decisioni autonome. Valuta solo la plausibilità linguistica e contestuale dell’istruzione.
Ed è qui che nasce il vero problema: il software è diventato truffabile.
Il vero rischio è il nostro approccio mentale
Il punto più critico, però, non è tecnico. È culturale. Continuiamo ad applicare ai sistemi di IA lo stesso approccio mentale che usavamo con il software tradizionale, pensando in termini di patch e correzioni. Ma se il paragone corretto è con il social engineering, allora le difese non possono essere solo tecniche, confermando l'importanza di adottare contromisure tipiche della sicurezza organizzativa e umana. Parlo di segregazione delle funzioni, principi di minimizzazione dei privilegi, verifica umana per i passaggi critici e "zero trust" sugli input, anche quelli testuali.
In altre parole, dobbiamo smettere di trattare l’IA come un semplice software e iniziare a considerarla come un attore che opera in un contesto socio-tecnico, con rischi simili a quelli di un collaboratore ingenuo ma estremamente veloce.
Diventa di conseguenza evidente che il problema non è più “insegnare all’IA a non sbagliare”, ma progettare sistemi in cui non possa sbagliare da sola.
Le regole, i filtri, gli esempi negativi e i guardrail sono utili, ma funzionano solo fino a un certo punto. Non perché l’IA sia “difettosa”, ma perché il linguaggio è ambiguo, il contesto è manipolabile e l’intenzione non è formalizzabile in modo deterministico.
Per questo le difese realmente efficaci non agiscono sull’interpretazione, ma sull’azione. L’AI può analizzare, suggerire, simulare scenari. Ma la decisione ultima deve rimanere all’utente.
È lo stesso principio che governa i processi aziendali da decenni: un dipendente può ricevere una mail che chiede un bonifico, ma non può eseguirlo senza una seconda verifica, una firma autorizzata, un controllo umano.
Uno schema architetturale "by-design" per l’IA agentica deve quindi prevedere una netta separazione tra interpretazione e azione e l'impossibilità di delegare il controllo finale a un sistema probabilistico. Perché il punto non è mettere in sicurezza l’IA come fosse un software tradizionale, ma governarla come un comportamento.
Un modello di Intelligenza artificiale non va messo in sicurezza come un software, ma governato al pari di un comportamento.
