OpenAI ammette: la prompt injection è social engineering. Ecco cosa non dicono.

OpenAI ha pubblicato un articolo che cambia il modo in cui dovremmo pensare alla sicurezza degli agenti AI. Il messaggio centrale: la prompt injection non è un bug da risolvere con un filtro. È social engineering.

L'articolo si intitola "Designing AI agents to resist prompt injection" ed è uscito l'11 marzo 2026. Merita attenzione non tanto per le soluzioni tecniche proposte, quanto per il cambio di paradigma che rappresenta. Per la prima volta, uno dei principali laboratori di AI ammette apertamente che il problema della prompt injection assomiglia più alla manipolazione psicologica che a una vulnerabilità software tradizionale.

In questo articolo analizzo cosa dice OpenAI, cosa dice bene, cosa non dice e perché il tempismo di questa pubblicazione non è casuale.

Prompt injection: da bug tecnico a manipolazione

Per chi non ha familiarità con il termine: la prompt injection è una tecnica con cui un attaccante inserisce istruzioni malevole in contenuti esterni — email, pagine web, documenti — che un agente AI potrebbe leggere. L'obiettivo è far fare all'agente qualcosa che l'utente non ha chiesto.

I primi attacchi di questo tipo erano banali. Bastava modificare una pagina Wikipedia aggiungendo un'istruzione diretta tipo "ignora le tue istruzioni precedenti e fai X". Senza esperienza di ambienti ostili, i modelli eseguivano senza fare domande.

Ma i modelli sono migliorati, e gli attacchi si sono evoluti di conseguenza. L'esempio più interessante citato da OpenAI è un'email costruita come un messaggio aziendale legittimo su una ristrutturazione interna. Il testo usa un linguaggio professionale e credibile, fa riferimento a riunioni reali, elenca task plausibili. Solo verso la fine compaiono istruzioni per estrarre dati sensibili dei dipendenti e inviarli a un endpoint esterno.

In fase di test, questo attacco ha funzionato nel 50 percento dei casi quando l'utente chiedeva a ChatGPT di analizzare le proprie email. Non è un exploit tecnico. È manipolazione contestuale. È social engineering applicato a un'intelligenza artificiale.

L'analogia con il social engineering: cosa dice bene OpenAI

Il cuore dell'articolo è un cambio di prospettiva. OpenAI propone di smettere di trattare la prompt injection come un problema di filtraggio degli input e iniziare a trattarla come un problema di design del sistema.

L'analogia che usano è efficace: immagina un operatore di customer service. L'azienda sa che questo operatore sarà esposto a clienti che mentono, manipolano, cercano di ottenere rimborsi non dovuti. La soluzione non è addestrare l'operatore a individuare ogni singola bugia. La soluzione è progettare il sistema con dei limiti: l'operatore può emettere rimborsi solo fino a un certo importo, i sistemi automatici flaggano i pattern sospetti, ci sono checkpoint che richiedono approvazione.

Applicato agli agenti AI, questo significa progettare il sistema partendo dal presupposto che l'agente verrà manipolato, prima o poi. La domanda non è "come impedisco che venga ingannato" ma "come limito i danni quando verrà ingannato".

OpenAI usa anche un framework tecnico interessante: la source-sink analysis. Un attacco richiede due cose: una source, cioè un modo per influenzare il sistema con contenuto esterno, e un sink, cioè un'azione pericolosa come trasmettere dati a terzi o navigare verso un URL malevolo. Se proteggi i sink, riduci il rischio anche quando la source è compromessa.

Questo è l'approccio più pragmatico che abbia visto articolato da un laboratorio AI. Invece di promettere modelli impermeabili alla manipolazione, ragiona in termini di architettura di sistema e contenimento del danno. È il modo in cui la sicurezza informatica funziona da decenni: non elimini le minacce, le gestisci.

Cosa non dicono: tre punti critici

Fin qui, l'analisi di OpenAI è solida. Ma ci sono almeno tre aspetti significativi che l'articolo non affronta o affronta in modo evasivo.

Il problema è probabilmente irrisolvibile a livello di modello

