Progettare agenti di IA resistenti all’iniezione di prompt

Gli agenti di IA sono sempre più in grado di navigare sul web, recuperare informazioni e compiere azioni per conto dell’utente. Queste capacità sono utili, ma creano anche nuovi modi con cui i malintenzionati possono tentare di manipolare il sistema.

Questi attacchi sono spesso descritti come l'iniezione di prompt⁠: istruzioni inserite in contenuti esterni con l’obiettivo di indurre il modello a fare qualcosa che l’utente non ha richiesto. Nella nostra esperienza, le versioni più efficaci di questi attacchi nel mondo reale assomigliano sempre più a tecniche di ingegneria sociale piuttosto che a semplici sovrascritture del prompt.

Questo cambiamento è significativo. Se il problema non è solo individuare una stringa dannosa, ma anche resistere a contenuti fuorvianti o manipolativi nel contesto, la difesa non può basarsi esclusivamente sul filtraggio degli input. Richiede inoltre una progettazione del sistema che limiti l’impatto di eventuali manipolazioni, anche quando alcuni attacchi hanno successo.

I primi attacchi di tipo “iniezione di prompt” potevano essere semplici quanto modificare un articolo di Wikipedia per includere istruzioni dirette agli agenti di IA che lo visitavano; senza esperienza, durante l’addestramento, di un simile ambiente avversario, i modelli di IA spesso avrebbero seguito tali istruzioni senza metterle in discussione¹. Con il miglioramento dei modelli, la loro vulnerabilità a questo tipo di suggerimento è diminuita e abbiamo osservato che gli attacchi in stile iniezione di prompt hanno iniziato a incorporare elementi di ingegneria sociale:

Nel più ampio ecosistema della sicurezza dell’IA è ormai comune raccomandare tecniche come il “firewalling dell’IA”, in cui un intermediario tra l’agente di IA e il mondo esterno tenta di classificare gli input come iniezione di prompt dannosa oppure come input legittimi. Tuttavia, gli attacchi più sofisticati spesso non vengono intercettati da questi sistemi. Per questi sistemi, individuare un input dannoso diventa un problema molto difficile, simile a riconoscere una menzogna o un’informazione fuorviante, spesso senza disporre del contesto necessario.

Con l’aumentare della complessità degli attacchi di iniezione di prompt, abbiamo osservato che le tecniche offensive più efficaci sfruttano tattiche di ingegneria sociale. Piuttosto che considerare questi attacchi di iniezione di prompt con componenti di ingegneria sociale come una categoria di problema separata o del tutto nuova, abbiamo iniziato ad analizzarli attraverso la stessa prospettiva utilizzata in altri ambiti per gestire il rischio di ingegneria sociale che colpisce gli esseri umani. In questi sistemi, l’obiettivo non è solo identificare perfettamente gli input dannosi, ma progettare agenti e sistemi in modo da limitare l’impatto di eventuali manipolazioni, anche quando hanno successo. Questi sistemi si dimostrano efficaci nel mitigare sia l’iniezione di prompt sia l’ingegneria sociale.

In questo modo possiamo immaginare l’agente di IA come parte di un sistema a tre attori simile a quello dell’assistenza clienti: l’agente vuole agire per conto del proprio datore di lavoro, ma è continuamente esposto a input esterni che potrebbero tentare di fuorviarlo. L’agente dell’assistenza clienti, umano o IA, deve avere limiti alle proprie capacità per ridurre il rischio intrinseco di operare in un ambiente potenzialmente malevolo.

Immagina una situazione in cui una persona gestisce un sistema di assistenza clienti ed è in grado di erogare carte regalo e rimborsi per disagi segnalati dal cliente, come ritardi nella consegna, danni dovuti a un malfunzionamento, ecc. Si tratta di un problema con più parti coinvolte: l’azienda deve potersi fidare che l’agente conceda rimborsi per le ragioni corrette, mentre l’agente interagisce anche con terze parti che potrebbero cercare di fuorviarlo o persino metterlo sotto pressione.

