La risposta breve
I ricercatori di Zenity Labs hanno rivelato AgentForger, una falla di cross-site request forgery (CSRF) nell'Agent Builder di ChatGPT che permetteva a un singolo link di phishing di costruire, autorizzare e distribuire un agente IA autonomo controllato dall'attaccante all'interno dell'organizzazione di una vittima — senza alcun clic di conferma. Il Builder accettava parte del suo stato iniziale tramite parametri dell'URL, e il valore in initial_assistant_prompt veniva eseguito anziché soltanto mostrato. Un clic di un utente autenticato che disponeva dei Workspace Agents e di almeno un'app collegata bastava perché il Builder cablasse i suoi connettori, spegnesse le richieste di approvazione, pubblicasse un nuovo agente e lo mettesse a pianificazione. OpenAI è stata avvisata tramite Bugcrowd il 4 giugno 2026 e ha chiuso il buco in pochi giorni rimuovendo il parametro vulnerabile.
La patch è fatta, quindi non è un'emergenza. È una lezione di progettazione per chiunque rilasci agenti IA: l'agente è un'identità con accesso permanente, e uno forgiato è un insider. L'aspetto interessante di AgentForger non è il bug specifico — è quanto fosse ordinaria la falla web e quanto raggio d'azione abbia ereditato perché un agente poggia su connettori aziendali pre-approvati.
Cosa ha rivelato Zenity
Il red team IA di Zenity Labs ha pubblicato a fine luglio 2026 una ricerca che descrive AgentForger, una falla nell'Agent Builder distribuito con i Workspace Agents di ChatGPT. L'attacco richiedeva soltanto che il bersaglio fosse autenticato in ChatGPT, avesse accesso ai Workspace Agents e disponesse di almeno un connettore già autorizzato — Outlook, Gmail, Google Calendar, Slack o Teams, ad esempio. In queste condizioni comuni, aprire un link dall'aspetto normale bastava a mettere in piedi un agente funzionante che rispondeva all'attaccante anziché al dipendente.
La catena, come la descrive Zenity, è schietta. Un clic e il Builder « si metteva al lavoro per conto dell'attaccante, cablando i connettori esistenti della vittima, spegnendo le richieste di approvazione, pubblicando il nuovo agente e liberandolo a pianificazione ». Anziché contattare una classica infrastruttura di comando e controllo, l'agente forgiato sorvegliava la casella di posta della vittima in cerca di messaggi con una parola chiave definita nell'oggetto e trattava ciascuno come un nuovo incarico — un canale silenzioso, a basso segnale, che sembra normale traffico di posta.
La cronologia conta per come si legge la notizia. Zenity ha segnalato il problema a OpenAI tramite Bugcrowd il 4 giugno 2026; OpenAI l'ha riconosciuto il 5 giugno e corretto in pochi giorni rimuovendo il parametro dell'URL vulnerabile, quindi il percorso specifico è chiuso. Il resoconto pubblico è l'evento di luglio, non uno zero-day attivo. Inoltre, OpenAI ha dichiarato che dismetterà l'Agent Builder il 30 novembre 2026 per indirizzare gli sviluppatori verso il suo Agents SDK — un promemoria che la superficie stessa è ancora giovane e in movimento.
Come un link ha forgiato un agente
La meccanica è un bug web da manuale in un contesto insolito. L'Agent Builder lasciava arrivare parte del suo stato iniziale tramite parametri dell'URL, in una forma come /agents/studio/new?template_name=…&initial_assistant_prompt=…. Il problema, nelle parole di Zenity, era che « quando la pagina si carica, il valore di initial_assistant_prompt non viene semplicemente inserito nel campo del prompt — viene automaticamente inviato ed eseguito ». Un'istruzione incorporata in un link diventava il primo comando su cui il Builder agiva, con l'autorità di chiunque avesse cliccato.
Questa è la cross-site request forgery: un'azione che modifica lo stato, innescata da una richiesta malevola che cavalca la sessione esistente della vittima. Il CSRF è una delle categorie più antiche del libro della sicurezza web, e le difese standard — token anti-falsificazione, richiesta di un gesto esplicito dell'utente per le azioni sensibili, non trattare i parametri GET come comandi — sono ben comprese. Ciò che rendeva pericoloso AgentForger non era la novità ma la leva. La richiesta forgiata non trasferiva denaro né modificava una e-mail; creava un attore autonomo imbullonato a connettori che l'utente aveva già approvato, così che non compariva mai una nuova schermata di consenso.
Questo è lo schema da interiorizzare. Quando una superficie di creazione di agenti accetta istruzioni da input non attendibile e le esegue, il contenuto del prompt diventa flusso di controllo. Il raggio d'azione è allora tutto ciò che l'agente può raggiungere, e i moderni agenti aziendali sono deliberatamente collegati a posta, chat, file e calendari per essere utili. Una falla che su una pagina di impostazioni sarebbe un CSRF di gravità media diventa un punto d'appoggio per un insider autonomo non appena l'oggetto che crea è un agente con accesso permanente.
Perché un « insider autonomo » è diverso
Togli le specificità di ChatGPT e un agente forgiato si comporta come un account dipendente compromesso — con due differenze che vanno contro il difensore. Primo, è paziente e automatizzato: gira a pianificazione, non ha bisogno di mani su una tastiera e può cercare file, raccogliere documenti, inviare messaggi come la vittima e mappare l'organizzazione senza mai far scattare un alert di anomalia di accesso, perché usa una sessione già fidata e connettori già approvati. Secondo, può riprodursi. Lo scenario di Zenity fa avviare all'agente forgiato del phishing interno che genera altri agenti compromessi, trasformando un clic in una popolazione di insider che si propaga.
Questo infrange alcune comode assunzioni. Il consenso dovrebbe essere il punto di controllo per l'accesso ai connettori, ma una singola approvazione data settimane prima qui bastava — l'agente la ereditava. Il monitoraggio è tarato su schemi umani, ma un agente che prende ordini da messaggi di posta con un oggetto innocuo non sembra esfiltrazione. E la governance delle identità di solito traccia utenti e account di servizio, mentre gli agenti spesso esistono in un punto cieco: nessuno possiede l'inventario di quali agenti esistono, chi li ha creati e cosa possono toccare. AgentForger è un'anteprima della classe del problema, non un caso isolato.
Cosa significa per i team software negli USA & in Italia
Il primo spostamento è concettuale: un agente IA è un'identità privilegiata, non una funzionalità dell'interfaccia. Se distribuisci agenti — siano essi di terze parti come questi o sistemi che costruisci — hanno bisogno dello stesso ciclo di vita che dai a un account di servizio: un proprietario, una voce d'inventario, permessi limitati, una pista di audit e un modo per revocarli in fretta. « Un agente può fare X » va letto come « un nuovo principal nel tuo ambiente può fare X », e va provvisto del minimo privilegio che gli consente comunque di lavorare. Le concessioni di connettori ampie e permanenti sono il moltiplicatore che ha trasformato un CSRF di routine in un problema a livello di dominio.
Il secondo spostamento è una regola architetturale ferma per chiunque costruisca superfici di agenti: non lasciare mai che un input non attendibile diventi un'istruzione eseguita, e non lasciare mai che un solo consenso autorizzi un'azione futura aperta. Mantieni un passaggio di approvazione umana su qualsiasi agente in grado di agire su dati o persone, richiedi una conferma esplicita di stessa origine prima che un agente sia pubblicato o gli venga concesso un connettore, e tratta i prompt che arrivano via link, documenti o e-mail come dati da isolare, non comandi da eseguire. Sono le stesse lezioni che l'industria continua a riapprendere — validazione degli input, token CSRF, minimo privilegio — ora applicate dove l'oggetto eseguito è un lavoratore autonomo.
Per i prodotti regolamentati il livello di governance non è opzionale. Nella FinTech e nella HealthTech, un agente collegato a caselle di posta e archivi documentali sta vicino a dati personali e finanziari, quindi uno forgiato è un potenziale incidente GDPR con i suoi tempi di notifica, non una curiosità da laboratorio. Per le entità finanziarie vigilate si aggiungono DORA e le aspettative sulla gestione del rischio informatico e dei fornitori terzi — un agente autonomo costruito su un servizio esterno rientra esattamente in quest'ambito. E secondo il Regolamento europeo sull'IA, un sistema automatizzato che compie azioni rilevanti su persone porta con sé obblighi di documentazione, sorveglianza umana e registrazione — « l'ha fatto un agente di terze parti in autonomia » non è una risposta che un auditor accetterà. Integra fin d'ora identità, permessi e sorveglianza degli agenti nel tuo SDLC sicuro e nel registro dei rischi fornitori, finché il numero di agenti è ancora abbastanza piccolo da inventariarlo a mano.
Cosa fare questa settimana
Una sequenza breve e pratica che trasforma la divulgazione in azione anziché in ansia:
- Inventaria i tuoi agenti. Elenca ogni agente IA operante nei tuoi tenant — agenti ChatGPT Workspace, agenti Copilot e quelli fatti in casa — con un proprietario, i suoi connettori e ciò che ciascuno può raggiungere. Non si può governare ciò che non si è contato.
- Limita i connettori al minimo privilegio. Sfoltisci le concessioni permanenti così che un agente tocchi solo le caselle di posta, i canali e i dischi di cui ha davvero bisogno, e non giri mai con l'accesso completo di un umano né con un'identità di deployment in produzione.
- Tieni un umano nel ciclo per le azioni. Richiedi un'approvazione esplicita prima che un agente invii, modifichi o condivida per conto di una persona, e prima che un nuovo agente sia pubblicato o gli venga concesso un connettore. Non lasciare che un consenso passato valga per azioni future.
- Strumenta per il comportamento degli agenti. Genera alert su agenti appena creati o modificati, su concessioni di connettori e su raffiche di attività dei connettori pianificate o automatizzate — i segnali che un agente forgiato produce — anziché affidarti alle sole anomalie di accesso umane.
- Irrobustisci le tue superfici di creazione di agenti. Se rilasci qualcosa che assembla o configura agenti, non eseguire mai automaticamente istruzioni da parametri dell'URL, aggiungi protezione anti-CSRF alle route che modificano lo stato e pretendi una conferma fresca, di stessa origine, prima che un agente entri in produzione.
Niente di tutto ciò è un argomento contro il costruire su agenti — il vantaggio di produttività è reale e la direzione è tracciata. Ma AgentForger è un segnale netto: nel momento in cui un agente può agire con l'accesso dei tuoi utenti, fa parte del tuo programma di sicurezza, non di una comodità che gli sta al di fuori.
Domande frequenti
Cos'è la vulnerabilità AgentForger?
AgentForger è una falla di cross-site request forgery (CSRF) che Zenity Labs ha rivelato nell'Agent Builder di ChatGPT. Un link malevolo trasportava un'istruzione in un parametro dell'URL (initial_assistant_prompt) che il Builder inviava ed eseguiva automaticamente al caricamento. Un clic di un utente autenticato con Workspace Agents e un'app collegata bastava a cablare i suoi connettori, spegnere le richieste di approvazione, pubblicare un nuovo agente e pianificarlo sotto il controllo dell'attaccante. OpenAI è stata avvisata il 4 giugno 2026 e l'ha corretta in pochi giorni.
AgentForger di ChatGPT è stato attivamente sfruttato?
Non ci sono prove pubbliche di sfruttamento in the wild. La falla è stata trovata e divulgata responsabilmente da Zenity Labs, segnalata a OpenAI il 4 giugno 2026, riconosciuta il 5 giugno e corretta in pochi giorni rimuovendo il parametro vulnerabile. La ricerca è stata pubblicata a fine luglio 2026 — quella pubblicazione è l'evento di cronaca; la correzione lo precede.
Come poteva un link distribuire un agente IA ostile?
Il Builder accettava parte del suo stato iniziale tramite parametri dell'URL, e il valore passato in initial_assistant_prompt veniva eseguito, non solo mostrato. Un link di phishing poteva istruire il Builder ad assemblare un agente dai connettori già autorizzati della vittima, disattivare il passaggio di approvazione umana, pubblicarlo e pianificarlo. Poiché la vittima era già autenticata e aveva approvato quei connettori, non compariva alcuna nuova richiesta di consenso.
Cosa poteva fare l'agente forgiato?
I ricercatori hanno descritto un insider autonomo. L'agente forgiato poteva raggiungere tutto ciò che i connettori della vittima consentivano — Outlook, Gmail, Slack, Teams, SharePoint, Google Drive — girava a pianificazione e prendeva ordini attraverso la casella di posta della vittima. Da lì poteva cercare ed esfiltrare file, raccogliere credenziali, impersonare il dipendente, mappare l'organizzazione e inviare phishing interno che generava altri agenti compromessi.
Cosa devono fare i team che costruiscono su agenti IA?
Tratta ogni agente come un'identità macchina nel tuo modello di minaccia. Mantieni un passaggio di approvazione umana su tutto ciò che può agire, limita i permessi dei connettori al minimo privilegio e non lasciare mai che un consenso copra azioni future aperte. Inventaria quali agenti esistono, chi li possiede e cosa possono raggiungere; genera alert su agenti nuovi o modificati e sull'attività automatizzata dei connettori. Sulle tue superfici, non eseguire mai automaticamente istruzioni da parametri dell'URL e richiedi una conferma esplicita di stessa origine prima che un agente entri in produzione.
Fonti
Zenity Labs — AgentForger, Part 1: ChatGPT Cross-Site Agent Forgery (ricerca primaria)
The Hacker News — ChatGPT AgentForger Flaw Could Deploy Rogue Workspace Agents via a Phishing Link, luglio 2026
The Register — One ChatGPT link could smuggle a rogue AI agent into your company, 23 luglio 2026
SecurityWeek — OpenAI Fixes ChatGPT Agent Flaw That Could Let Attackers Forge an AI Insider, luglio 2026