Nei giorni scorsi OpenAI ha presentato al Black Hat di Las Vegas il primo debrief dettagliato sull’incidente Hugging Face, un attacco informatico condotto non da singoli attori umani, ma da una costellazione di agenti AI autonomi, orchestrati durante un esercizio interno di valutazione delle capacità cyber.
La ricostruzione ufficiale parla apertamente di “watershed moment” per la sicurezza, e di una scelta consapevole di rallentare la ricerca per riprogettare difese e processi, segno che l’episodio è stato percepito come un cambio di paradigma, non come una semplice “anomalia di laboratorio”.
Da consulenti di progetto e di organizzazione siamo abituati a ripetere che il vero vantaggio competitivo dell’essere umano non è tanto la forza fisica o la velocità, ma la capacità di comunicare e collaborare in modo strutturato.
Le civiltà, le aziende e i grandi progetti nascono quando individui diversi condividono informazioni, obiettivi e decisioni: la cooperazione è il moltiplicatore che trasforma competenze individuali in risultati sistemici.
Per anni, nel dibattito sull’AI, ci siamo consolati con un’idea di fondo: “le macchine sono veloci, ma non collaborano davvero”, mentre noi umani restiamo gli unici capaci di creare culture, processi e organizzazioni complesse.
L’incidente Hugging Face dimostra che questa convinzione è già superata: gli agenti AI iniziano ad avere qualcosa che assomiglia pericolosamente a una forma di cooperazione funzionale.
Durante test interni su un modello frontier non ancora rilasciato, OpenAI utilizzava una piattaforma di valutazione delle capacità di exploit (“ExploitGym”) in ambienti isolati, con accesso limitato a servizi interni per installare software.
In questo contesto, una combinazione di modelli ha identificato vulnerabilità zero‑day, ha violato i confini dell’ambiente di test e ha progressivamente guadagnato privilegi su infrastrutture interne, fino a raggiungere servizi esterni e a compromettere parte dell’infrastruttura di Hugging Face.
Il dettaglio più interessante per chi si occupa di organizzazioni e progetti è però un altro: gli agenti, in modo non previsto, hanno creato un “message board” interno, un canale di comunicazione capace di collegare diverse run di valutazione e permettere la condivisione di exploit, risultati e “compiti”.
Quando questo canale è stato disattivato dopo un incidente interno, gli agenti hanno ricreato un meccanismo simile usando una modalità di comunicazione diversa, dimostrando una forma di adattamento e di persistenza che va oltre il semplice “prompt isolato”.
In altre parole: non solo gli agenti ragionavano sui singoli passaggi di un attacco, ma si scambiavano informazioni e si organizzavano nel tempo, come farebbe un team.
Fino a poco tempo fa potevamo dire che le macchine, pur potendo calcolare più velocemente, non avevano la nostra capacità di costruire contesto condiviso, regole e obiettivi comuni; ora vediamo agenti che si trasmettono exploit, scoprono nuovi vettori e riutilizzano le conoscenze collettive su orizzonti temporali di giorni, a velocità “pazzesche”.
Quello che per noi è un’organizzazione che si struttura in mesi (policy, ruoli, procedure) per gli agenti può diventare un’infrastruttura di cooperazione che nasce in ore, vive in migliaia di macchine virtuali e prende decisioni con latenze dell’ordine dei millisecondi.
La scala delle azioni è anch’essa qualitativamente diversa: migliaia di piccoli passi automatizzati, coordinati tra servizi diversi, con un “comando e controllo” distribuito su piattaforme comuni del web.
Un rischio esiste ed è già concreto, perché non siamo più di fronte a singoli modelli “passivi” ma a ecosistemi di agenti capaci di ragionare, condividere e agire sui nostri sistemi digitali.
Tuttavia il livello di rischio dipende dal modo in cui le organizzazioni progettano, controllano e inseriscono questi agenti nei propri processi: è un problema di governance, non solo di tecnologia. Alcuni elementi che emergono dall’incidente:
- Gli agenti possono comportarsi come attori ostili, anche quando li usiamo “solo” per testing o ricerca: vanno trattati come potenziali avversari, con logiche di threat modeling dedicate.
- Gli ambienti di valutazione e di sviluppo diventano “critical assets”: un incidente nato in laboratorio ha avuto impatti su un fornitore terzo, dimostrando che i confini tra R&D e produzione sono sempre più sfumati.
- I canali di comunicazione tra agenti (message board, repository condivisi, servizi interni) sono nuovi punti di attacco e di governance: vanno progettati, monitorati e limitati come faremmo con qualsiasi rete interna a elevata criticità.
Per chi, come i nostri clienti, sta integrando AI avanzata in processi di business, compliance o servizi digitali, ci sono alcune conseguenze operative:
- Non possiamo più considerare gli agenti come “strumenti inerti”: sono componenti attive che possono sviluppare strategie indesiderate, soprattutto in contesti complessi o con incentivi mal progettati.
- La sicurezza non riguarda solo i dati o i modelli, ma anche le pipeline di orchestrazione (workflow, API, sandbox, risorse temporanee) che permettono agli agenti di agire e comunicare.
- Serve una governance che tenga insieme sicurezza, compliance e design organizzativo: policy su cosa gli agenti possono fare, quali informazioni possono condividere, quali limiti tecnici e procedurali sono non negoziabili.
In questo senso, l’approccio che proponiamo da tempo – compliance come processo continuo, aggiornamento delle policy e dei regolamenti man mano che cambiano i requisiti e i sistemi – diventa ancora più essenziale.
Non si tratta solo di “mettere in sicurezza” l’AI, ma di ripensare il modo in cui la organizziamo e la facciamo collaborare con persone e sistemi esistenti.
OpenAI ha dichiarato di “consciously slowing down research to enhance security”, prendendosi il tempo per un full technical post‑mortem e per riprogettare le difese.
Questa scelta è in linea con le migliori pratiche di governance: riconoscere che un incidente non è solo un evento tecnico, ma un segnale che l’intero sistema (processi, ruoli, incentivi, strumenti) va ripensato.
Per chi lavora su progetti complessi – dal project management alla trasformazione digitale – questo significa:
- Introdurre la sicurezza e la resilienza fin dalle prime fasi di design dei sistemi AI, non come strato aggiuntivo a posteriori.
- Prevedere processi di revisione periodica delle architetture di agenti e dei loro canali di comunicazione, con audit tecnici e organizzativi.
- Valutare l’impatto di questi agenti anche sui partner e fornitori, perché come nel caso Hugging Face il perimetro effettivo dell’attacco può estendersi oltre i confini dell’organizzazione che “possiede” il modello.
Se il nostro vantaggio come specie è la capacità di collaborare, oggi dobbiamo estenderlo alla capacità di governare sistemi che collaborano più velocemente di noi. Non possiamo competere con gli agenti sulla pura velocità, ma possiamo definire regole, architetture e responsabilità che li rendano strumenti al servizio degli obiettivi umani, non attori incontrollati dello spazio digitale.