Nel mondo reale, all’agente viene fornito un insieme di regole da seguire, ma nell’ambiente avversario in cui opera ci si aspetta che venga comunque indotto in errore. Ad esempio, un cliente potrebbe inviare un messaggio sostenendo che il rimborso non è mai stato ricevuto, oppure minacciare conseguenze se il rimborso non viene concesso. I sistemi deterministici con cui l’agente interagisce limitano l’importo dei rimborsi che possono essere concessi a un cliente, segnalano potenziali email di phishing e forniscono altre misure di mitigazione per ridurre l’impatto della compromissione di un singolo agente. 

Questo approccio ha guidato la progettazione di una solida serie di contromisure che abbiamo implementato per soddisfare le aspettative di sicurezza dei nostri utenti.

In ChatGPT combiniamo questo modello di ingegneria sociale con approcci più tradizionali di ingegneria della sicurezza, come l’analisi source-sink.

In questo contesto, un aggressore ha bisogno sia di una sorgente, cioè un modo per influenzare il sistema, sia di un sink, ovvero una capacità che diventa pericolosa nel contesto sbagliato. Per i sistemi agentici, questo spesso significa combinare contenuti esterni non attendibili con un’azione, come trasmettere informazioni a una terza parte, seguire un link o interagire con uno strumento.

Il nostro obiettivo è preservare un principio fondamentale di sicurezza per gli utenti: azioni potenzialmente pericolose, o la trasmissione di informazioni potenzialmente sensibili, non dovrebbero avvenire in modo silenzioso o senza adeguate misure di salvaguardia.

Gli attacchi che osserviamo contro ChatGPT consistono più spesso nel tentativo di convincere l’assistente a estrarre informazioni riservate da una conversazione e trasmetterle a una terza parte malevola. Nella maggior parte dei casi di cui siamo a conoscenza, questi attacchi falliscono perché il nostro addestramento alla sicurezza porta l’agente a rifiutare. Nei casi in cui l’agente venga convinto, abbiamo sviluppato una strategia di mitigazione chiamata Safe URL, progettata per rilevare quando le informazioni apprese dall’assistente durante la conversazione verrebbero trasmesse a una terza parte. In questi rari casi, mostriamo all’utente le informazioni che verrebbero trasmesse e chiediamo conferma; in alternativa blocchiamo la trasmissione e chiediamo all’agente di provare un altro modo per procedere con la richiesta dell’utente.

Questo stesso meccanismo si applica alle navigazioni e ai segnalibri in Atlas⁠; e alle ricerche e alle navigazioni in Deep Research⁠. ChatGPT Canvas⁠ & ChatGPT Apps⁠ adottano un approccio simile, consentendo all'agente di creare e utilizzare applicazioni funzionali: queste vengono eseguite in una sandbox in grado di rilevare comunicazioni impreviste e chiedere il consenso dell'utente⁠(si apre in una nuova finestra).

Per ulteriori informazioni su “Safe URL” e per consultare un documento sulla sua struttura, visita il post del blog dedicato Mantenere i tuoi dati al sicuro quando un agente IA fa clic su un link⁠.

Un’interazione sicura con il mondo esterno, potenzialmente avversario, è necessaria per agenti pienamente autonomi. Quando si integra un modello di IA in un sistema applicativo, consigliamo di chiedersi quali controlli dovrebbe avere un agente umano in una situazione analoga e di implementarli. Ci aspettiamo che un modello di IA molto avanzato sia in grado di resistere all’ingegneria sociale meglio di un agente umano, ma ciò non è sempre fattibile o conveniente dal punto di vista dei costi, a seconda dell’applicazione.

Continuiamo a esplorare le implicazioni del social engineering contro i modelli di IA e le difese possibili, integrando i risultati sia nelle architetture di sicurezza delle nostre applicazioni sia nei processi di addestramento dei modelli.