Gli agenti AI ombra rappresentano un rischio invisibile per le imprese

Google News ha portato alla luce un avvertimento di Dark Reading sugli agenti AI ombra, mentre le imprese affrontano un conflitto preoccupante: l'adozione accelera, ma la visibilità resta incompleta.

La preoccupazione va oltre i dipendenti che incollano testo riservato in un chatbot non approvato. Gli agenti autonomi possono ricevere credenziali, connettersi ai sistemi aziendali, conservare il contesto e compiere azioni senza richiedere approvazione a ogni passaggio.

Questo cambia il principale terreno di confronto nella sicurezza. Le imprese non stanno più bilanciando la produttività con la normale governance del software. Stanno bilanciando l'azione autonoma con controlli progettati per utenti umani e applicazioni prevedibili.

Dark Reading ha documentato come i sistemi agentici possano raggiungere gli ambienti di produzione con credenziali estese e deboli controlli di conferma. In un incidente segnalato che ha coinvolto un agente di coding, un database di produzione e i relativi backup a livello di volume sono stati cancellati in pochi secondi. La conclusione più ampia della testata è più importante del singolo guasto: un agente con accesso eccessivo può trasformare un errore ordinario in un evento operativo immediato.

L'avvertimento arriva inoltre nel contesto del rapido sviluppo di prodotti da parte di Microsoft, Google, Amazon, Nvidia e numerosi fornitori di sicurezza. Ogni azienda vuole entrare a far parte dello stack di agenti aziendale. Eppure ogni nuovo framework, connettore e identità delegata offre ai team di sicurezza un'altra relazione da individuare e governare.

L'inversione centrale è scomoda. Gli agenti AI promettono di ridurre il lavoro manuale, ma governarli crea una nuova categoria di lavoro continuo. I team di sicurezza devono identificare ogni agente, comprenderne lo scopo, mappare i suoi accessi, monitorarne le azioni e ritirarlo in sicurezza.

Google News mette in evidenza il problema degli agenti ombra

L'ultimo avvertimento è importante perché l'AI ombra è passata dalle conversazioni non autorizzate alle azioni non autorizzate.

Google News funge qui da canale di scoperta, mentre la copertura sottostante di Dark Reading riflette un cambiamento più ampio nella ricerca sulla sicurezza aziendale. Dipendenti e sviluppatori stanno distribuendo agenti tramite strumenti locali, piattaforme cloud, estensioni software e progetti di automazione interni.

Un agente AI è un software che usa un modello per perseguire un obiettivo attraverso più passaggi. Può selezionare strumenti, recuperare informazioni, chiamare API e modificare sistemi con una supervisione diretta inferiore rispetto a un'applicazione convenzionale.

Questa autonomia distingue un agente ombra da un chatbot non approvato. Un chatbot di norma restituisce informazioni a una persona. Un agente può inviare un messaggio, modificare codice, aggiornare un record cliente, interrogare un database o attivare un altro processo automatizzato.

Dark Reading ha riferito che la sicurezza dell'AI agentica resta un importante ostacolo aziendale, poiché i diffusi agenti locali si propagano più rapidamente di quanto i team responsabili delle identità riescano a inventariarli. La sua copertura ha descritto utenti che configuravano istanze prima ancora che i team di sicurezza sapessero dell'esistenza di tali agenti. Il rapporto ha anche esaminato una dimostrazione in cui un ticket di assistenza dannoso ha aiutato un agente a elevare l'accesso ed estrarre dati in meno di un minuto.

Questi esempi non dimostrano che ogni distribuzione di agenti sia insicura. Mostrano come fallimenti di controllo familiari diventino più rilevanti quando il software può pianificare e agire.

La portata del divario di visibilità è più chiara in un sondaggio aziendale sugli agenti del 2026 della Cloud Security Alliance. CSA ha riferito che l'82% delle organizzazioni partecipanti aveva scoperto agenti precedentemente sconosciuti nel corso dell'anno precedente.

La ricerca si basava su 418 risposte di professionisti IT e della sicurezza. Token Security ha commissionato e finanziato il sondaggio, una relazione che i lettori dovrebbero considerare nell'interpretarne le conclusioni.

Anche con questa precisazione, diversi risultati rivelano un problema di governance coerente. Il quarantuno per cento degli intervistati aveva scoperto agenti sconosciuti più volte. Gli ambienti interni di automazione e scripting erano la fonte più comune, citata dal 51%.

