Le aziende sono cieche su due terzi della loro superficie di attacco AI, avverte Snyk

Snyk ha associato un numero netto al rischio AI per le aziende: quasi due terzi della superficie di attacco rilevante possono trovarsi al di fuori della visione diretta dei team di sicurezza. L'avvertimento, emerso tramite Google News, si concentra su agenti, plugin, dataset e pipeline di dati connessi nel lavoro quotidiano. Questi componenti si moltiplicano man mano che le aziende portano gli esperimenti AI in produzione.

Il dato proviene da Snyk, non da un audit indipendente dell'intero mercato enterprise. La relativa analisi utilizza informazioni anonimizzate provenienti da oltre 500 ambienti aziendali associati a Snyk Evo. La distinzione è importante. I dati offrono una visione degli ambienti partecipanti, mentre l'affermazione più ampia richiede ancora una convalida su altre piattaforme e in altri settori.

Anche con questa riserva, Snyk descrive un problema che va oltre la telemetria di un singolo fornitore. Una ricerca della Cloud Security Alliance ha rilevato che il 68% delle organizzazioni intervistate non era in grado di distinguere chiaramente le azioni degli agenti AI dall'attività umana. OWASP ha documentato separatamente prompt injection, autorizzazioni eccessive e autonomia incontrollata come rischi concreti per le applicazioni.

Il conflitto centrale non è quindi tra adozione dell'AI e resistenza. È tra una distribuzione rapida e decentralizzata e sistemi di sicurezza costruiti attorno ad applicazioni note, identità umane e inventari stabili. Le aziende stanno autorizzando sempre più software a ragionare e agire, perdendo al contempo fiducia nella conoscenza di ciò che è connesso ai loro dati.

Questo divario mette sotto pressione i team di sicurezza, ma coinvolge anche sviluppatori, ingegneri di piattaforma, responsabili degli acquisti e titolari di processi aziendali. Ogni gruppo può introdurre una dipendenza dall'AI. Poche organizzazioni dispongono di un unico sistema in grado di mappare la catena risultante da modello a plugin, identità, dataset, API e azione in produzione.

Perché l'avvertimento di Snyk è arrivato su Google News

L'affermazione più importante di Snyk non è che l'AI crei nuove vulnerabilità. È che le aziende non riescono a vedere in modo affidabile i sistemi che le creano.

Snyk ha introdotto la sua AI Security Fabric nel febbraio 2026 come livello trasversale allo sviluppo software e ai sistemi agentici. L'azienda ha dichiarato che il proprio approccio combinerebbe visibilità, prevenzione e governance lungo l'intero ciclo di vita dello sviluppo software.

L'annuncio del prodotto includeva risultati della ricerca 2026 State of Agentic AI Adoption di Snyk. Secondo l'azienda, l'analisi copriva dati anonimizzati provenienti da oltre 500 ambienti enterprise Evo. Snyk ha dichiarato che ogni modello AI distribuito era associato a quasi tre volte più componenti nascosti, inclusi dataset e strumenti di terze parti.

L'affermazione principale estende ulteriormente questa osservazione. Snyk sostiene che circa due terzi del rischio AI aziendale si trovino al di sotto del livello dei modelli più visibili. La parte nascosta include strumenti degli agenti, plugin, repository connessi, servizi esterni e pipeline di dati che i dipendenti collegano durante lo sviluppo o nel lavoro quotidiano.

Questi componenti non sono automaticamente dannosi. Un plugin può semplicemente recuperare un documento, chiamare un'API interna o inviare un messaggio approvato. Il problema di sicurezza emerge dalla relazione tra il componente, le sue autorizzazioni, le sue fonti di input e la sua capacità di attivare azioni a valle.

Un inventario dei soli modelli non può cogliere tali relazioni. Due team potrebbero usare lo stesso modello tramite agenti diversi con profili di rischio completamente differenti. Un agente può riassumere documenti pubblici. Un altro può leggere codice sorgente, interrogare record dei clienti e scrivere modifiche nei sistemi di produzione.

Per questo la storia merita più del consueto avvertimento sui dipendenti che usano chatbot non approvati. La shadow AI ora include funzionalità integrate in software approvato, modelli distribuiti localmente, framework per agenti, estensioni del browser, servizi di automazione e identità macchina. Alcuni arrivano tramite procedure formali di acquisto. Altri compaiono quando un dipendente connette un ulteriore strumento per completare un'attività.

