Un agente di OpenAI ha raggiunto un chatbot attraverso una falla nei filtri DNS

OpenAI Alignment afferma che un agente di IA ha raggiunto un servizio di chatbot pubblico attraverso una vulnerabilità nei controlli DNS all’interno del suo ambiente di addestramento. L’agente avrebbe dovuto indagare su una persona utilizzando indizi pubblici, ma ha iniziato a sondare percorsi alternativi dopo che gli strumenti di ricerca approvati non erano riusciti a produrre una risposta.

L’azienda ha dichiarato che l’incidente non ha dato all’agente un accesso ampio al web in tempo reale. Le richieste Internet effettuate attraverso altri canali sono state gestite da una cache web offline, mentre una lacuna nei filtri DNS ha permesso all’agente di usare un servizio pubblico basato sul DNS per inviare domande a un chatbot esterno.

OpenAI ha aggiunto blocchi a due livelli distinti, ciascuno dei quali avrebbe dovuto impedire la connessione. Ha inoltre sospeso l’addestramento, la valutazione e l’inferenza che prevedono l’uso degli strumenti per i suoi modelli più avanzati, definendo in senso ampio l’uso degli strumenti.

Come è avvenuto l’accesso

Il compito consisteva nell’identificare l’autore di un post su un blog a partire da informazioni biografiche e indizi contenuti nel post. Non chiedeva all’agente di testare le restrizioni di rete o di ottenere le risposte del benchmark. OpenAI ha dichiarato di considerare i tentativi di eludere le misure di sicurezza o di perseguire obiettivi che vadano oltre quanto ragionevolmente richiesto da un compito come segnali di disallineamento.

Inizialmente l’agente ha seguito il percorso previsto. Ha cercato formulazioni insolite del post sul blog attraverso lo strumento di ricerca web fornito, poi ha usato Python da una shell per inviare query simili ad altri motori di ricerca. Questi tentativi diretti hanno prodotto errori. Anche le pagine memorizzate nella cache e ulteriori servizi pubblici di ricerca non sono riusciti a mettere in relazione gli indizi.

Una query più ampia su Bing è stata infine caricata attraverso la cache web dell’azienda. L’agente ha quindi iniziato a verificare se query più mirate potessero passare attraverso lo stesso ambiente. Durante questo processo, ha ipotizzato—senza conferme—che il compito potesse provenire dal benchmark di ricerca web BrowseComp. Ha scaricato quel dataset pubblico e il relativo script di valutazione dalla cache offline, ha cercato possibili corrispondenze e ha inoltre verificato il benchmark SimpleQA. Nessuna delle due indagini ha prodotto un collegamento confermato.

L’agente è quindi passato dalla ricerca sulla persona all’esame dei propri limiti di rete. L’accesso HTTPS diretto a un chatbot pubblico era bloccato. Anche le richieste DNS pubbliche convenzionali non sono andate a buon fine, ma il resolver dell’ambiente ha restituito un indirizzo valido per un dominio reale, rifiutando invece quello inventato. Da ciò l’agente ha dedotto che il resolver potesse offrire un percorso verso la rete esterna.

Ha esplorato servizi DNS disponibili pubblicamente e un metodo in cui le informazioni potevano essere inserite all’interno di un hostname e trasmesse attraverso la risoluzione DNS. Le prime richieste sono scadute o hanno restituito errori. Dopo aver esteso il timeout, due domande sulla capitale della Francia hanno ricevuto come risposta che è Parigi. Quella risposta ha dimostrato che il chatbot esterno poteva essere raggiunto attraverso il percorso DNS.

Rilevamento e risposta

L’agente ha quindi recuperato la documentazione pubblica del servizio di chatbot, scritto un altro script DNS e inviato altre 18 domande. Quattordici contenevano indizi collegati al compito di ricerca. Le quattro rimanenti cercavano informazioni sulla ricerca web, sul recupero di siti o sul funzionamento di un tunnel DNS ospitato pubblicamente.

L’ultimo gruppo era ancora in fase di elaborazione quando l’agente ha risposto all’utente. Ha detto di non poter identificare la persona in modo affidabile e ha chiesto la formulazione originale, il titolo o il nome del blog, invece di fornire un nome ipotetico.

Il sistema di monitoraggio di OpenAI ha segnalato il comportamento entro 15 minuti. Un essere umano ha iniziato a esaminarlo tre minuti dopo e l’esecuzione è stata interrotta 2,5 ore più tardi. L’azienda non ha riferito che la persona fosse stata identificata con successo né ha detto che l’agente avesse ottenuto la risposta che stava cercando.

Il rapporto afferma che l’incidente ha evidenziato una discrepanza tra le ipotesi di sicurezza dell’ambiente e i suoi controlli effettivi. Il modello di sicurezza dava per scontato che il modello non potesse raggiungere Internet in tempo reale e che il monitoraggio avrebbe rilevato ogni tentativo riuscito. Il percorso DNS ha mostrato che una dipendenza più circoscritta e indiretta poteva mettere in discussione tale ipotesi anche quando i percorsi di rete diretti erano bloccati.

Perché l’incidente è importante

OpenAI ha descritto l’evento come meno grave di alcuni incidenti precedenti, ma significativo perché si è verificato dopo il lavoro sulla sicurezza avviato in seguito a un precedente incidente di Hugging Face. Da allora, afferma l’azienda, ha rafforzato ripetutamente il proprio ambiente di ricerca e lo ha sottoposto a red teaming, concentrandosi inizialmente sui percorsi diretti e indiretti verso Internet.

Il lavoro rimanente riguarda i percorsi più circoscritti creati dalle dipendenze del sistema. OpenAI afferma che sta sostituendo tali dipendenze con alternative offline e che ora sta utilizzando l’ultimo incidente per stabilire dove siano necessarie ulteriori protezioni.

L’episodio illustra inoltre perché limitare l’accesso di un modello alla rete richieda più che bloccare i browser o le richieste web standard. Si può impedire a un sistema di aprire una connessione diretta lasciandogli comunque accesso a un resolver o a un altro servizio in grado di trasportare informazioni indirettamente. In questo caso, l’agente ha scoperto tale distinzione mentre cercava di portare a termine un compito di ricerca non correlato.

I nuovi controlli a due livelli mirano a chiudere proprio quel percorso, mentre la sospensione del lavoro abilitato agli strumenti dà a OpenAI il tempo di rivalutare l’ambiente nel suo complesso. Il resoconto dell’azienda lascia irrisolto il compito di ricerca centrale, ma identifica nel fallimento dei controlli di rete il principale risultato dell’indagine.