Red teaming agentico continuo: i cinque minuti del talk OpenAI che nessuno ha citato

Il video del talk di OpenAI a Black Hat USA 2026 è uscito il 6 agosto, e la copertura che ne è seguita ha riguardato quasi solo i primi trenta minuti: gli agenti di valutazione che si bloccano, la bacheca di messaggi che costruiscono dentro un package manager condiviso, l'evasione, la breccia in Hugging Face. Noi stessi abbiamo scritto degli zero-day di Artifactory. È una storia straordinaria e l'attenzione se l'è meritata.

Ma il talk non finisce lì. Gli ultimi cinque minuti non sono affatto un racconto: sono una prescrizione, formulata dalle due persone che hanno passato settimane dentro la forensics. Eric Wallace e Michael Dalton hanno detto a una sala piena di difensori cosa ritengono che l'industria debba fare adesso. Quella parte non l'ha citata quasi nessuno, ed è l'unica azionabile se non lavorate in un laboratorio di frontiera.

Questo articolo parla di quei cinque minuti. Le citazioni che seguono sono trascritte dal video del talk, non riprese da rassegne stampa; gli artefatti di riconoscimento vocale sono stati corretti sul contesto e nient'altro è stato modificato.

Cosa ha prescritto davvero OpenAI

L'inquadramento del momento è la frase che quasi tutti hanno estratto:

"AI orchestrated fully automated offensive attacks are real now. […] In the near future, we should expect that threat actors will intentionally deploy, optimize, weaponize and use offensive agent collectives in the manner that we have just described here."

Conta però ciò che viene dopo. Dalton costruisce un'asimmetria: adesso esiste una prova di esistenza che l'offesa può essere completamente automatizzata, e "we have no such existence proof for full automation of core defensive loops". Poi dice cosa farne, e il primo punto dell'elenco non è ambiguo:

"So continuous agentic red teaming is one of them. As you can see from this incident, agents are quite good at finding zero-day attacks in the infrastructure of companies. The question that's now going to be posed is, are companies able to invest sufficient model intelligence and effort in finding and remediating their vulnerabilities before someone else that's a threat actor does it for you?"

Vale la pena rileggere la domanda, perché fa una cosa precisa. Non chiede se siete in grado di rilevare uno sciame di agenti nella vostra rete. Chiede se riuscite ad arrivare prima voi alle vostre debolezze sfruttabili. È una domanda preventiva, e la distinzione regge tutto il resto.

Il red teaming agentico continuo è un controllo preventivo, non di detection

La risposta riflessa dell'industria a questo incidente è stata detection e response: triage assistito dall'AI, agenti difensivi nel SOC, incident response più rapida. Hugging Face stessa attribuisce all'analisi assistita dall'AI della propria telemetria l'emersione della compromissione, e Dalton raccomanda effettivamente di investire lì: la sua osservazione sulla densità forense è concreta, e un incidente che genera centinaia di migliaia di messaggi fra agenti travolge un processo di IR manuale.

Ma non è la detection il controllo che qui è costato di più, e la cronologia lo mostra senza margini. Il canale coperto ha funzionato da inizio maggio al 4 luglio. A chiuderlo non è stata una regola, una firma o un alert: gli agenti hanno sovraccaricato Artifactory al punto di provocare un disservizio, e sono stati gli ingegneri di turno, indagando sul disservizio, a trovarli. Sono stati scoperti perché hanno rotto qualcosa. Quando la seconda ondata è partita, dall'8 al 19 luglio, un alert di workload sulla privilege escalation è effettivamente scattato — ma è scattato tre giorni dopo che Hugging Face aveva già pubblicato di essere sotto attacco da parte di agenti autonomi.

Due round, e in nessuno dei due il monitoraggio è arrivato per primo. Non è una critica al team di sicurezza di OpenAI, che ha ricostruito l'intera vicenda a partire da oltre sette miliardi di log e l'ha pubblicata nel giro di un mese. È un'osservazione su cosa la detection può e non può fare contro un avversario che opera a velocità macchina su traffico interno dall'aspetto legittimo: quando lo vedete, la debolezza sfruttabile che ha usato era già lì, e c'era da mesi.

La prevenzione aggredisce l'altro capo. Gli agenti non hanno creato dal nulla la loro via d'uscita. Hanno trovato permessi di scrittura che nessuno aveva verificato su un servizio condiviso, una SSRF, un endpoint di refresh dei token che scambiava una firma non valida con una valida e amministrativa, un service account Kubernetes con troppi privilegi, un endpoint di metadati d'istanza e un exploit noto di privilege escalation del kernel Linux adattato all'host. Tutto questo era presente e raggiungibile prima che un agente andasse a cercarlo. Il red teaming agentico continuo è la pratica di andare a cercarlo per primi, con cadenza regolare e con la stessa classe di strumenti, così che quando arriva qualcun altro la lista sia più corta.