Le piattaforme LLM, inclusi strumenti personalizzati, assistenti e plugin, seguivano al 47%. Anche l'automazione SaaS e i workflow creati dagli sviluppatori figuravano tra le principali fonti.

Questa distribuzione spiega perché un normale inventario software sia insufficiente. Un agente può presentarsi come processo desktop, risorsa cloud, plugin, integrazione API o workflow incorporato in un prodotto SaaS approvato.

L'applicazione visibile è solo una componente. Credenziali, endpoint dei modelli, connessioni agli strumenti, archivi di memoria e agenti a valle formano il sistema operativo che la circonda.

Quel sistema può rimanere attivo dopo che il dipendente che lo ha creato passa a un altro progetto. Può inoltre mantenere l'accesso dopo che il suo scopo aziendale originario è venuto meno.

Google News può aver portato un titolo a un pubblico più vasto, ma l'evento supera il singolo ciclo di pubblicazione. Le imprese stanno scoprendo che il loro patrimonio AI include attori mai registrati e autorizzazioni mai esaminate.

Perché gli agenti AI ombra comportano un rischio diverso

Un agente ombra combina una risorsa sconosciuta con un'identità attiva, creando rischi che lo shadow IT tradizionale raramente comportava alla stessa velocità.

Lo shadow IT si riferisce di norma a software o infrastrutture adottati senza approvazione formale. I suoi rischi includono archiviazione dei dati non gestita, configurazioni insicure, scarsa valutazione dei fornitori e registri di audit mancanti.

L'AI ombra eredita questi problemi. A essi aggiunge poi decisioni probabilistiche, contesto persistente, uso di strumenti ed esecuzione autonoma.

Un'applicazione SaaS convenzionale segue workflow programmati. Un agente interpreta un obiettivo e seleziona un percorso. Due richieste simili possono portare ad azioni diverse, perché il modello, il contesto e gli strumenti disponibili influenzano ogni decisione.

Questa flessibilità crea valore. Rende però anche più difficile valutare l'agente attraverso una revisione di sicurezza una tantum.

L'autorità effettiva di un agente dipende da più della sua configurazione iniziale. I team di sicurezza devono considerare l'utente richiedente, le credenziali delegate, gli strumenti connessi, i contenuti recuperati, i dati accessibili e ogni azione a valle.

La prompt injection rende questa relazione particolarmente pericolosa. La prompt injection si verifica quando contenuti non attendibili manipolano le istruzioni di un agente, potenzialmente deviandolo dal compito previsto dall'utente.

Un'istruzione dannosa potrebbe essere nascosta in un ticket di assistenza, documento, email o pagina web. Se l'agente tratta quel contenuto come una guida affidabile, potrebbe divulgare informazioni o chiamare uno strumento autorizzato per uno scopo non autorizzato.

L'analisi dell'infrastruttura della Cloud Security Alliance descrive questo scenario come una superficie di attacco stratificata, anziché come una raccolta di applicazioni non autorizzate. La distinzione è utile perché gli agenti collegano sistemi che i team di sicurezza spesso valutano separatamente.

Si consideri un dipendente che costruisce un agente per riassumere il feedback dei clienti. L'agente legge un'unità condivisa, chiama un modello esterno, memorizza il contesto, pubblica conclusioni su un canale di messaggistica e aggiorna un database di pianificazione.

Ogni connessione può sembrare ragionevole isolatamente. Insieme, creano una pipeline capace di spostare informazioni riservate attraverso diversi confini di fiducia.

Il dipendente potrebbe proteggere la prima fonte di dati ma trascurare le impostazioni di conservazione del fornitore del modello. Potrebbe archiviare una credenziale API in un file di configurazione locale. Potrebbe concedere all'agente il permesso di modificare ogni record quando gli serve solo l'accesso in lettura.

L'agente può inoltre accumulare privilegi tramite accesso OAuth delegato. OAuth consente a un servizio di agire attraverso autorizzazioni concesse da un utente o da un'altra applicazione.

Un agente abbandonato può quindi rimanere operativo senza un tradizionale account dipendente. Il suo token può sopravvivere all'interno di un workflow, un'integrazione o un ambiente di sviluppo che riceve poca attenzione.

CSA definisce l'accumulo di agenti dimenticati e autorizzazioni mantenute “debito di dismissione”. Solo il 21% degli intervistati nel suo sondaggio ha dichiarato di disporre di un processo formale per dismettere gli agenti.