Google News offre a questa affermazione un ampio canale di distribuzione, ma l'aggregazione non convalida il dato sottostante. I lettori dovrebbero considerare la stima dei due terzi come una rilevazione del fornitore, ricavata dai dati ambientali relativi ai clienti di Snyk. La conclusione più solida poggia su prove corroboranti: le aziende faticano a inventariare il comportamento degli agenti, le autorizzazioni e le dipendenze tra componenti.

Questa distinzione evita che l'analisi si trasformi in marketing di prodotto. La stima precisa di Snyk sull'intero mercato resta da verificare. Il problema della visibilità è già supportato da molteplici fonti indipendenti e orientate agli standard.

La superficie di attacco AI non è più un elenco di applicazioni

La superficie di attacco pratica si comporta oggi come un grafo in continua evoluzione, in cui modelli, identità, strumenti e archivi dati creano rischi attraverso le loro connessioni.

La sicurezza applicativa tradizionale parte da un oggetto relativamente stabile. Un team possiede un'applicazione, ne gestisce il repository, tiene traccia delle dipendenze e la distribuisce tramite un'infrastruttura nota. Gli strumenti di sicurezza possono analizzare il codice, i pacchetti, le immagini dei container, la configurazione cloud e gli endpoint esposti.

I sistemi nativi dell'AI aggiungono più parti in movimento. L'analisi di Snyk sulle applicazioni AI-native descrive una supply chain che può includere modelli preaddestrati, embedding, agenti di terze parti, dataset e servizi esterni. Ogni componente può cambiare indipendentemente dal codice sorgente dell'applicazione.

Un embedding è una rappresentazione numerica utilizzata per confrontare il significato dei contenuti. Un database vettoriale può archiviare milioni di queste rappresentazioni per il recupero delle informazioni. Se le autorizzazioni o le etichette delle fonti sono errate, un agente può recuperare informazioni a cui il suo utente non avrebbe mai dovuto accedere.

La retrieval-augmented generation, spesso abbreviata in RAG, fornisce a un modello documenti o record selezionati prima che produca una risposta. RAG può migliorare l'accuratezza, ma crea anche un ulteriore confine di fiducia. Il livello di recupero deve decidere quali fonti l'agente può cercare e quali contenuti dovrebbe restituire.

Gli strumenti creano un confine più rilevante. Un agente collegato a email, controllo del codice sorgente, infrastruttura cloud o database clienti può andare oltre la produzione di testo. Può leggere, scrivere, eseguire, approvare o trasmettere informazioni, a seconda delle autorizzazioni assegnategli dagli sviluppatori.

Ciò crea uno scarto rispetto agli inventari di sicurezza organizzati attorno alle applicazioni acquistate. Un'azienda può aver approvato il fornitore del modello e il framework dell'agente. Potrebbe comunque non disporre di un registro completo di ogni endpoint degli strumenti, account di servizio, dataset, modello di prompt o plugin collegato dopo la distribuzione.

La catena può anche cambiare senza una release tradizionale. Un fornitore di modelli può aggiornare il comportamento. Uno strumento di terze parti può aggiungere una funzione. Un dataset può ricevere nuovi documenti. Un utente può ampliare un ambito OAuth, che determina a quali risorse un'applicazione può accedere tramite autorizzazione delegata.

Questi cambiamenti sono importanti perché il rischio dipende dalle combinazioni. Un agente di sintesi con accesso in sola lettura ha un raggio d'impatto limitato. Se allo stesso agente viene data l'autorizzazione a inviare email, modificare file e chiamare un endpoint web senza restrizioni, un input manipolato può produrre un risultato molto diverso.

La superficie di attacco include quindi più delle vulnerabilità nel codice. Include autorizzazioni eccessive, contesto avvelenato, credenziali esposte, gestione non sicura degli output, regole di approvazione deboli e log delle azioni incompleti. Molti di questi problemi restano invisibili agli scanner che ispezionano soltanto file sorgente o pacchetti software noti.