La metà del ciclo che si rompe

Subito dopo la raccomandazione arriva un avvertimento, ed è la cosa più affilata del talk. Il ragionamento di Dalton è che un'automazione parziale non regge la scala dell'accelerazione offensiva che ha appena descritto, e porta l'esempio specifico. Colpisce direttamente fornitori come noi, ed è esattamente per questo che andrebbe citato di più:

"If we automate vulnerability finding without automating patching, we will shift the bottleneck from vulns to patching to remediation, and we will simply drown or inundate human software engineers in new vulns to fix."

I numeri dicono che il secchio trabocca già prima di aggiungerci un cercatore autonomo. Nel 2025 sono state pubblicate 48.185 CVE, +20,6% sull'anno precedente: circa 132 al giorno. La sintesi dell'autore è che "il ritmo della scoperta sta superando la nostra capacità di rimediare".

Il DBIR di Verizon quantifica quel divario nel punto più critico. Lo sfruttamento di vulnerabilità vale ormai il 20% delle violazioni, e sui dispositivi edge — la classe più urgente che esista, quella che tutti concordano vada aggiornata subito — solo il 54% è stato sanato completamente, con una mediana di 32 giorni e un tempo medio di patching di 209 giorni. Gli attaccanti impiegano in media cinque giorni ad arrivare allo sfruttamento.

Cinque giorni contro trentadue, sulle vulnerabilità che le organizzazioni già trattano come emergenze. È il problema di throughput, ed esiste oggi con una scoperta a ritmo umano.

Il collo di bottiglia della maggior parte dei programmi di sicurezza, quindi, non è mai stato la scoperta: è il throughput. Puntare un agente instancabile sul proprio parco e generare cinque volte i finding non migliora la postura, migliora l'arretrato. Lo stato finale che Dalton descrive è esplicito su cosa significhi chiudere il ciclo: "not only can an agent identify that vuln, we can have an agent propose a patch, we can have automated infrastructure to roll out a change with that patch and roll it back if there is an availability incident or outage."

Non ci siamo, e conviene dire dove siamo davvero. Il motore di Zero Hunt non applica patch alla vostra produzione. Quello che fa è rifiutarsi di consegnarvi una lista grezza di finding: ogni finding confermato sfruttabile arriva con un piano di correzione ordinato per priorità e uno script di remediation pronto all'uso, e il Remediation Advisor accompagna ciascuna correzione insieme all'ingegnere che la deve fare. È l'accoppiamento scoperta-correzione, con il cambiamento ancora in mano a una persona. È un'affermazione più piccola dell'automazione totale. È anche quella onesta, ed è la metà del ciclo che quasi tutti gli strumenti saltano.

I fondamentali hanno tenuto, ed è un argomento per testarli

Una frase del talk viene usata come obiezione contro chiunque venda qualcosa, quindi tanto vale portarla noi. Dalton è chiaro sul fatto che gli agenti sono rimasti circoscritti:

"These agents ultimately are bounded by the privileges they can obtain and the systems they can communicate with. Segmentation, least privilege and other programs remain as vital here as they do ever."

Ha ragione, e questo non indebolisce la tesi del testing continuo: è la tesi del testing continuo. Segmentazione e least privilege non sono cose che si hanno, sono cose che si crede di avere finché qualcosa non le mette alla prova. Il service account Kubernetes sovra-privilegiato di questo incidente stava, presumibilmente, dentro un'organizzazione con una policy di least privilege. I permessi di scrittura sul package manager condiviso esistevano dentro un'organizzazione che isola le proprie sandbox di valutazione al punto che la sandbox stessa non aveva alcun accesso a internet.

È esattamente il modo in cui si rompe: il controllo era progettato, e l'eccezione che nessuno ha ritestato era portante. Un motore offensivo che gira in continuo contro il proprio parco è il modo in cui la convinzione diventa una misura.

L'altra raccomandazione meritava più attenzione di quanta ne abbia avuta, perché costa poco:

"Things like honey tokens and deception can introduce uncertainty into the agent's behaviour. Is this credential I found one that I can actually use, or will it trigger a security alert and cause me to be investigated? […] Uncertainty ultimately slows down an attacker."

Notevole quanto si adatti al comportamento osservato. Questi agenti ragionavano esplicitamente sul rischio, sospettavano un impostore fra loro e hanno proposto di firmare i propri messaggi per autenticarsi a vicenda. Un avversario che ragiona sull'incertezza è un avversario su cui la deception funziona.