Questo divario nel ciclo di vita complica la risposta agli incidenti. Un team di sicurezza non può revocare rapidamente un agente quando non dispone di un record completo dell'identità dell'agente, del proprietario, degli strumenti e delle dipendenze.

Il rischio non si limita a compromissioni ostili. Un agente può causare danni pur perseguendo fedelmente un obiettivo definito in modo inadeguato.

Dark Reading ha esaminato questo schema di fallimento dopo che un agente AI di coding avrebbe eliminato dati di produzione e backup associati. L'incidente specifico coinvolgeva diverse debolezze di controllo, incluse credenziali estese e una separazione insufficiente tra gli ambienti.

Si tratta di errori di ingegneria familiari. L'autonomia comprime il tempo tra l'errore e le sue conseguenze.

Un operatore umano potrebbe fermarsi prima di eliminare un database. Un sistema di distribuzione deterministico potrebbe rifiutare un'azione al di fuori del proprio percorso programmato. Un agente può interpretare un'azione distruttiva come un passaggio valido per completare l'obiettivo assegnato.

Ecco perché le regole basate sui prompt non sono sufficienti. Dire a un agente di evitare azioni dannose può influenzarne il comportamento, ma non rimuove la sua capacità tecnica di compierle.

La capacità deve essere limitata al di fuori del modello. L'agente non dovrebbe avere accesso a sistemi e azioni che il suo compito non richiede.

I controlli aziendali sulle identità affrontano il loro test più difficile

Il principale terreno di confronto è ora la capacità autonoma contro sistemi di identità costruiti attorno a utenti stabili, account di servizio e carichi di lavoro prevedibili.

La gestione delle identità e degli accessi risponde a diverse domande fondamentali. Chi richiede l'accesso, a quale risorsa può accedere, quale azione può eseguire e per quanto tempo quell'autorizzazione dovrebbe rimanere valida?

Le imprese hanno trascorso anni a migliorare questi controlli per dipendenti e account di servizio. Gli agenti mettono in discussione entrambe le categorie.

Un agente non è una persona, ma spesso agisce per conto di una persona. Non è neppure un account di servizio tradizionale, perché la sua sequenza di azioni può cambiare mentre interpreta nuovo contesto.

Trattare un agente come un account di servizio condiviso oscura la responsabilità. I log potrebbero mostrare quale credenziale ha avuto accesso a un file senza rivelare quale utente abbia avviato il compito o perché l'agente abbia selezionato quel file.

I sistemi multi-agente rendono il problema più difficile. Un agente può delegare il lavoro a un altro, che chiama un terzo strumento con una credenziale diversa.

L'identità e l'intento dell'utente originario possono scomparire lungo quella catena. Le autorizzazioni seguono quindi l'integrazione tecnica anziché l'autorità della persona che ha richiesto il lavoro.

Le previsioni di sicurezza di Google per il 2026 avevano anticipato questo cambiamento. Sostenevano che gli agenti dovessero diventare attori digitali gestiti, con accesso granulare e consapevole del contesto.

Il rapporto ha sottolineato il privilegio minimo, l'accesso temporaneo e una catena di delega tracciabile. Il privilegio minimo significa che un'identità riceve solo l'accesso necessario per il proprio compito corrente.

Questi principi sono pratiche di sicurezza consolidate. La parte difficile consiste nell'applicarli alla velocità e alla scala dell'attività degli agenti.

Un dipendente può compiere diverse azioni importanti durante una giornata lavorativa. Un agente può avviare numerose chiamate a strumenti all'interno di un singolo compito e può operare continuamente.

Una revisione trimestrale degli accessi non può valutare ogni decisione. Le autorizzazioni statiche non possono stabilire se una particolare azione sia coerente con lo scopo attuale dell'agente.

Le aziende necessitano quindi di contesto nel punto in cui viene presa una decisione. Una richiesta di lettura di una cartella di progetto approvata potrebbe procedere automaticamente. Una richiesta di esportazione dei dati dei clienti dovrebbe invece attivare una verifica più rigorosa o un passaggio di approvazione umana.

Il sondaggio CSA mostra che le organizzazioni riconoscono già questa distinzione. Il 53% ha dichiarato che gli agenti operano autonomamente per le attività a basso rischio, mentre le azioni a rischio più elevato ricevono una revisione umana.