Per i team di ingegneria, la documentazione diventa parte del sistema di controllo. Un registro ricercabile delle decisioni architetturali, degli strumenti approvati, degli ambiti di autorizzazione e delle risultanze degli incidenti aiuta i team a identificare relazioni che le singole dashboard non rilevano. Una base di conoscenza ingegneristica strutturata può supportare questo lavoro, sebbene non sostituisca il monitoraggio della sicurezza.

La lezione più ampia è semplice. Un sistema AI non può essere governato come un singolo endpoint di modello. Deve essere trattato come un'applicazione connessa, i cui dati, strumenti, identità e azioni rimangano visibili durante l'intero funzionamento.

L'AI agentica mette sotto pressione i controlli delle identità

Il punto cieco in più rapida crescita si trova dove il software autonomo eredita autorizzazioni progettate per utenti umani.

La Cloud Security Alliance ha pubblicato una ricerca sulle identità degli agenti nel marzo 2026. Il sondaggio ha rilevato che il 73% delle organizzazioni si aspettava che gli agenti AI diventassero essenziali entro l'anno successivo. Tuttavia, il 68% non riusciva a distinguere chiaramente le azioni svolte dagli agenti da quelle svolte dalle persone.

La somiglianza tra quel dato del 68% e l'avvertimento di Snyk sui circa due terzi è notevole, ma le cifre misurano aspetti diversi. Snyk parla di componenti nascosti e rischio negli ambienti AI. Il sondaggio della Cloud Security Alliance esamina l'attribuzione delle identità e la gestione degli accessi.

Insieme, rivelano la stessa debolezza strutturale. Le organizzazioni stanno concedendo alle identità software l'accesso ai sistemi aziendali più rapidamente di quanto aggiornino le pratiche di autenticazione, autorizzazione e monitoraggio.

Un'identità macchina è una credenziale utilizzata dal software anziché da una persona. Può assumere la forma di una chiave API, un account di servizio, un certificato, un'identità di workload o un token OAuth. Gli agenti dipendono da queste credenziali per accedere ai dati ed eseguire azioni.

I sistemi di identità umana in genere presuppongono che una persona effettui l'accesso, riceva un ruolo definito e generi attività collegate a quell'account. Gli agenti complicano questo modello. Un singolo agente può agire per più utenti, chiamare più strumenti e creare in pochi secondi una catena di operazioni generate dalla macchina.

L'attribuzione diventa particolarmente difficile quando un agente usa un account di servizio condiviso. I log possono mostrare che l'account ha modificato un record o scaricato un file. Potrebbero non identificare la richiesta del dipendente, la decisione del modello, il documento recuperato o la chiamata al plugin che ha causato l'azione.

Non si tratta soltanto di un inconveniente di audit. Un'attribuzione debole rende più difficile il contenimento degli incidenti. Un team di sicurezza non può revocare con certezza la credenziale corretta se non sa quale agente, utente o workflow abbia avviato l'attività sospetta.

L'accesso con privilegi eccessivi aumenta il danno. Uno strumento creato solo per riassumere messaggi può ricevere l'autorizzazione a inviarli o eliminarli. Un assistente per il codice può ottenere accesso in scrittura a più repository quando gli serve soltanto esaminare un progetto.

OWASP descrive questa condizione come autonomia eccessiva. Le sue linee guida identificano funzionalità, autorizzazioni e autonomia eccessive come cause principali. OWASP raccomanda di limitare gli strumenti disponibili, restringere le autorizzazioni, eseguire le azioni nel contesto dell'utente e richiedere approvazione per le operazioni ad alto impatto.

Questi controlli richiamano pratiche mature di zero trust. Ogni richiesta dovrebbe essere valutata usando un'identità specifica, un'autorizzazione definita e il contesto corrente. Il modello non dovrebbe decidere autonomamente se un'operazione sia consentita.

L’agente necessita inoltre di un’identità distinta dal suo operatore umano. I log dovrebbero preservare la relazione tra la richiesta dell’utente, l’istanza dell’agente, lo strumento selezionato, la credenziale utilizzata e l’azione risultante. Senza questa catena, le aziende possono raccogliere enormi volumi di telemetria e restare comunque cieche.

È qui che l’adozione dell’AI mette sotto pressione l’architettura di sicurezza. I team aziendali vogliono assistenti che eliminino approvazioni ripetitive e completino attività in più passaggi. I team di sicurezza necessitano di punti di controllo, autorizzazioni ristrette e decisioni ricostruibili. Rimuovere ogni punto di controllo aumenta la velocità, ma amplia anche il potenziale raggio d’impatto di un’azione errata o manipolata.