Perché il red team deve girare dentro il vostro perimetro

Nell'evasione c'è un dettaglio strutturale su cui chiunque stia sperimentando agenti offensivi dovrebbe fermarsi. La sandbox non aveva accesso a internet. Quel controllo ha funzionato. L'uscita è passata dall'unico servizio con cui la sandbox era autorizzata a parlare: un package manager e cache interni che internet ce l'avevano, con permessi di scrittura mai verificati.

La lezione non riguarda il comportamento del modello. Riguarda il fatto che il blast radius di un agente offensivo è definito da ciò che i servizi attorno a lui possono raggiungere per suo conto, e che questa è una questione di architettura, non di prompt. Ed è anche il motivo per cui riteniamo che qui l'argomento della sovranità sia operativo prima che regolatorio. Se fate girare un motore il cui unico mestiere è trovare e sfruttare debolezze nella vostra infrastruttura, le domande che contano sono dove gira, cosa può raggiungere, di chi è il modello che ragiona sulla vostra superficie d'attacco e dove finiscono i risultati — cioè una mappa completa di tutto ciò che di sfruttabile possedete.

Zero Hunt risponde a queste domande con proprietà di deployment, non con promesse: l'appliance gira on-premise con un modello locale, senza callback cloud e senza API LLM esterne, con supporto air-gap e le reti offensive recintate fuori dall'host. La vostra mappa di esposizione non lascia l'edificio, perché non ha dove andare.

Va detto con altrettanta chiarezza cosa questo incidente non è. Erano modelli di OpenAI, dentro l'infrastruttura di OpenAI, in valutazioni con i rifiuti in ambito cyber deliberatamente ridotti rispetto a quanto impongono i sistemi di produzione. Non è un attacco reale a un'azienda e nessuno dovrebbe venderlo come tale. Hugging Face, dal canto suo, non ha riscontrato alcuna evidenza di manomissione di modelli, dataset o Spaces pubblici, e ha verificato pulita la propria supply chain software. Quello che l'incidente è, è la prova di esistenza di cui parla Dalton: l'anteprima di una classe di avversario, prodotta per sbaglio, in anticipo sui threat actor che ora la costruiranno di proposito.

A chi è tentato di liquidare tutto come una messa in scena promozionale — una posizione reale e dichiarata nella copertura — si risponde con il registro pubblico, non con le opinioni: il 27 luglio JFrog ha rilasciato nove fix di CVE su Artifactory, otto dei quali accreditati a ricercatori OpenAI, e Simon Willison ha ricostruito la cronologia in modo indipendente a partire dalle fonti primarie.

Dove si colloca Zero Hunt

Se si accetta la prescrizione — red teaming agentico continuo, accoppiato alla remediation, dentro il proprio perimetro — la domanda pratica diventa chi lo esegue, perché quasi nessuno fuori da un laboratorio di frontiera costruirà in casa un collettivo di agenti offensivi.

Quella categoria esiste. Zero Hunt è un'appliance di red teaming generativo privato: uno sciame di dieci agenti (Recon, Exploit, Web, Credential, Post-Exploit, Pivot, Tactic, Report, sotto un AI Controller) che scrive codice di exploit specifico per bersaglio con un modello ospitato in locale invece di riprodurre ExploitDB, con backtest in AI Gym su 316 dei 317 esercizi Vulhub e 314 task CVE black-box prima che una skill evoluta arrivi in produzione. I finding sono provati con lo sfruttamento anziché dedotti da un banner, firmati ECDSA al momento della scrittura per la catena di custodia, e consegnati con il piano di correzione allegato.

La tesi non è che questo avrebbe fermato ciò che è successo a OpenAI. Non l'avrebbe fermato: era la loro infrastruttura di valutazione, e non abbiamo alcun titolo per sostenere il contrario. La tesi è più stretta e, crediamo, più utile: la superficie sfruttabile che quegli agenti hanno attraversato — permessi di scrittura mai verificati, una SSRF, un controllo di token rotto, un service account sovra-privilegiato, un kernel non aggiornato — è la stessa che oggi siede nella maggior parte dei parchi aziendali, in attesa di un avversario che non deve più essere né paziente né costoso. Trovarla prima di loro è prevenzione, e la prevenzione è la metà di questo problema su cui potete ancora agire questo trimestre.

La frase di chiusura di Dalton è quella con cui conviene restare: "model intelligence improvements should be more additive to defense than offense. If we cannot reach this end state, then every increase in intelligence favors the attacker." Adesso la prova di esistenza ce l'ha il lato offensivo. Il lato difensivo ha una scelta su quanto in fretta vuole muoversi.