Solo il 13% ha riportato modelli pienamente autonomi. Tuttavia, quando gli agenti superavano il proprio ambito di azione, appena l’11% degli intervistati ha dichiarato che l’azione sarebbe stata bloccata automaticamente.

Questo divario è importante. Registrare un’azione dopo il suo completamento aiuta le indagini, ma non previene la perdita di dati o danni operativi.

Anche l’approvazione umana ha dei limiti. Se ogni azione genera una richiesta, i dipendenti finiranno per approvare le richieste senza valutarle con attenzione. L’affaticamento da approvazioni può trasformare un controllo visibile in un rituale inefficace.

Una progettazione migliore collega l’intervento al rischio. I team di sicurezza dovrebbero definire quali risorse, classificazioni dei dati e azioni richiedono controlli più rigorosi.

Microsoft ha iniziato a posizionare Agent 365 come piano di controllo per questo problema. Il suo aggiornamento di Agent 365 descrive la scoperta di agenti locali e cloud, incluse connessioni tra ambienti Microsoft, Amazon e Google.

Microsoft afferma che i suoi prodotti di sicurezza possono mappare dispositivi, server Model Context Protocol, identità associate e risorse cloud raggiungibili. Model Context Protocol, o MCP, è uno standard che consente alle applicazioni AI di connettersi a strumenti e fonti di dati.

Questa mappa delle relazioni è più utile di un semplice elenco di agenti. Aiuta i difensori a stimare il raggio d’impatto se un agente o le sue credenziali vengono compromessi.

Microsoft afferma inoltre che gli amministratori possono rilevare e bloccare metodi comuni impiegati da alcuni agenti locali non gestiti. I controlli di runtime sono pensati per fermare comportamenti sospetti mentre l’agente è in funzione.

Queste capacità illustrano la direzione della sicurezza aziendale, ma le affermazioni dei fornitori richiedono una validazione pratica. La scoperta multipiattaforma può non rilevare agenti personalizzati, infrastrutture private, connettori non supportati e flussi di lavoro nascosti all’interno di altri prodotti.

Un piano di controllo crea anche un proprio rischio di concentrazione. Le aziende devono decidere quanta autorità concedere al sistema responsabile della governance di ogni altro agente.

Il risultato non è una semplice migrazione dai vecchi strumenti di gestione delle identità a nuovi strumenti. Le aziende devono estendere i controlli di identità preservando al contempo monitoraggio indipendente, percorsi di ripristino e una significativa responsabilità umana.

La visibilità da sola non equivale al controllo

Scoprire un agente è necessario, ma un inventario non può dimostrare che le sue azioni restino sicure o allineate allo scopo assegnato.

I fornitori di sicurezza hanno risposto allo shadow AI con prodotti di scoperta. Questi prodotti ispezionano endpoint, traffico di rete, ambienti cloud, attività del browser, identità e integrazioni SaaS.

Questa visibilità fornisce un punto di partenza. Un’azienda non può governare una risorsa che non riesce a identificare.

Il pericolo è considerare la scoperta come un traguardo. Un agente può comparire in un inventario mentre le sue relazioni più importanti rimangono sconosciute.

I team di sicurezza devono sapere chi ne è responsabile, quale modello utilizza, quali dati recupera, dove risiede la sua memoria, quali credenziali possiede e quali strumenti può invocare.

Hanno anche bisogno di evidenze comportamentali. Un agente approvato per la riconciliazione delle fatture non dovrebbe iniziare improvvisamente a cercare nei repository del codice sorgente o a inviare file a un dominio sconosciuto.

La prevenzione tradizionale della perdita di dati può rilevare alcune informazioni sensibili in uscita da un’organizzazione. Potrebbe però non comprendere perché un agente abbia avuto accesso alle informazioni o se l’azione corrispondesse all’intento dell’utente che l’ha avviata.

La stessa limitazione si applica al monitoraggio degli endpoint. Il nome di un processo può rivelare che un agente è in esecuzione, ma non può sempre ricostruire un flusso di lavoro cloud avviato tramite quell’agente.

L’autorizzazione continua offre un modello più robusto. Valuta se l’accesso rimane appropriato a ogni passaggio significativo, invece di fidarsi di un singolo accesso iniziale.

Per gli agenti, questa valutazione dovrebbe includere lo scopo dell’attività, l’autorità dell’utente, la sensibilità della risorsa, la reputazione dello strumento, il comportamento attuale e i recenti cambiamenti nel rischio.