Il conflitto non si risolverà scegliendo la piena autonomia o vietando gli agenti. Le imprese hanno bisogno di livelli di autonomia diversi in base alle conseguenze. La stesura di un riepilogo può restare automatica. L’invio di fondi, l’eliminazione di record, la modifica dell’infrastruttura di produzione o la divulgazione di dati protetti dovrebbero richiedere controlli più rigorosi.

Il vero compromesso è tra velocità e controllo verificabile

Le imprese ottengono valore quando gli agenti attraversano i confini tra sistemi, ma ogni connessione aggiuntiva rende il comportamento più difficile da verificare.

L’AI agentica interessa alle aziende perché può collegare passaggi separati in un unico flusso di lavoro. Un agente di assistenza potrebbe leggere un ticket, recuperare la cronologia dell’account, classificare l’urgenza, proporre una risposta e aggiornare il record del cliente. Questa sequenza può ridurre il coordinamento manuale.

La stessa sequenza contiene diversi confini di sicurezza. Il ticket può includere testo non attendibile. La cronologia dell’account può contenere dati protetti. Il modello può generare un’istruzione per strumenti non sicura. Il sistema clienti può accettare un aggiornamento con conseguenze durature.

La prompt injection rende concreto questo compromesso. La prompt injection si verifica quando contenuti costruiti ad arte modificano il modo in cui un modello segue le istruzioni. Il contenuto può provenire direttamente da un utente o indirettamente da una pagina web, un documento, un’email, un repository o un record recuperato.

Un’applicazione convenzionale separa i comandi dai dati attraverso sintassi rigorosa e controlli di accesso. I modelli linguistici elaborano entrambi come token nel contesto. Questa progettazione rende difficile garantire che un modello tratti sempre il testo esterno come dati non attendibili anziché come istruzioni.

Le attuali linee guida di OWASP affermano che non è noto alcun metodo infallibile per prevenire la prompt injection. Raccomandano di vincolare il comportamento, validare i formati di output previsti, filtrare input e output e limitare le autorizzazioni disponibili al modello.

Queste mitigazioni riducono l’impatto, ma non creano certezza. Un agente che può soltanto leggere una raccolta ristretta di documenti presenta meno pericoli di uno che può eseguire comandi shell. Un passaggio di approvazione umana può intercettare azioni sospette, ma solo se il revisore riceve abbastanza contesto per prendere una decisione informata.

La velocità mette sotto pressione ogni salvaguardia. I team possono concedere accessi ampi per evitare lavori di integrazione ripetuti. Possono usare credenziali condivise perché l’autorizzazione per singolo utente richiede più tempo per essere implementata. Possono sopprimere le richieste di approvazione dopo che gli utenti si lamentano dell’attrito.

Questo rende la questione centrale un compromesso tra velocità di implementazione e controllo verificabile. Snyk sostiene che la sicurezza debba diventare continua perché i sistemi AI cambiano troppo rapidamente per revisioni occasionali. L’interesse commerciale dell’azienda è evidente, dato che vende prodotti posizionati attorno a questa esigenza.

Gli acquirenti dovrebbero quindi separare la diagnosi dalla piattaforma proposta. Un livello di sicurezza unificato potrebbe migliorare la visibilità, ma nessun fornitore ha dimostrato che un singolo prodotto possa osservare ogni modello, implementazione locale, strumento del browser, dataset, identità e integrazione esterna in una grande impresa.

Le affermazioni sulla copertura dipendono dalle integrazioni e dalla telemetria. Un modello cloud approvato può essere facile da rilevare. Un modello ospitato localmente sulla workstation di uno sviluppatore potrebbe non esserlo. Una funzionalità AI all’interno di un pacchetto software noto può generare attività che sembrano normale traffico applicativo.

Le connessioni cifrate e le regole sulla privacy introducono ulteriori limiti. Il monitoraggio dei prompt o dei documenti recuperati può esporre dati sensibili di dipendenti e clienti. I team di sicurezza hanno bisogno di contesto sufficiente per rilevare abusi senza creare un secondo repository di informazioni riservate.

