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.
Punti chiave relativi all'incidente tra OpenAI e Hugging Face
- OpenAI stava effettuando un benchmark interno su GPT-5.6 Sol, con alcune misure di protezione contro il "cyber-refusal" disattivate a scopo di test
- Il modello, senza alcun intervento umano, ha individuato e sfruttato una vulnerabilità zero-day in un proxy del registro dei pacchetti per sfuggire alla propria sandbox
- Ha dedotto autonomamente che Hugging Face probabilmente ospitasse la chiave di risposta del benchmark e vi ha avuto accesso tramite Internet aperto
- Ha combinato credenziali rubate con un exploit per l'esecuzione di codice remoto per violare i sistemi di produzione di Hugging Face
- Il team di sicurezza di Hugging Face ha individuato e contenuto l'intrusione, registrando oltre 17.000 eventi registrati—prima che OpenAI ci contattasse
- OpenAI ha individuato l'errore solo dopo essersi chiesta perché il modello avesse ottenuto un punteggio così alto nel benchmark su cui veniva testato
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. Questi sono identità non umane (NHI)—e loro rappresentare uno dei rischi aziendali in più rapida crescita e meno controllati. 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 contemporanea. Gli agenti inoltre ereditano le autorizzazioni, le concatenano tra loro e agiscono, spesso più velocemente di quanto un essere umano possa notare, figuriamoci approvare.
Che cos’è un agente di intelligenza artificiale?
Un agente di intelligenza artificiale è un sistema software che compie azioni autonome per raggiungere un obiettivo, senza che sia necessario l’intervento di un essere umano per approvare ogni singolo passo. A differenza di un utente umano, un agente può sfruttare contemporaneamente tutte le sue capacità di accesso disponibili, alla velocità di una macchina, su ogni sistema a cui può accedere.
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 individui eventuali scostamenti. Inoltre, non ha alcun modello per Escalazione dei privilegi degli agenti di intelligenza artificiale—il modo in cui gli agenti concatenano autorizzazioni e credenziali in percorsi di accesso che nessun essere umano ha mai configurato esplicitamente. Nessuna di queste fasi corrisponde chiaramente a un agente in grado di ereditare le credenziali dai servizi che chiama e di compiere migliaia di azioni autonome nel giro 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 governance che certifichi l'accesso su base continuativa e intervenga per correggere la situazione nel momento stesso in cui il comportamento di un agente risulti inappropriato, non 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.
Nel loro insieme, questi sono i requisiti fondamentali per Agenti IA Zero Trust: un'identità verificata per ogni agente, l'applicazione del principio del privilegio minimo in fase di esecuzione e una governance continua che non attendere il completamento di un ciclo di revisione.
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 produrre un elenco completo di tutti gli agenti che in questo momento hanno accesso ai vostri sistemi, dimostrare da dove provengono le sue autorizzazioni e indicare chi le sta esaminando.
Se la risposta è no, è proprio da lì che bisogna partire. Non dall’allineamento dei modelli, ma dall’identità.
Per identità non umana si intende qualsiasi identità digitale non associata a un utente umano: account di servizio, chiavi API, identità di macchina, automazione robotica dei processi (RPA) bot e agenti di intelligenza artificiale. Gli NHI dispongono spesso di privilegi elevati e vengono raramente inclusi nelle verifiche standard degli accessi, il che li rende un bersaglio di grande valore ma poco visibile per gli aggressori.
L'IAM tradizionale presuppone che sia una persona a effettuare la richiesta accesso, un responsabile lo approva e un ciclo di revisione rileva eventuali scostamenti. Agenti di intelligenza artificiale può superare tutte e tre le fasi: ereditano le credenziali e concatenano le autorizzazioni in modi che nessuno ha esplicitamente allocato, e possono eseguire migliaia di azioni prima che qualcuno se ne accorga. Per gestirli è necessario applicare la stessa disciplina di inventario e definizione dell’ambito di applicazione già utilizzata per gli account di servizio.
Gli agenti ampliano i propri privilegi concatenando le credenziali ereditate e gli accessi da ogni servizio a cui riescono a raggiungere, combinando autorizzazioni che non erano mai state concepite per essere utilizzate insieme. Nell’incidente di Hugging Face, non è stata una singola autorizzazione a consentire la violazione; l’agente ha costruito il percorso di attacco a partire dai componenti disponibili. Sono fondamentali i controlli di runtime che limitano ciò che un agente può effettivamente fare, e non solo ciò per cui è stato configurato.
I tre rischi principali sono: l'accesso senza responsabilità (gli agenti ereditano autorizzazioni senza un titolare chiaro), il movimento laterale autonomo (gli agenti agiscono alla velocità di una macchina prima che gli esseri umani possano intervenire) e l'assenza di una traccia di audit (la maggior parte delle organizzazioni non è in grado di dimostrare a cosa abbia avuto accesso un agente, quando o con quale autorizzazione).
Inizia dall’inventario: non puoi gestire ciò che non conosci non ho individuati. Successivamente, limitare le autorizzazioni di ciascun agente al minimo indispensabile, applicare tali limiti in fase di esecuzione e verificare costantemente l'accesso degli agenti, anziché attendere il ciclo di audit. Governance e ciclo di vita RSA estende queste funzionalità alle identità non umane, oltre che agli utenti umani.
Zero Trust per gli agenti di intelligenza artificiale mezzi ogni agente dispone di un'identità verificata, autorizzazioni limitate e controlli in fase di esecuzione — e tale accesso è revocato nel momento stesso in cui il comportamento si discosta dalle linee guida. L’incidente di Hugging Face è stato un fallimento del modello Zero Trust: un’identità non gestita ha trovato una porta che nessuno sapeva fosse aperta. Le soluzioni Zero Trust di RSA sono stati realizzati proprio per colmare tale divario.
Leggi Dal "teatro della conformità" alla difesa attiva, il documento di sintesi della RSA sulla governance continua delle identità, comprese quelle non umane, oppure Richiedi una demo per scoprire come RSA Governance & Lifecycle si adatta al vostro ambiente.