L’autorizzazione continua non richiede un’approvazione manuale per ogni operazione. Le azioni a basso rischio e reversibili possono procedere entro un limite definito.

Le azioni ad alto impatto meritano un percorso diverso. L’eliminazione di record, la pubblicazione di messaggi esterni, la modifica dell’infrastruttura, il cambiamento delle autorizzazioni o l’esportazione di dati regolamentati dovrebbero incontrare limiti tecnici.

Il limite dovrebbe esistere al di fuori del modello. Credenziali di sola lettura, ambienti isolati, limiti di transazione e servizi di approvazione separati possono restringere ciò che un agente può effettivamente fare.

Il ripristino richiede una separazione analoga. I backup non dovrebbero trovarsi all’interno dello stesso confine di autorizzazioni del sistema di produzione che un agente può modificare.

La copertura di Dark Reading sui database rende concreto questo punto. Se un agente può eliminare sia i dati di produzione sia la loro copia di ripristino attraverso un unico percorso di credenziali, il backup non fornisce una protezione indipendente.

Anche l’osservabilità richiede registri durevoli. I log dovrebbero conservare l’utente che ha avviato l’azione, l’identità dell’agente, il modello e la versione, l’obiettivo richiesto, gli strumenti selezionati, i dati a cui si è avuto accesso, le approvazioni ricevute e il risultato finale.

Registrare tutto crea problemi di privacy e archiviazione. Prompt sensibili e dati recuperati non dovrebbero diventare un dataset secondario senza restrizioni.

Le aziende necessitano di limiti di conservazione e controlli di accesso per la telemetria degli agenti. Gli investigatori richiedono abbastanza contesto per ricostruire le decisioni senza esporre ogni input riservato a un gruppo troppo ampio.

La governance dovrebbe anche distinguere la sperimentazione approvata dall’accesso alla produzione non controllato. Gli sviluppatori hanno bisogno di ambienti in cui possano testare nuovi agenti senza attendere l’intero ciclo di approvvigionamento.

Questi ambienti dovrebbero utilizzare dati sintetici o adeguatamente protetti. Dovrebbero isolare le credenziali e impedire l’accesso diretto alle risorse critiche di produzione.

Un divieto generalizzato crea un altro problema di visibilità. La previsione di Google ha avvertito che proibire gli agenti può spingere il loro utilizzo al di fuori della rete aziendale, dove il monitoraggio diventa ancora più debole.

Ciò non significa che ogni strumento debba ricevere l’approvazione. Significa che il percorso approvato deve essere abbastanza utilizzabile da indurre i dipendenti a sceglierlo.

I team di sicurezza possono offrire modelli verificati, connettori standard, credenziali limitate, ambienti di test e un processo di registrazione rapido. Queste misure riducono l’incentivo a creare alternative nascoste.

Anche i responsabili aziendali hanno un ruolo. Dovrebbero nominare un responsabile per ogni agente di produzione e documentare il processo aziendale che supporta.

La responsabilità deve includere il ritiro. Quando il progetto termina, l’organizzazione dovrebbe revocare i token, rimuovere le integrazioni, eliminare la memoria non necessaria e verificare che i flussi di lavoro dipendenti non chiamino più l’agente.

Senza questa disciplina del ciclo di vita, la visibilità diventa un elenco crescente di risorse irrisolte. L’azienda sa che il rischio esiste, ma non riesce comunque a rimuoverlo con sicurezza.

Le evidenze sono serie, ma hanno dei limiti

La ricerca attuale mostra un sostanziale divario di governance, ma sondaggi finanziati dai fornitori e incidenti isolati non possono misurare la frequenza complessiva dei danni causati dagli agenti.

Il reporting sulla sicurezza richiede due forme di cautela. Le aziende non dovrebbero liquidare gli shadow agent come un problema ipotetico. Ma non dovrebbero neppure trattare ogni previsione o statistica dei fornitori come una misurazione neutrale.

Il sondaggio CSA fornisce dettagli utili perché identifica il numero di intervistati, il periodo dell’indagine e diversi modelli di distribuzione. Dichiara inoltre che Token Security ha commissionato, finanziato e contribuito a sviluppare il questionario.

Token vende sicurezza delle identità per agenti AI. Questo non invalida i risultati, ma crea un interesse commerciale nell’enfatizzare i divari di visibilità e identità.