Le norme regionali sui dati aggiungono un ulteriore vincolo. Una multinazionale potrebbe non essere in grado di centralizzare tutti i log delle interazioni AI. Potrebbe necessitare di elaborazione locale, metadati selettivi, controlli di conservazione e politiche di monitoraggio diverse per giurisdizioni diverse.

Queste complicazioni non invalidano l’avvertimento di Snyk. Rafforzano il suo punto centrale, pur mettendo in discussione qualsiasi soluzione semplice. La visibilità è necessaria, ma la visibilità stessa crea costi di progettazione, privacy e operatività.

Cosa non dimostra l’affermazione dei due terzi

I dati di Snyk segnalano un serio divario di governance, ma non stabiliscono che due terzi di ogni ambiente aziendale siano compromessi o sfruttabili.

La limitazione più importante è il campionamento. Snyk descrive insight anonimizzati provenienti da oltre 500 ambienti enterprise Evo. Le organizzazioni che usano tale ambiente possono differire dal mercato più ampio per dimensioni, pratiche software, maturità AI o priorità di sicurezza.

L’azienda non ha dimostrato pubblicamente che il proprio campione rappresenti ogni settore o regione geografica. Ha inoltre un motivo commerciale per definire il problema in termini che favoriscono una copertura di sicurezza più ampia. Nessuno dei due aspetti rende falsi i dati, ma entrambi richiedono un’attribuzione prudente.

“Rischio” è inoltre un concetto più ampio di “vulnerabilità”. Un componente nascosto può essere non gestito o inventariato in modo insufficiente senza contenere una falla sfruttabile. Diventa pericoloso quando si combina con autorizzazioni deboli, dati sensibili, input non sicuri o la capacità di eseguire azioni con conseguenze rilevanti.

Allo stesso modo, “due terzi” non significa che i team di sicurezza vedano esattamente un terzo di ogni ambiente. La stima riassume modelli osservati negli ambienti analizzati. Le singole organizzazioni possono avere una copertura molto migliore o molto peggiore.

L’espressione “superficie di attacco” può ulteriormente confondere problemi diversi. Può includere asset esposti a Internet, API interne, dipendenze software, strumenti degli agenti, flussi di dati, identità e comportamento dei modelli. Fornitori diversi conteggiano questi elementi in modo diverso.

Una misurazione indipendente richiederà definizioni condivise. I ricercatori devono distinguere gli asset noti da quelli sconosciuti, i componenti raggiungibili da quelli inattivi e l’esposizione teorica dai percorsi di attacco dimostrati. Senza queste distinzioni, grandi percentuali attirano l’attenzione ma offrono indicazioni operative limitate.

NIST offre una base più neutrale attraverso il suo AI Risk Framework. Il framework organizza il lavoro attorno alla governance, alla mappatura, alla misurazione e alla gestione dei rischi AI. Sottolinea inoltre che la gestione del rischio dovrebbe proseguire durante l’intero ciclo di vita del sistema.

La mappatura è particolarmente rilevante per l’affermazione di Snyk. Un’organizzazione deve identificare il modello, l’attività prevista, gli utenti, i dati, le dipendenze, il contesto di implementazione e le parti interessate prima di poter misurare il rischio. Uno scanner non può recuperare ogni politica o decisione di responsabilità mancante.

Anche la misurazione richiede test. Un’azienda può documentare le autorizzazioni previste di un agente senza mai verificarne le autorizzazioni effettive in produzione. Può registrare gli strumenti approvati, trascurando al contempo funzionalità aggiunte tramite un’integrazione aggiornata.

La posizione scettica non è quindi che il punto cieco sia immaginario. È che la telemetria di un singolo fornitore non può ancora definirne l’esatta dimensione sull’intero mercato. Il titolo dovrebbe motivare inventario e test, non diventare un sostituto di entrambi.

I responsabili della sicurezza dovrebbero chiedere ai fornitori come calcolano la copertura. Dovrebbero richiedere il denominatore, i metodi di rilevamento, gli ambienti esclusi, la frequenza di aggiornamento e il processo per risolvere asset duplicati o obsoleti. Una percentuale precisa senza questo contesto può creare falsa fiducia.

