Un’azienda di sicurezza ha dimostrato che una piccola applicazione per AI, modificabile tramite un link esterno dopo l’approvazione, è riuscita a superare i sistemi di scansione di sicurezza dei maggiori fornitori.
[In pillole] La sintesi per chi va di fretta:
La società di sicurezza AIR ha dimostrato una grave vulnerabilità nei sistemi di controllo per agenti di intelligenza artificiale. Creando una skill apparentemente innocua, è riuscita a superare le scansioni di sicurezza e a raggiungere 26.000 agenti. L'esperimento ha rivelato come un link esterno, modificabile dopo l'approvazione, possa essere usato per introdurre comportamenti dannosi, aggirando le protezioni esistenti.
La falla di sicurezza che ha messo a rischio 26.000 intelligenze artificiali
Una società di sicurezza informatica, AIR, ha recentemente condotto un esperimento tanto silenzioso quanto significativo, dimostrando una vulnerabilità fondamentale nel modo in cui vengono controllate le estensioni per gli agenti di intelligenza artificiale.
L’azienda ha creato un’abilità (in gergo tecnico, skill), ovvero una sorta di piccola applicazione che estende le capacità di un agente AI, completamente innocua in apparenza. Questa abilità è stata poi sottoposta ai sistemi di scansione di sicurezza di alcuni dei più grandi fornitori del settore, superandoli senza difficoltà.
Una volta approvata, è stata resa disponibile e, secondo quanto riportato, installata su circa 26.000 agenti AI, prima che AIR stessa rivelasse la natura del suo test.
L’esperimento, la cui notizia è stata diffusa inizialmente da The Hacker News, ha messo in luce come un semplice link esterno, modificabile dopo l’approvazione, possa essere utilizzato per introdurre comportamenti potenzialmente dannosi, aggirando di fatto le protezioni esistenti.
Non si è trattato di un attacco reale, ma di una dimostrazione controllata pensata per esporre un punto debole che riguarda l’intera architettura di sicurezza di queste nuove tecnologie.
Il fatto che un singolo componente, apparentemente benigno, abbia potuto raggiungere una diffusione così ampia prima di essere segnalato, solleva interrogativi importanti sulla reale efficacia dei processi di verifica attuali, anche quando gestiti da colossi della tecnologia.
Un esperimento controllato che sembrava un attacco reale
Il metodo utilizzato da AIR è stato ingegnosamente semplice. Il team ha sviluppato un’abilità per agenti AI che, al momento della sottomissione per il controllo di sicurezza, non conteneva alcun codice sospetto. Non c’erano righe di programma che potessero attivare un allarme nei sistemi di scansione, né manuali né automatici. La sua innocuità era, a un primo esame, totale.
La chiave dell’intero esperimento non risiedeva nel codice interno dell’abilità, ma in un riferimento a un link esterno. Al momento del controllo, questo link portava a una risorsa web del tutto innocua, un contenuto che non avrebbe destato alcun sospetto.
Le piattaforme di sicurezza, incluse quelle di giganti come Cisco e NVIDIA, hanno analizzato l’abilità, verificato il link e, non trovando nulla di malevolo, hanno dato il loro via libera. L’abilità è stata così pubblicata e resa disponibile per l’installazione.
È a questo punto che la vulnerabilità si è manifestata in tutta la sua evidenza: una volta ottenuta l’approvazione, AIR ha modificato la risorsa a cui puntava il link. Sebbene l’abilità installata sugli agenti AI rimanesse formalmente identica a quella approvata, il suo comportamento poteva ora essere alterato a distanza, semplicemente cambiando il contenuto servito dall’URL esterno.
– Leggi anche: GLM 5.2: il modello AI cinese open weight che sfida la Silicon Valley
Questo meccanismo ha permesso all’abilità di superare ogni controllo e raggiungere una vasta platea di agenti, esponendo un difetto strutturale nel processo di verifica: la sicurezza viene valutata in un singolo momento, ma il comportamento di questi sistemi può evolvere nel tempo.
La questione che emerge è se i sistemi di controllo attuali siano veramente adatti a un mondo in cui i componenti software sono sempre più interconnessi e dipendenti da risorse esterne e dinamiche.
L’esperimento di AIR suggerisce che l’approccio basato su un’analisi statica e puntuale potrebbe non essere più sufficiente, lasciando aperte porte che attori malintenzionati potrebbero facilmente sfruttare.
Il punto debole dei sistemi di controllo
La dimostrazione di AIR ha illuminato quello che la testata tecnologica The Next Web ha definito “un punto cieco” nelle procedure di verifica delle abilità per agenti AI. Le aziende che forniscono i sistemi di scansione si concentrano principalmente sull’analisi statica del codice e della configurazione inviati.
In altre parole, esaminano il pacchetto così come viene presentato, ma non sembrano avere un controllo continuo e a lungo termine sulle risorse esterne a cui quel pacchetto può fare riferimento.
L’approccio di AIR non ha richiesto lo sfruttamento di vulnerabilità sconosciute o complesse tecniche di hacking; si è limitato a sfruttare la fiducia che il sistema ripone in un link esterno dopo averlo controllato una sola volta.
Le reazioni della comunità di esperti non si sono fatte attendere. Il Cybersecurity Center della Western Illinois University, ad esempio, ha riassunto il caso come un esempio ammonitore per le organizzazioni che stanno integrando agenti AI nei loro processi produttivi.
Il blog specializzato SpoofGuard, invece, ha descritto l’incidente come la prova che migliaia di agenti AI erano a rischio perché la piattaforma permetteva a un’abilità di fare riferimento a domini esterni il cui comportamento poteva cambiare dopo l’approvazione.
Il blog ha evidenziato una somiglianza con le tecniche di phishing, in cui un link o un dominio inizialmente sicuro viene poi “armato” con contenuti dannosi solo dopo che si è instaurato un rapporto di fiducia.
In un contesto di intelligenza artificiale, dove gli agenti sono programmati per seguire link ed eseguire istruzioni in autonomia, le implicazioni sono significative.
Un’abilità che sembrava sicura potrebbe trasformarsi in un canale per il furto di dati o per la manipolazione di processi aziendali, senza che la piattaforma o l’utente se ne accorgano.
La discussione si è estesa rapidamente anche su social media professionali, con account come The Cyber Security Hub su X (ex Twitter) che hanno condiviso la notizia, attirando l’attenzione sui rischi legati alla catena di approvvigionamento del software AI.
Sembra esserci un consenso crescente sul fatto che le piattaforme di agenti AI stiano, in una certa misura, ripetendo un errore di sicurezza già visto in passato: trattare la revisione statica e una tantum come una garanzia sufficiente in un ambiente intrinsecamente dinamico.
Un vecchio problema con una nuova forma
Ciò che l’esperimento di AIR ha messo in luce non è, in fondo, un problema completamente nuovo. Ricorda da vicino gli attacchi alla catena di approvvigionamento (supply-chain attack) che hanno già afflitto altri settori del software.
Casi simili si sono verificati in passato negli store di applicazioni per smartphone, nei repository di estensioni per browser e nei gestori di pacchetti software: un’applicazione o un componente viene approvato perché innocuo, guadagna la fiducia e la diffusione tra gli utenti, e solo in un secondo momento viene aggiornato per includere funzionalità malevole.
La differenza, nel caso degli agenti AI, è più sottile e forse più insidiosa.
L’aggiornamento malevolo non avviene tramite una nuova versione dell’abilità stessa, che richiederebbe un’ulteriore revisione, ma attraverso la modifica di una risorsa esterna, un’operazione che avviene al di fuori del perimetro di controllo della piattaforma.
Gli agenti AI sono progettati proprio per interagire con il web e con le API esterne; fa parte della loro natura. Questo significa che il web esterno agisce, di fatto, come un’estensione non regolamentata della loro base di codice. I processi di verifica attuali, tuttavia, sembrano concentrarsi quasi esclusivamente su ciò che è contenuto all’interno del pacchetto al momento della presentazione.
Questo crea un rischio notevole per le aziende che si affidano a “store” di agenti o a mercati di terze parti per ampliare le funzionalità dei loro sistemi. Anche se una piattaforma applica standard di revisione molto rigorosi, qualsiasi abilità che possa caricare istruzioni dall’esterno reintroduce un elemento di incertezza e di codice non verificato.
L’implicazione diretta è che i modelli di sicurezza basati unicamente su scansioni statiche non sono adeguati a garantire la sicurezza di sistemi così dinamici.
Le piattaforme dovranno probabilmente considerare approcci più complessi, come il monitoraggio continuo del traffico generato dagli agenti e dei contenuti recuperati da domini esterni, o l’imposizione di restrizioni più severe sull’uso di URL esterni.
Per le organizzazioni che implementano agenti AI, il caso di AIR serve da promemoria: le abilità di terze parti devono essere trattate con la stessa cautela di qualsiasi altro software che abbia accesso a dati e processi sensibili. Per queste ragioni molte aziende preferiscono software su misura sviluppati internamente, dove ogni componente è verificabile e non dipende da risorse esterne non controllate.
Il fatto che una singola abilità fittizia abbia superato i controlli di importanti fornitori di sicurezza per raggiungere potenzialmente 26.000 agenti suggerisce che la fiducia riposta nei processi di revisione delle piattaforme potrebbe essere eccessiva.
La dimostrazione di AIR, in definitiva, ha rappresentato uno dei primi test reali sulla resilienza degli ambienti AI agli attacchi alla catena di approvvigionamento. La risposta delle piattaforme a questa evidenza determinerà quanto saranno esposti i futuri agenti AI al tipo di vulnerabilità che questa finta abilità ha illustrato con tanta efficacia.
