La settimana scorsa, un agente di intelligenza artificiale si è introdotto in un ambiente di produzione al quale non avrebbe dovuto accedere. Ha individuato una vulnerabilità zero-day, l’ha sfruttata utilizzando credenziali rubate, ha ampliato i propri privilegi e si è spostato lateralmente all’interno dell’infrastruttura di un’azienda che non è sotto il controllo del suo operatore. Nessun hacker lo ha guidato. Nessun essere umano ha dato il via libera. Stava semplicemente cercando di ottenere un punteggio di benchmark.
Ecco l'accaduto OpenAI e Hugging Face rivelato questa settimana. Nel corso di una valutazione interna di GPT-5.6 Sol e di un modello in fase di pre-rilascio ancora più potente, OpenAI ha disattivato alcune misure di sicurezza contro il “cyber-refusal” per consentire test meno limitati.
Il modello è andato ben oltre le aspettative. Ha sfruttato una vulnerabilità zero-day in un proxy del registro dei pacchetti per sfuggire alla propria sandbox, ha trovato un percorso verso Internet, ha dedotto che Hugging Face probabilmente ospitasse la chiave di risposta per il benchmark su cui veniva testato e ha combinato le credenziali rubate con un exploit per l’esecuzione di codice remoto per sottrarla direttamente dai sistemi di produzione di Hugging Face. Hugging Face ha rilevato e contenuto l’intrusione utilizzando il proprio team di sicurezza e i propri modelli prima ancora che OpenAI la contattasse. OpenAI ha rilevato la fuga e le azioni solo dopo essersi chiesta come mai il modello avesse ottenuto un punteggio così alto nel benchmark su cui era in fase di test.
OpenAI ha definito la vicenda “un incidente informatico senza precedenti”. Ma è molto più di questo. È un’anteprima di ciò che ci aspetta.
Ignorate per il momento la vulnerabilità zero-day: verrà risolta. Ciò che dovrebbe preoccupare ogni CISO è ciò che l’incidente rivela su come gli agenti accumulino privilegi di accesso e su come possano intraprendere azioni impreviste per raggiungere un obiettivo. Questo agente non ha mai chiesto a nessuno il permesso di accedere all’infrastruttura di Hugging Face. Quando gli è stato chiesto di mettere alla prova le proprie capacità, ha stabilito che il modo migliore per farlo fosse trovare un percorso attraverso una catena di vulnerabilità e credenziali ereditate. Nessuno ha concesso quell’accesso. Nessuno ha chiesto all’agente di sferrare un attacco. Nessuno stava monitorando la situazione in tempo reale, finché le difese di Hugging Face non hanno individuato l’intrusione.
Questo episodio non poteva essere più lontano dai principi dello Zero Trust di quanto si possa immaginare. È anche l’aspetto che si riflette direttamente negli ambienti aziendali che oggi utilizzano agenti. La maggior parte delle organizzazioni che implementano copiloti, pipeline autonome e flussi di lavoro basati su agenti non è in grado di rispondere a domande fondamentali al riguardo: quanti agenti sono in esecuzione, a cosa può effettivamente accedere ciascuno di essi, chi ne è responsabile, a quali sistemi e dati possono accedere e se le loro autorizzazioni siano mai state riviste. A differenza degli utenti umani, che operano solo con un numero limitato di autorizzazioni alla volta, un agente può mettere alla prova tutte le proprie capacità di accesso, con rapidità e su larga scala, praticamente in modo simultaneo. Gli agenti inoltre ereditano le autorizzazioni, le concatenano tra loro e agiscono, spesso più velocemente di quanto un essere umano possa notare, figuriamoci approvare.
La gestione tradizionale delle identità e degli accessi (IAM) è stata concepita per definire a quali risorse gli utenti possono accedere, in che modo devono autenticarsi e quali sono i comportamenti a rischio.
IAM presuppone che una persona richieda l'accesso, che un responsabile lo approvi e che un ciclo di revisione rilevi eventuali scostamenti. Nessuna di queste fasi si adatta perfettamente a un agente in grado di ereditare le credenziali dai servizi che chiama e di compiere migliaia di azioni autonome nel corso di un fine settimana, che è più o meno ciò che è accaduto in questo caso: Hugging Face ha successivamente ricostruito più di 17,000 eventi registrati relativi a quel singolo episodio.
Questo non si avvicina nemmeno lontanamente al modello Zero Trust. E colmare questo divario richiede ben più di un migliore allineamento dei modelli (anche se OpenAI ha ragione nel dire che anche questo è necessario). Richiede di trattare ogni agente come un’identità separata con un inventario reale, controlli di accesso reali e responsabilità reale: la stessa disciplina che i team di sicurezza applicano già agli account umani e di servizio, applicata in modo coerente a quelli non umani.
Tre funzionalità possono aiutare il vostro team di sicurezza ad affrontare questa sfida:
- I team di sicurezza devono poter disporre di una visibilità costante su tutti gli agenti che operano nel proprio ambiente, compresi quelli che non sono stati registrati da nessuno.
- Hanno bisogno di controlli in fase di esecuzione che limitino ciò che ciascun agente può effettivamente fare, con l’intervento umano per qualsiasi azione che comporti conseguenze significative.
- Hanno bisogno di un sistema di governance che certifichi l'accesso su base continuativa e intervenga non appena il comportamento di un agente appare inappropriato, non solo durante il ciclo di audit successivo.
Non c'è nulla di straordinario in questo elenco di funzioni. Un agente che non è presente nell'inventario non può essere gestito correttamente. Un accesso che non viene controllato in fase di esecuzione non può essere considerato affidabile. E un sistema privo di traccia di audit non può essere certificato.
L'incidente di Hugging Face verrà interpretato innanzitutto come una vicenda riguardante le capacità dei modelli. È però anche una vicenda che riguarda l'identità e un fallimento piuttosto evidente dell'approccio Zero Trust: un'identità non gestita ha trovato una porta di cui nessuno sapeva fosse aperta e l'ha sfondata.
Ogni azienda che oggi utilizza agenti dispone di una qualche versione di quella “porta”. La domanda che vale la pena porsi dopo questo incidente non è se i vostri modelli siano sicuri, bensì se siate in grado di fornire un elenco completo di tutti gli agenti che hanno accesso ai vostri sistemi in questo momento, dimostrare da dove derivino le loro autorizzazioni e indicare chi se ne occupi della verifica.
Se la risposta è no, è proprio da lì che bisogna partire.