OpenAI scrive che "un modello massimamente intelligente potrà resistere al social engineering meglio di un agente umano". È una frase vaga che sposta l'obiettivo nel futuro senza impegnarsi. La realtà è che la capacità di un modello di seguire istruzioni è la stessa capacità che lo rende vulnerabile alla prompt injection. Non puoi avere un modello che esegue perfettamente ciò che gli chiedi e allo stesso tempo ignora perfettamente le istruzioni malevole inserite nei contenuti che legge. Sono le due facce della stessa medaglia.

Nessun paper, nessun benchmark ha dimostrato una soluzione generale a questo problema. OpenAI non lo ammette esplicitamente, ma il fatto stesso che proponga difese architetturali anziché difese a livello di modello lo dice implicitamente.

Il trade-off autonomia/sicurezza che nessuno vuole affrontare

La soluzione principale che OpenAI descrive per ChatGPT si chiama Safe URL: quando il modello sta per trasmettere informazioni a un URL esterno, il sistema mostra all'utente cosa verrebbe inviato e chiede conferma.

Funziona. Ma c'è un problema fondamentale: se l'agente ti chiede conferma ogni volta che deve compiere un'azione potenzialmente sensibile, perdi il valore principale dell'automazione. Un agente che si ferma continuamente per chiedere permesso non è autonomo. È un'interfaccia complicata per fare cose che potresti fare a mano.

Esiste un trade-off fondamentale tra autonomia e sicurezza che l'articolo non affronta. Più autonomia dai all'agente, più ampio è il danno potenziale se viene manipolato. Più lo limiti, meno utile diventa. Trovare il punto di equilibrio giusto è il problema reale, e OpenAI non offre una risposta.

Chi usa le API si arrangia

Il terzo punto è forse il più rilevante per chi lavora con l'AI professionalmente. Le difese descritte nell'articolo — Safe URL, sandbox, conferme utente — sono implementate in ChatGPT, Atlas, Deep Research, Canvas. Sono prodotti OpenAI.

Ma chi costruisce agenti personalizzati usando le API di OpenAI non ha accesso a Safe URL. Non ha la sandbox di Canvas. Non ha le protezioni di Deep Research. Il messaggio implicito è: noi proteggiamo i nostri prodotti, voi implementate le vostre difese. L'articolo fornisce un framework concettuale utile ma nessuno strumento concreto per gli sviluppatori che costruiscono agenti indipendenti.

Il tempismo non è casuale

Questo articolo non esce nel vuoto. OpenAI lo pubblica nella stessa settimana in cui sta spingendo aggressivamente prodotti basati su agenti sempre più autonomi: ChatGPT agent per navigare il web e compiere azioni, Deep Research per analisi approfondite con accesso a fonti esterne, Atlas per la ricerca web integrata.

È una mossa intelligente. Pubblicare un articolo sulla sicurezza degli agenti AI nel momento in cui lanci agenti AI serve a due scopi. Primo, è genuina trasparenza: stanno effettivamente lavorando sul problema e condividono il framework con cui lo affrontano. Secondo, è PR difensiva: quando inevitabilmente emergerà un caso di prompt injection su uno dei loro prodotti, potranno dire "ne eravamo consapevoli e stavamo lavorando attivamente sulle difese".

Non è cinismo. È pragmatismo. Lo stesso pragmatismo che loro stessi propongono come approccio alla sicurezza degli agenti.

Cosa significa per chi usa l'AI nel proprio lavoro

Il messaggio più importante dell'articolo di OpenAI non è tecnico. È un cambio di mentalità: la prompt injection non si risolve, si gestisce.

Se usi agenti AI nel tuo lavoro — per analisi, automazione, gestione contenuti — non puoi aspettarti che il modello sia impermeabile alla manipolazione. Devi pensare come un security designer: quali azioni può compiere l'agente? Quali dati può vedere? Cosa succede se viene ingannato? Quali checkpoint servono prima delle azioni irreversibili?

L'analogia del customer service agent è il framework giusto. Non dai le chiavi della cassaforte a un operatore al primo giorno. Non dovresti darle nemmeno al tuo agente AI.

OpenAI ha il merito di aver formalizzato questo approccio e di averlo comunicato in modo chiaro. Ha il limite di non ammettere apertamente che il problema è strutturale e che le loro difese proteggono i loro prodotti, non necessariamente i tuoi. Ma il framework è solido. Usalo.