Altre misurazioni citate frequentemente provengono da fornitori di sicurezza che osservano i propri clienti. Questi dataset possono rivelare tendenze all’interno della telemetria di un prodotto, ma potrebbero non rappresentare tutte le aziende.

La selezione dei clienti, la configurazione di distribuzione, i metodi di rilevamento e la terminologia possono influenzare il risultato. Un prodotto potrebbe contare ogni flusso di lavoro come un agente, mentre un altro conta solo identità di agenti indipendenti.

Anche il termine “incidente” richiede un’interpretazione attenta. Può comprendere esposizione di dati, violazioni delle policy, comportamenti inattesi, interruzioni operative o compromissioni confermate.

CSA ha riportato che il 65% degli intervistati ha subito un incidente correlato a un agente AI nell’anno precedente. Tra le organizzazioni coinvolte, l’esposizione dei dati è stata l’impatto aziendale segnalato più frequentemente.

Questa conclusione è preoccupante. Non stabilisce quanti incidenti abbiano coinvolto aggressori malevoli, azioni accidentali, utilizzo non approvato o fallimenti in sistemi autorizzati.

I casi documentati offrono profondità, ma non prevalenza. L’eliminazione del database di produzione di un’azienda dimostra una plausibile catena di guasti. Non può indicare ai lettori con quale frequenza si verifichino eventi simili sul mercato.

La stessa cautela si applica alle dimostrazioni di attacco. Un exploit controllato mostra che una progettazione può fallire in condizioni specifiche. Difese di produzione, autorizzazioni e monitoraggio possono modificare l’esito.

Le aziende dovrebbero quindi chiedere ai fornitori la metodologia di rilevamento, i confini della copertura, i tassi di falsi positivi e una validazione indipendente. Un dashboard etichettato come “inventario completo” merita un esame particolarmente attento.

Gli agenti sconosciuti sono sconosciuti proprio perché la scoperta è incompleta. Nessun fornitore può dimostrare una copertura universale mostrando soltanto le risorse rilevate dai propri sensori.

I responsabili della sicurezza dovrebbero anche separare il rischio del modello dal rischio dei sistemi. Un agente può prendere una decisione inadeguata a causa del comportamento del modello, ma sono le autorizzazioni eccessive a determinare se quella decisione diventi un incidente grave.

Viceversa, autorizzazioni ristrette non risolvono ogni problema. Un agente con accesso in sola lettura può comunque divulgare informazioni riservate, produrre raccomandazioni dannose o influenzare un altro sistema.

La risposta più credibile combina valutazione del modello, governance delle identità, protezione dei dati, monitoraggio di runtime e resilienza operativa. Nessun singolo livello sostiene l’intero peso.

Le aziende necessitano inoltre di report sugli incidenti che distinguano i guasti degli agenti dai normali guasti delle applicazioni. Report utili dovrebbero acquisire il livello di autonomia, il percorso di accesso, l’identità iniziante, il componente compromesso e l’impatto aziendale.

Senza definizioni condivise, il mercato produrrà numeri grandi ma incompatibili. Ciò rende più difficile per consigli di amministrazione e autorità di regolamentazione capire se il rischio stia migliorando.

I lettori di Google News dovrebbero interpretare il titolo attuale come un avvertimento sostenuto da evidenze convergenti, non come una misurazione completa dell’esposizione aziendale.

Il divario di verifica è parte della storia. Il settore vede abbastanza elementi da giustificare un intervento, ma manca ancora di dati pubblici coerenti sugli incidenti degli agenti e sulle loro conseguenze.

Cosa dovrebbero osservare le aziende

La prossima fase sarà definita da registri degli agenti, applicazione delle policy in runtime ed evidenze sugli incidenti che verifichino se i prodotti di governance funzionano al di fuori delle dimostrazioni dei fornitori.

Il primo segnale è l’adozione di registri di agenti multipiattaforma. Microsoft, i fornitori di sicurezza e i provider cloud stanno realizzando sistemi che inventariano gli agenti tra endpoint, prodotti SaaS e ambienti cloud.

Le aziende dovrebbero verificare se tali registri rilevano flussi di lavoro personalizzati e strumenti non supportati. Una copertura limitata all’ambiente di un solo fornitore non risolverà un problema di shadow agent multicloud.