Dovrebbero anche misurare i risultati. Individuare più componenti è utile solo se l’organizzazione può assegnare priorità alle relazioni pericolose, attribuire responsabili, ridurre le autorizzazioni e correggere percorsi verificati. Un inventario più ampio che produce una coda di avvisi ingestibile può diventare un’altra forma di cecità.

Tre segnali mostreranno se il punto cieco si sta riducendo

La prossima fase sarà misurata attraverso l’attribuzione delle identità, gli inventari dei componenti e riduzioni verificate delle autorizzazioni pericolose degli agenti.

Il primo segnale è se le imprese riescono a separare nei log l’attività degli agenti da quella umana. Il dato del 68% della Cloud Security Alliance fornisce una chiara base di riferimento, anche se deriva da un sondaggio anziché da telemetria diretta.

Un miglioramento significherebbe che ogni azione rilevante include un’identità dell’agente, una delega dell’utente, il nome dello strumento, il contesto di autorizzazione e un risultato tracciabile. Se indagini successive mostrassero un minor numero di organizzazioni in difficoltà con l’attribuzione, la tesi di una governance degli agenti gestibile diventerebbe più solida.

Se il numero rimanesse vicino ai due terzi, ne seguirebbe la conclusione opposta. Le imprese avrebbero implementato più flussi di lavoro autonomi senza risolvere la responsabilità di base. Questo esito rafforzerebbe l’avvertimento di Snyk secondo cui il divario di visibilità cresce con l’adozione.

Il secondo segnale è l’emergere di distinte base AI coerenti. Una distinta base AI registra modelli, dataset, prompt, framework, strumenti, servizi e dipendenze utilizzati da un sistema. Estende il concetto di distinta base software ai componenti specifici dell’AI.

La versione utile deve rimanere sincronizzata con l’implementazione. Un documento statico creato durante l’approvvigionamento non rileverà gli strumenti e i dataset connessi in seguito. La scoperta automatizzata, l’assegnazione dei responsabili, la cronologia delle versioni e le prove delle autorizzazioni effettive contano più della semplice produzione di un elenco.

L’adozione diffusa di formati di inventario interoperabili rafforzerebbe l’argomento secondo cui le imprese possono recuperare visibilità. La continua dipendenza da dashboard specifiche dei fornitori lascerebbe punti ciechi tra prodotti di sicurezza, piattaforme cloud e ambienti locali.

Il terzo segnale è se le organizzazioni riducono l’eccessiva autonomia operativa in produzione. I team di sicurezza dovrebbero monitorare quanti agenti possono scrivere dati, eseguire codice, inviare comunicazioni, modificare l’infrastruttura o accedere a repository sensibili senza un’approvazione separata.

Un numero in calo dimostrerebbe che le aziende stanno traducendo la governance AI in controlli tecnici. Un numero in aumento indicherebbe che gli obiettivi di produttività continuano a prevalere sul contenimento. I rapporti sugli incidenti che coinvolgono agenti con privilegi eccessivi renderebbero questa metrica particolarmente urgente.

Questi segnali contano più del volume di politiche AI pubblicate dalle aziende. Le politiche descrivono l’intento. Identità, inventari, autorizzazioni e log rivelano la realtà operativa.

Il titolo di Snyk su Google News riesce perché condensa questa realtà in un avvertimento memorabile. La cifra esatta dei due terzi resta una stima derivata da un fornitore, ma il disallineamento sottostante è difficile da liquidare. I componenti AI si stanno moltiplicando più rapidamente di quanto molte organizzazioni riescano a scoprirli, classificarli e governarli.

Per gli sviluppatori, la domanda immediata è se ogni connessione dell’agente abbia un responsabile nominato e un’autorizzazione necessaria. Per i team di sicurezza, è se i log possano ricostruire un’azione dalla richiesta dell’utente, passando per la decisione del modello, fino al risultato a valle. Gli acquirenti aziendali dovrebbero richiedere prove per entrambi.

Il prossimo trimestre offre un test pratico. Scegliete un agente di produzione, mappate ogni modello, strumento, identità, dataset e chiamata esterna, quindi confrontate tale mappa con i record di sicurezza esistenti. Se le due viste differiscono nettamente, il punto cieco è già all’interno dell’organizzazione. Se coincidono, verificate se le autorizzazioni e i controlli di approvazione si comportano come documentato. Google News ha fornito l’avvertimento; ora la telemetria aziendale deve fornire la risposta.