Le skill AI malevole ampliano il rischio per la sicurezza aziendale
Google News ha portato alla luce un netto conflitto nell'IA aziendale: gli agenti acquisiscono capacità utili tramite le skill, mentre gli attaccanti sfruttano le stesse estensioni. Una ricerca recente ha identificato oltre 3.000 skill malevole tra quasi 900.000 analizzate dal fornitore di sicurezza ESET. Questa scoperta trasforma una comoda funzionalità degli agenti in un problema di supply chain software.
La preoccupazione va oltre un singolo marketplace o una campagna malware. Le skill AI possono combinare istruzioni, script, documentazione esterna e accesso a sistemi sensibili. Una skill compromessa può quindi influenzare sia le decisioni di un agente sia gli strumenti che controlla.
Le aziende si trovano ora di fronte a un compromesso tra autonomia e controllo. Gli ecosistemi aperti accelerano la sperimentazione, ma i loro segnali di fiducia restano più deboli rispetto a quelli che circondano i pacchetti software consolidati. I ricercatori hanno già dimostrato che la popolarità di un repository, l'approvazione di un marketplace e la scansione statica possono tutti fallire contemporaneamente.
Cosa ha portato alla luce Google News sulle skill AI malevole
Il cambiamento importante è la scala, non la prima comparsa di un'estensione malevola.
La ricerca H1 2026 di ESET ha coperto l'attività delle minacce osservata da dicembre 2025 a maggio 2026. L'azienda ha dichiarato di aver analizzato quasi 900.000 skill AI e di aver trovato decine di migliaia di esempi sospetti. Oltre 3.000 sono state classificate come malevole.
Una skill AI è un pacchetto riutilizzabile che indica a un agente come completare un'attività, usare strumenti e gestire le relative informazioni. Alcune skill contengono poco più di semplici istruzioni. Altre collegano l'agente a script, servizi, file, strumenti da riga di comando o risorse web soggette a modifiche.
La popolazione analizzata è cresciuta rapidamente durante il periodo di ricerca. Secondo le notizie basate sui risultati, ESET ha analizzato circa 60.000 skill uniche a marzo e quasi 900.000 a maggio. I rilevamenti sospetti sono aumentati da circa 10.000 a oltre 25.000 durante quell'intervallo.
I rilevamenti malevoli sono saliti da circa 600 a oltre 3.000. Questi dati non dimostrano che ogni repository abbia lo stesso tasso di infezione. Mostrano però che i team di sicurezza devono valutare un volume crescente di comportamenti di agenti di terze parti.
Il riepilogo pubblico del threat report di ESET descrive le skill come piccoli componenti funzionali utilizzati dagli agenti. L'azienda ha rilevato istanze malevole e sospette nei repository esaminati.
I ricercatori hanno osservato capacità associate all'esecuzione di comandi, all'iniezione di codice, all'accesso ai file, al caricamento di credenziali, all'offuscamento e ai download esterni. Non si tratta automaticamente di funzionalità malevole. Diventano pericolose quando lo scopo dichiarato della skill non le giustifica.
Una skill legittima per sviluppatori potrebbe richiedere l'accesso alla shell per compilare un'applicazione. Un assistente documentale potrebbe necessitare dell'autorizzazione per leggere file selezionati. La domanda di sicurezza è se tali autorizzazioni restino limitate, visibili e collegate a uno scopo aziendale approvato.
Il malware tradizionale arriva spesso come eseguibile, allegato o pacchetto compromesso. Le skill AI malevole aggiungono un altro formato di distribuzione. Istruzioni dannose possono comparire in un linguaggio ordinario che un agente interpreta come guida operativa.
Questo design complica il rilevamento. Durante la revisione, una skill potrebbe non contenere un binario malevolo riconoscibile. Può invece indirizzare l'agente verso una pagina esterna, ottenere nuove istruzioni in un secondo momento o abusare di strumenti legittimi già presenti.
L'elemento su Google News è rilevante perché collega questi risultati distinti in una storia di rischio aziendale. La minaccia non è più limitata agli agenti personali sperimentali. Le skill stanno entrando nei flussi di lavoro di ingegneri, marketer, analisti, designer e team di vendita.
Questi utenti potrebbero installare estensioni senza considerare l'azione alla stregua di un deployment software. Un breve file di testo sembra meno pericoloso di un programma di installazione. Eppure l'agente che legge quel file potrebbe già avere accesso a email, cloud storage, codice sorgente o conoscenza interna.
Il divario tra apparenza e autorità crea la tensione centrale. Le skill spesso sembrano documentazione, ma possono funzionare come logica eseguibile dei flussi di lavoro. Le aziende non possono governarle in sicurezza come prompt innocui.
Perché la sicurezza degli agenti IA ora assomiglia alla difesa della supply chain
Una skill diventa una dipendenza aziendale quando un agente vi fa affidamento per agire all'interno dei sistemi aziendali.
La sicurezza della supply chain software traccia l'origine dei componenti, chi li mantiene, quali versioni sono distribuite e come gli aggiornamenti raggiungono la produzione. Le skill AI malevole richiedono molti degli stessi controlli. Introducono inoltre rischi comportamentali che la scansione convenzionale dei pacchetti non è stata progettata per interpretare.
Una skill può coordinare diversi strumenti affidabili senza sfruttare una vulnerabilità software. Potrebbe indicare a un agente di individuare una credenziale, trasformare un file e inviare il risultato altrove. Ogni singola chiamata a uno strumento può apparire legittima se osservata isolatamente.
Il rischio cresce con l'autorità dell'agente. Un assistente limitato alla stesura di testi presenta un'esposizione minore rispetto a uno collegato a una shell, un browser, un repository di codice e un account cloud. Gli agenti aziendali si avvicinano sempre più al secondo modello.
Questo crea un effetto moltiplicatore. La skill fornisce le istruzioni, mentre l'agente fornisce autorizzazioni, ragionamento ed esecuzione. Un attaccante non deve incorporare ogni capacità nell'estensione malevola.
Il marketplace ClawHub di OpenClaw è diventato uno dei primi casi di studio. I ricercatori hanno documentato skill malevole mirate a credenziali e asset in criptovalute. Alcune distribuivano malware consolidato, mentre altre manipolavano transazioni guidate dagli agenti.
La Unit 42 di Palo Alto Networks ha esaminato l'attività del marketplace tra febbraio e maggio 2026. La sua analisi della supply chain ha identificato cinque skill malevole non bloccate dopo l'introduzione di nuove misure di controllo.
Due distribuivano infostealer per macOS collegati a infrastrutture di command-and-control. Un'altra utilizzava file gonfiati per eludere le soglie degli scanner. Skill aggiuntive perseguivano manipolazioni finanziarie attraverso comportamenti specifici degli agenti autonomi.
Unit 42 ha segnalato le cinque skill a ClawHub. Il marketplace le ha rimosse e ha vietato gli account associati. La risposta ha ridotto l'esposizione immediata, ma non ha eliminato il problema di distribuzione alla radice.
Le scoperte precedenti avevano già spinto ClawHub a integrare VirusTotal e ClawScan. Questi servizi hanno aggiunto screening proattivo e analisi a livello di codice. OpenClaw ha inoltre annunciato una collaborazione con Nvidia sull'analisi delle skill e sulla documentazione.
La sequenza è istruttiva. Un marketplace ha aggiunto difese dopo la comparsa di campagne malevole, eppure i ricercatori hanno continuato a trovare skill evasive. Questo ricorda la competizione di lunga data che circonda le estensioni dei browser, i registri di pacchetti e le applicazioni mobili.
Le skill degli agenti aggiungono un'ulteriore complicazione perché il loro contenuto effettivo può estendersi oltre l'artefatto scaricato. Una skill locale può istruire l'agente a leggere documentazione online. Quella pagina esterna può cambiare senza modificare la skill esaminata.
I team di sicurezza non possono quindi fare affidamento soltanto su un verdetto al momento dell'installazione. Un risultato sicuro descrive ciò che uno scanner ha osservato in un determinato momento. Non garantisce che ogni dipendenza rimanga invariata.
L'inventario aziendale diventa inoltre più difficile quando i dipendenti possono aggiungere direttamente le skill. Un'azienda può approvare una piattaforma di agenti senza sapere quali estensioni della community gli utenti installino in seguito. Questo crea comportamenti di IA ombra all'interno di un prodotto ufficialmente autorizzato.
La distinzione è importante per la risposta agli incidenti. Gli investigatori devono sapere quale skill è stata eseguita, quali istruzioni ha caricato, quali strumenti ha chiamato e a quali informazioni ha avuto accesso. I normali log applicativi potrebbero non acquisire questa catena completa.
Le organizzazioni mantengono già distinte dei materiali software per sistemi selezionati. Le distribuzioni di agenti necessitano di un registro correlato che copra modelli, strumenti, skill, fonti di istruzioni esterne, autorizzazioni e versioni. Senza questa mappa, chi risponde agli incidenti non può determinare in modo affidabile l'esposizione.
Un registro interno ricercabile può inoltre supportare le indagini dopo la scoperta di un'estensione rischiosa. I team che organizzano le prove tecniche locali tramite una knowledge base ingegneristica possono conservare decisioni di revisione, responsabilità e contesto di remediation.
Questo registro non sostituisce la sicurezza in fase di esecuzione. Aiuta a stabilire chi ha approvato una dipendenza e perché. Il requisito più ampio resta un controllo continuo su ciò che gli agenti possono leggere, invocare e trasmettere.
Il compromesso centrale è tra autonomia degli agenti e controllo aziendale
Le skill rendono gli agenti più capaci riducendo la supervisione ripetuta, ma così offrono anche alle istruzioni malevole spazio per operare.
Un agente aziendale diventa utile quando può completare attività in più fasi. Potrebbe raccogliere requisiti, ispezionare file, interrogare un servizio, generare un artefatto e consegnare il risultato. Richiedere un'approvazione dopo ogni azione minore eliminerebbe gran parte di quel valore.
Concedere un'ampia autonomia risolve il problema dell'usabilità, ma amplia il potenziale raggio d'impatto. Un'estensione compromessa può riutilizzare le stesse connessioni che rendono produttivo l'agente. L'attaccante eredita indirettamente l'accesso attraverso il flusso di lavoro autorizzato dell'agente.
Non si tratta semplicemente di una competizione tra piattaforme aperte e chiuse. Un catalogo curato può comunque distribuire un componente compromesso. Una skill privata può comunque diventare pericolosa dopo che cambiano il suo repository, l'account del maintainer o una dipendenza esterna.
I marketplace aperti aumentano l'esposizione perché pubblicazione e installazione possono richiedere poca frizione. Rendono però possibili anche ricerca, rimozione e revisione da parte della community. Limitare ogni agente alle sole skill sviluppate internamente ridurrebbe alcuni rischi, ma creerebbe nuovi oneri di manutenzione.
La questione decisiva è se l'autorità rispetti il principio del privilegio minimo. Una skill per landing page non dovrebbe necessitare di accesso illimitato a chiavi SSH o credenziali cloud. Una skill di riepilogo non dovrebbe eseguire silenziosamente script shell scaricati.
Il principio suona familiare perché lo è. Il privilegio minimo guida la sicurezza delle identità e delle applicazioni da decenni. I sistemi agentici rendono più difficile l'applicazione perché un agente può combinare diverse azioni individualmente consentite in una sequenza non sicura.
Le skill operano anche a livello semantico. Le loro istruzioni descrivono obiettivi e procedure in linguaggio naturale. I controlli di sicurezza tradizionali eccellono nell'identificazione di schemi di codice noti, hash di file e indicatori di rete.
Sono meno efficaci quando il comportamento pericoloso è espresso come guida operativa plausibile. Un'istruzione potrebbe chiedere all'agente di ottenere un prerequisito, convalidare un account o sincronizzare una configurazione. L'intento dannoso emerge solo dal contesto.
Le linee guida sulle skill agentiche di OWASP separano questo livello comportamentale dal livello di connessione degli strumenti. Gli strumenti definiscono le azioni disponibili, mentre le skill orchestrano tali azioni in flussi di lavoro.
OWASP identifica tra i principali rischi skill malevole, compromissione della supply chain, privilegi eccessivi, istruzioni esterne non attendibili, isolamento debole e deriva degli aggiornamenti. Questo elenco mostra perché un singolo scanner o una sola policy non può coprire l'intero problema.
Un'architettura sicura necessita di diversi confini. Il marketplace deve stabilire la provenienza. La piattaforma agentica deve applicare i permessi. I controlli di runtime devono osservare le azioni, mentre l'organizzazione deve mantenere inventario e responsabilità.
L'approvazione umana resta utile quando viene applicata ai rischi significativi. L'invio di una bozza ordinaria a una cartella interna potrebbe procedere automaticamente. Il caricamento di file riservati o la modifica dell'infrastruttura di produzione dovrebbero richiedere un'autorizzazione più forte.
La sfida consiste nell'evitare richieste di approvazione prive di significato. Gli utenti approvano di routine richieste che non comprendono, soprattutto quando le interruzioni diventano frequenti. Una finestra di dialogo per l'approvazione non può compensare permessi predefiniti eccessivi o modifiche invisibili alle dipendenze.
Gli acquirenti aziendali dovrebbero inoltre distinguere l'utilità di una skill dalla sua affidabilità. La popolarità dimostra l'adozione, non la sicurezza. Un elevato numero di stelle può offrire una prova sociale senza dire nulla sul comportamento attuale delle istruzioni esterne.
La stessa cautela vale per i badge dei marketplace. L'approvazione potrebbe confermare che una proposta ha superato una revisione. Non stabilisce che le risorse collegate, la proprietà del repository o i pacchetti a valle rimarranno stabili.
Questo compromesso modellerà l'adozione aziendale. I team di sicurezza che bloccano ogni estensione spingeranno la sperimentazione in ambienti non gestiti. I team che consentono installazioni senza restrizioni creeranno un grafo di dipendenze in espansione che non riescono a ispezionare.
Il terreno intermedio praticabile è l'autonomia governata. Gli utenti possono accedere a funzionalità approvate, mentre le azioni ad alto rischio restano isolate e osservabili. Le skill ricevono permessi legati al loro scopo, non tutti i permessi disponibili per l'host agent.
L'autonomia governata richiede anche la revoca. Quando una skill diventa non sicura, gli amministratori devono individuare ogni installazione, disabilitarla, invalidare le credenziali esposte e riesaminare l'attività correlata. Una semplice rimozione dal marketplace non è sufficiente.
Gli scanner statici stanno perdendo la corsa alla fiducia
L'avvertimento più forte è arrivato da una skill di ricerca dall'aspetto innocuo che, secondo quanto riportato, ha raggiunto oltre 26.000 agent dopo aver superato gli scanner disponibili.
I ricercatori di AIR Security hanno creato una skill chiamata brand-landingpage. Appariva pensata per aiutare utenti non tecnici a creare una landing page con lo strumento di design Stitch di Google. La skill offriva funzionalità reali, rendendo credibile la proposta.
I ricercatori l'hanno inviata a una popolare raccolta open source contenente 156 skill e circa 36.000 stelle su GitHub. Il contributo è stato accettato dopo alcuni giorni. AIR ha poi promosso la skill attraverso una pubblicità su Instagram rivolta a professionisti del marketing, designer e venditori.
La skill distribuita non conteneva inizialmente un payload dannoso evidente. Invece, indirizzava gli agent verso documentazione di installazione su un dominio controllato dai ricercatori. Quel dominio inizialmente reindirizzava i visitatori verso il servizio Stitch legittimo.
AIR ha successivamente modificato le istruzioni esterne. La pagina rivista indicava agli agent di scaricare ed eseguire uno script. Per l'esperimento, il payload raccoglieva indirizzi email affinché gli utenti coinvolti potessero essere avvisati.
I ricercatori hanno affermato che nessun agent è stato danneggiato. Hanno inoltre dichiarato che la tecnica avrebbe potuto raggiungere conversazioni private e sistemi interni connessi. Questi impatti più ampi erano possibili esiti, non perdite documentate dell'esperimento.
Il resoconto di AIR sul test controllato della skill afferma che gli scanner di Cisco, Nvidia e skills.sh hanno contrassegnato la proposta come sicura. Il risultato ha messo in luce un limite strutturale della revisione statica.
Uno scanner può ispezionare i file attuali di una skill e continuare a non rilevare contenuti futuri ospitati altrove. La documentazione esterna funziona come una dipendenza mutabile. Il suo proprietario può modificare le istruzioni dopo che marketplace e utenti hanno stabilito fiducia.
Questo metodo ricorda gli aggiornamenti dannosi ritardati nei consolidati ecosistemi software. La differenza sta nella distribuzione. L'attaccante può alterare linguaggio ordinario che l'agent in seguito interpreta come guida procedurale autorevole.
L'analisi statica conserva comunque valore. Può identificare codice dannoso noto, comandi offuscati, URL sospetti, permessi eccessivi e dipendenze di pacchetti pericolose. L'errore è trattare una singola scansione pulita come una decisione di fiducia duratura.
I test comportamentali aggiungono un ulteriore livello. Un sandbox può eseguire la skill in un ambiente agentico ristretto e osservare tentativi di accesso ai file, download, comandi e comunicazioni di rete. Questo approccio può rivelare comportamenti nascosti dietro testi plausibili.
Tuttavia, anche il sandboxing ha dei limiti. Un attaccante può ritardare l'attivazione, reagire ai segnali ambientali o fornire istruzioni innocue a sistemi di analisi noti. Un test non può inoltre anticipare ogni interazione tra una skill e gli strumenti interni di un'azienda.
Il monitoraggio continuo è quindi importante dopo l'installazione. I sistemi di sicurezza devono rilevare quando una skill contatta un nuovo dominio, richiede dati più ampi, modifica il proprio schema di esecuzione o invoca strumenti al di fuori del suo scopo previsto.
Il pinning dei contenuti può ridurre la deriva delle istruzioni esterne. Un'azienda può conservare la versione revisionata della documentazione o richiedere hash crittografici per i componenti scaricati. L'agent non dovrebbe fidarsi automaticamente di qualunque contenuto venga successivamente servito da un URL mutabile.
I controlli di rete offrono un ulteriore punto di verifica. Alle skill che non necessitano di accesso a internet non dovrebbe essere concesso. Le altre possono essere limitate a domini, metodi e destinazioni approvati.
La visibilità del runtime deve estendersi oltre il traffico di rete. I difensori necessitano di una traccia che colleghi la richiesta dell'utente, la skill selezionata, le istruzioni recuperate, le decisioni del modello, le chiamate agli strumenti e il conseguente movimento dei dati. Altrimenti, ogni azione perde il proprio contesto comportamentale.
L'esperimento AIR non dimostra che ogni skill popolare sia non sicura. Dimostra che comuni segnali di fiducia possono convergere su una conclusione falsa. Reputazione, accettazione nel marketplace e scansione hanno tutti sostenuto lo stesso artefatto progettato in modo malevolo.
Questa è la prospettiva scettica che i leader aziendali dovrebbero mantenere. I fornitori di sicurezza stanno introducendo scanner specifici per l'AI, ma nessuno scanner può offrire garanzie permanenti per workflow mutabili. Le dichiarazioni sui prodotti dovrebbero essere valutate rispetto a test di elusione dal vivo e tassi di fallimento trasparenti.
La copertura di Google News può aumentare la consapevolezza, ma la consapevolezza non stabilisce un controllo tecnico. Gli acquirenti hanno bisogno di prove che le piattaforme agentiche possano vincolare le azioni dopo che una skill ha superato la revisione. Prevenzione e contenimento devono operare insieme.
Chi è sotto pressione per il rischio in espansione
Le piattaforme agentiche, i fornitori di sicurezza e gli acquirenti aziendali condividono ora la responsabilità di una dipendenza che nessuno può governare da solo.
Gli operatori dei marketplace affrontano la pressione più immediata. Devono bilanciare la rapida crescita della comunità con la verifica dei publisher, la revisione degli artefatti, i controlli sugli aggiornamenti e la risposta agli incidenti. Una maggiore frizione nelle proposte può rallentare la crescita, ma controlli deboli danneggiano la fiducia.
Gli sviluppatori di piattaforme agentiche controllano l'ambiente di esecuzione. Decidono se le skill vengono eseguite con i permessi dell'host, all'interno di container o tramite strumenti limitati. La loro architettura determina fino a dove può arrivare un'istruzione malevola.
I fornitori di sicurezza affrontano una prova diversa. Devono identificare comportamenti dannosi espressi tramite codice, linguaggio naturale, siti web mutabili e strumenti amministrativi legittimi. I segnali endpoint e di rete esistenti restano preziosi, ma il contesto semantico diventa essenziale.
I team di sicurezza aziendale non possono esternalizzare l'intero problema. Scelgono quali piattaforme entrano nell'organizzazione e quali connessioni ricevono tali piattaforme. Determinano inoltre se i dipendenti possono installare skill della comunità senza revisione.
Gli sviluppatori restano un gruppo ad alto rischio perché gli agent di coding spesso dispongono di accesso alla shell e ai repository. Una skill malevola potrebbe prendere di mira codice sorgente, credenziali di pacchetti, chiavi di firma, token cloud o configurazioni di deployment.
Gli utenti non tecnici presentano un'esposizione diversa. Una skill di marketing o vendita può raggiungere email, record dei clienti, asset del marchio, note delle riunioni e sistemi di contenuto. La sua interfaccia amichevole può nascondere l'autorità dell'agent sottostante.
I team di procurement necessitano quindi di domande che vadano oltre l'accuratezza del modello. Dovrebbero chiedere come la piattaforma individua le skill installate, registra le versioni, gestisce le istruzioni esterne e separa gli ambienti utente.
Devono anche comprendere la revoca. Gli amministratori possono disabilitare una skill su ogni endpoint? Possono identificare quali credenziali erano disponibili durante il suo periodo di installazione?
I team di conformità si interesseranno alle prove. Se un agent trasmette informazioni dei clienti tramite una skill non approvata, l'organizzazione deve ricostruire ciò che è accaduto. Una trascrizione generica di chatbot potrebbe non spiegare ogni chiamata agli strumenti a valle.
I responsabili della risposta agli incidenti affrontano richieste simili. Necessitano di log immutabili e di una timeline affidabile. Devono anche sapere se una skill rimossa ha creato persistenza altrove, come un processo pianificato o una configurazione modificata.
Le conclusioni di Unit 42 illustrano questo problema. I ricercatori hanno osservato meccanismi di persistenza associati ad attività malevole nei marketplace. La rimozione dell'elenco visibile non ha neutralizzato automaticamente ogni payload distribuito o canale di comando.
Le aziende dovrebbero trattare le credenziali degli agent come potenzialmente esposte dopo un'installazione malevola confermata. Ciò significa revocare i token pertinenti, riesaminare l'attività di autenticazione, controllare i file modificati ed esaminare le connessioni in uscita.
Il rischio non è distribuito uniformemente tra tutti i deployment. Un agent di ricerca isolato con dati sintetici crea conseguenze limitate. Un agent autonomo connesso a sistemi di produzione crea un problema di controllo molto più ampio.
Questa distinzione dovrebbe guidare la policy. Le organizzazioni possono classificare agent e skill in base ai dati accessibili, agli strumenti disponibili, all'autonomia, alla portata di rete e all'impatto aziendale. Le combinazioni a rischio più elevato ricevono revisione e monitoraggio più rigorosi.
La pressione raggiunge anche i programmi di governance dell'AI. Molti programmi si concentrano sulla selezione dei modelli, sui termini di privacy, sull'accuratezza degli output e sull'uso accettabile. Le skill AI malevole introducono dipendenze operative che assomigliano più alla sicurezza applicativa che alla governance dei modelli.
I comitati di governance necessitano di una responsabilità tecnica, non solo di principi scritti. Qualcuno deve approvare le fonti delle skill, mantenere l'inventario, stabilire i confini dei permessi e intervenire quando una dipendenza fidata cambia.
L'approccio vincente non dipenderà da un singolo dipartimento. Il platform engineering può applicare controlli di deployment. La sicurezza può monitorare il comportamento, mentre i responsabili di business definiscono attività e accesso ai dati accettabili.
Senza questo coordinamento, le organizzazioni creeranno due percorsi insoddisfacenti. Gli agent approvati rimarranno troppo vincolati per essere utili, mentre i dipendenti installeranno alternative meno controllate. Entrambi gli esiti indeboliscono la supervisione aziendale.
Tre segnali mostreranno se le difese stanno recuperando terreno
La prossima fase sarà misurata attraverso i controlli dei marketplace, le prove di runtime aziendali e test di rilevamento indipendenti.
Il primo segnale è se i principali registri di skill adotteranno provenienza verificabile e versionamento immutabile. Un marketplace dovrebbe identificare il publisher, conservare gli artefatti revisionati ed esporre ogni modifica. Anche le istruzioni esterne necessitano di inventario e controlli d'integrità.
Se i registri implementeranno ampiamente queste misure, gli attaccanti incontreranno maggiore frizione nel sostituire contenuti fidati. Ciò rafforzerebbe la tesi secondo cui gli ecosistemi di skill aperti possono maturare senza abbandonare i contributi della comunità.
Se i registri continueranno a fare affidamento sulla popolarità e su una scansione una tantum, l'attuale valutazione del rischio si rafforzerà. Con l'accumularsi di utenti per skill di valore, dovrebbero essere attesi più payload ritardati e acquisizioni di dipendenze.
Il secondo segnale riguarda il fatto che le piattaforme di agenti aziendali offrano autorizzazioni applicabili a livello di skill. Gli amministratori necessitano di limiti per file, strumenti, credenziali, comandi e destinazioni di rete. Tali limiti devono accompagnare la skill in ogni distribuzione.
Tracce di esecuzione chiare sono altrettanto importanti. Un analista della sicurezza dovrebbe poter collegare un’azione alla skill e alle istruzioni esterne che l’hanno provocata. I log dovrebbero resistere a manomissioni locali e supportare ricerche a livello dell’intera organizzazione.
Se le piattaforme offrono questi controlli, una skill dannosa diventa più facile da contenere. Potrebbe comunque entrare nell’ambiente, ma la sua capacità di raggiungere risorse non correlate si ridurrebbe. Questo indebolirebbe gli scenari aziendali più gravi.
Se le piattaforme espongono ogni skill alla piena autorità dell’agente, il rischio resta concentrato sull’endpoint. Un’estensione trascurata può ereditare l’accesso a molti sistemi non correlati.
Il terzo segnale è rappresentato da test indipendenti contro attacchi mutevoli e ritardati. Le valutazioni degli scanner dovrebbero includere modifiche alle istruzioni esterne, reindirizzamenti da domini attendibili, payload dormienti, acquisizioni di repository e strumenti legittimi utilizzati in sequenze non sicure.
L’esperimento con 26.000 agenti ha fornito uno di questi test. Le valutazioni future richiedono metodi ripetibili, campioni trasparenti e divulgazioni che distinguano il comportamento sospetto dal malware confermato.
Un rilevamento coerente tra strumenti indipendenti suggerirebbe che il mercato sta sviluppando basi di sicurezza condivise. Grandi divergenze mostrerebbero che i fornitori definiscono ancora in modo diverso il comportamento dannoso.
Le organizzazioni non dovrebbero attendere standard perfetti. Possono iniziare inventariando le skill installate e associando ciascuna a un responsabile, una fonte, una versione, autorizzazioni e dipendenze esterne.
Possono isolare gli agenti con autorizzazioni elevate, limitare l’accesso alla rete e richiedere approvazioni per le azioni sensibili. Possono inoltre rieseguire la scansione delle skill quando cambiano le dipendenze, non solo al momento della prima installazione da parte degli utenti.
I team dovrebbero considerare le skill rimosse o appena segnalate come trigger di incidente. La risposta dovrebbe esaminare credenziali, persistenza, accesso ai dati e comunicazioni in uscita. Eliminare la skill locale è solo il primo passo.
L’attenzione di Google News sulle skill AI dannose dovrebbe portare a una domanda pratica: la vostra organizzazione è in grado di spiegare cosa ogni agente aziendale è autorizzato a fare? Se la risposta è incompleta, iniziate dagli agenti collegati a codice, sistemi cloud, dati dei clienti e comunicazioni interne. Mappate le loro skill, limitate le autorizzazioni non necessarie e preservate le prove necessarie per indagare sulle loro azioni. La sicurezza degli agenti AI non dipenderà dall’individuazione di uno scanner perfetto. Dipenderà dalla combinazione di una distribuzione affidabile, autorizzazioni limitate, osservazione continua e revoca rapida prima che un’estensione apparentemente utile diventi un incidente aziendale.