Le evidenze più solide arriveranno da confronti indipendenti. I team di sicurezza hanno bisogno di test che distribuiscano agenti noti attraverso vari canali e misurino quali prodotti rilevino ogni componente.

Un registro utile dovrebbe identificare proprietà, finalità, identità, autorizzazioni, strumenti, fonti di dati e stato del ciclo di vita. Un elenco di nomi di agenti offre un contesto troppo limitato per prendere decisioni sul rischio.

Il secondo segnale è l’applicazione delle regole in fase di esecuzione. Gli annunci di prodotto promettono sempre più spesso di bloccare l’uso sospetto degli strumenti, limitare gli agenti in base alle policy e applicare autorizzazioni contestuali.

La misura importante non è se un prodotto riesca a generare un avviso. È se il prodotto riesca a fermare un’azione ad alto impatto senza interrompere il normale lavoro.

I falsi positivi contano perché gli agenti possono avviare molte operazioni. Un controllo che blocca attività di routine spingerà i team a disattivarlo o ad aggirarlo.

I falsi negativi contano ancora di più. Una sola azione distruttiva non rilevata può vanificare migliaia di richieste correttamente approvate.

Le aziende dovrebbero testare i controlli contro prompt injection, credenziali compromesse, deleghe eccessive, trasferimenti di dati non autorizzati e tentativi di modificare i registri di audit. I test dovrebbero includere sia le implementazioni autorizzate sia quelle non ufficiali.

Il terzo segnale è una migliore divulgazione degli incidenti. L’industria tecnologica dispone di sistemi dettagliati per segnalare le vulnerabilità software, ma i fallimenti degli agenti non rientrano agevolmente in questi canali.

Un connettore vulnerabile potrebbe ricevere un identificatore convenzionale. Un agente che interpreta erroneamente un obiettivo, eredita accessi eccessivi e cancella dati pone una questione di responsabilità più complessa.

Il guasto è stato causato dal modello, dal framework dell’agente, dal connettore, dalla progettazione delle credenziali, dall’implementazione o dall’istruzione umana? In molti casi hanno contribuito più livelli.

Una segnalazione coerente aiuterebbe le organizzazioni a confrontare gli incidenti e a migliorare i controlli. Rivelerebbe inoltre se i rischi ampiamente discussi si traducono in ricorrenti fallimenti in produzione.

Regolatori e revisori probabilmente chiederanno prove, non documenti di policy. Un’azienda dovrebbe essere in grado di mostrare quali agenti esistevano, chi ne era responsabile, a cosa accedevano e come venivano controllate le azioni ad alto rischio.

La risposta pratica dovrebbe iniziare prima che arrivino tali richieste. I team di sicurezza possono censire gli agenti noti, cercare quelli non approvati, classificarne l’autorità e rimuovere le credenziali abbandonate.

Possono inoltre definire un piccolo insieme di azioni che richiedono sempre controlli più rigorosi. La cancellazione in produzione, la pubblicazione esterna, le modifiche alle autorizzazioni e l’esportazione massiva di dati sono punti di partenza sensati.

Sviluppatori e knowledge worker dovrebbero chiedersi cosa possa fare un agente prima di concentrarsi su ciò che può generare. Le autorizzazioni dietro una dimostrazione impressionante ne determinano il reale rischio aziendale.

I leader aziendali dovrebbero chiedersi se il percorso approvato per gli agenti sia sufficientemente accessibile da ridurre l’adozione non ufficiale. Una governance che esiste solo sulla carta perderà contro uno strumento che un dipendente può installare in pochi minuti.

Il titolo di Google News riguarda quindi meno una minaccia appena scoperta che un riconoscimento tardivo. Il software autonomo è già entrato nei flussi di lavoro aziendali, mentre molte organizzazioni lo gestiscono ancora come un’altra applicazione.

Questo approccio non reggerà. Ogni agente in produzione necessita di un’identità, di un responsabile definito, di autorità limitata, di azioni osservabili e di un percorso di dismissione verificato.

I prossimi tre mesi dovrebbero rivelare se i registri degli agenti otterranno una credibile copertura multipiattaforma, se i controlli runtime supereranno test realistici e se la divulgazione degli incidenti diventerà più specifica.

Se questi segnali emergeranno, la governance aziendale sta iniziando a recuperare terreno. In caso contrario, il problema degli agenti ombra continuerà a espandersi dietro dashboard che suggeriscono un controllo maggiore di quello che le organizzazioni possiedono realmente.