La sicurezza dell’intelligenza artificiale in azienda sta diventando un problema bidirezionale. Non basta più controllare le informazioni che dipendenti e applicazioni inviano ai modelli: occorre verificare anche i dati che servizi e agenti AI recuperano dai sistemi connessi e restituiscono agli utenti.
Il cambio di scenario emerge dal Netskope AI Report 2026, basato sui dati aggregati raccolti dalla piattaforma Netskope One presso un campione di clienti tra giugno 2025 e luglio 2026. Le violazioni delle policy “downstream”, nelle quali un sistema AI fornisce dati che il destinatario non è autorizzato a consultare, sono più che raddoppiate in un anno: da 12 a 31 alla settimana per organizzazione. Nel 25% delle aziende maggiormente esposte, sono passate da 72 a 206 casi settimanali.
I numeri rappresentano alert generati dalle policy di sicurezza, non necessariamente incidenti informatici confermati. Mostrano però quanto sia diventato più difficile preservare le autorizzazioni originarie quando un agente può interrogare database, repository, documenti e applicazioni per conto di un utente.
Dalla shadow AI alla governance delle operazioni
Nella prima fase dell’adozione, il problema principale consisteva nell’individuare dipendenti che usavano account personali e servizi non approvati per elaborare informazioni aziendali. Con l’introduzione di applicazioni gestite, agenti e infrastrutture AI interne, la semplice classificazione di un servizio come autorizzato non è più sufficiente.
Un’applicazione approvata può essere utilizzata per un caso d’uso non consentito. Un agente legittimo può avere permessi eccessivi. Un sistema di retrieval-augmented generation (RAG) può recuperare documenti ai quali la persona che formula la domanda non dovrebbe accedere. Anche un modello personalizzato, addestrato su dati proprietari, può restituire informazioni fuori dal perimetro previsto.
Le interazioni AI vanno quindi valutate lungo quattro dimensioni: volume, direzione del flusso, gravità e intenzione. Un’esposizione accidentale causata da un dipendente che cerca di lavorare più velocemente richiede infatti una risposta diversa rispetto a un tentativo deliberato di aggirare i controlli.
Le violazioni upstream restano le più numerose
Le violazioni upstream, nelle quali un utente o un agente tenta di inviare dati sensibili a un sistema AI in contrasto con le policy aziendali, rappresentano 8.752 alert ogni 10.000. Nell’organizzazione media sono aumentate da 44 a 69 alla settimana.
I dati regolamentati e il codice sorgente pesano ciascuno per il 35% delle violazioni upstream. Seguono proprietà intellettuale, con il 20%, e password o chiavi di accesso, con il 10%. Queste ultime si trovano spesso all’interno di file di configurazione o frammenti di codice sottoposti ai modelli per attività di analisi e debugging.
Gli alert downstream sono molti meno, 924 ogni 10.000, quasi uno su dieci, ma costituiscono ormai la seconda categoria più comune. La loro crescita indica che l’esposizione non dipende più soltanto dal comportamento della persona che compone il prompt: può essere prodotta dall’architettura attraverso la quale l’AI raggiunge i dati.
MCP moltiplica le connessioni con dati e strumenti
Uno dei fattori alla base della trasformazione è il Model Context Protocol, standard aperto che permette alle applicazioni AI di collegarsi in modo uniforme a fonti di dati, strumenti e workflow esterni.
Un server MCP può mettere a disposizione file, database e funzioni operative. Il client utilizzato dall’agente può così recuperare informazioni o eseguire azioni senza richiedere un’integrazione specifica per ogni sistema.
In dieci settimane, il numero di utenti collegati a server MCP remoti è cresciuto del 250%, mentre le transazioni sono aumentate del 375%, quasi quadruplicando. La rilevazione comprende soltanto i server disponibili su Internet, non quelli eseguiti sul dispositivo dell’utente o all’interno della rete aziendale.
Il rischio non nasce dal protocollo in sé, ma da identità non propagate correttamente, risorse esposte con permessi troppo ampi e risposte non verificate rispetto al ruolo del destinatario. Le indicazioni di sicurezza del progetto MCP richiamano, tra gli altri aspetti, la protezione dei flussi di autorizzazione, la validazione degli input e la limitazione degli accessi.
Il coding agentico amplia i vettori di esecuzione
L’adozione delle applicazioni AI dedicate al codice è passata dal 42% all’84% delle organizzazioni in un anno. Claude Code risulta utilizzato nel 75% delle aziende osservate e Codex nel 58%. Dodici mesi prima entrambi registravano una presenza inferiore all’1%.
GitHub Copilot e Cursor, dominanti un anno fa, devono quindi confrontarsi con strumenti capaci di svolgere sequenze operative più articolate rispetto al semplice completamento del codice. Un agente può leggere molti file, modificare un progetto, usare il terminale, installare dipendenze e richiamare servizi esterni.
Queste capacità accelerano il lavoro, ma trasformano ogni risposta in un possibile vettore di esecuzione. Il codice malevolo costituisce appena 5 alert ogni 10.000, la categoria meno frequente fra quelle analizzate, ma è classificato come rischio critico: un comando dannoso potrebbe essere eseguito direttamente dall’agente oppure incorporato in una base di codice più ampia.
L’origine non deve necessariamente essere una richiesta esplicitamente pericolosa. Il codice può arrivare attraverso una prompt injection indiretta, uno strumento o un modello compromesso, dati di addestramento vulnerabili oppure un errore generato dal modello.
Ray Canzanese, Director di Netskope Threat Labs, sintetizza così il cambio di prospettiva: “Ogni interazione con un agente AI deve essere considerata un potenziale vettore di esecuzione, non soltanto una richiesta di dati”. Il controllo dei dati deve quindi estendersi all’integrità dell’intera supply chain AI.
Prompt injection e richieste di dati cambiano la gravità
Fra le categorie meno gravi ma più frequenti compaiono le violazioni dei filtri sui contenuti, con 154 alert ogni 10.000. Riguardano richieste o risposte incompatibili con le policy aziendali su contenuti inappropriati e pongono soprattutto problemi HR, legali e di conformità, più che minacce dirette a reti e dati.
Gli alert relativi a prompt injection e jailbreaking sono 129 ogni 10.000. Questi eventi si verificano quando un utente, un agente o un contenuto esterno tenta di sovvertire le istruzioni di sistema e aggirare le protezioni del modello. La prompt injection figura al primo posto fra i rischi individuati da OWASP per le applicazioni basate su modelli linguistici.
La variante indiretta è particolarmente rilevante per gli agenti: le istruzioni ostili possono essere nascoste in una pagina web, un documento o un’altra risorsa consultata durante l’esecuzione di un’attività. Se l’agente le interpreta come comandi, l’attacco può propagarsi ai servizi collegati.
Le richieste intenzionali di informazioni sensibili producono altri 28 alert ogni 10.000. In una semplice violazione downstream, il sistema può rivelare un dato senza che l’utente lo abbia cercato deliberatamente. Qui emergono invece segnali di ricognizione o raccolta intenzionale. La combinazione fra una richiesta sospetta e la successiva restituzione dei dati suggerisce che il tentativo abbia superato almeno una parte dei controlli.
Aumentano utenti, prompt e piattaforme
Nell’organizzazione mediana, la quota di utenti che adopera applicazioni AI almeno una volta alla settimana è salita dal 34% al 59%. Nel 25% delle aziende con l’adozione più elevata raggiunge almeno il 77%, mentre nel primo percentile si avvicina al 100%.
Il volume medio è triplicato, passando da 1.498 a 4.731 prompt settimanali per organizzazione. Nel quarto delle imprese più attive se ne registrano almeno 19.292; le realtà nel primo percentile arrivano a centinaia di migliaia. Una parte dell’aumento deriva dagli agenti, che possono produrre numerose interazioni durante l’esecuzione di un singolo compito.
Anche le piattaforme per creare applicazioni e agenti sono cresciute rapidamente, passando dal 51% al 92% delle organizzazioni. In parallelo, il 41% utilizza Ollama per eseguire modelli in locale, una scelta legata al controllo sui dati e alla riduzione dei costi cloud. L’esecuzione interna non elimina però i rischi derivanti da permessi eccessivi, prompt injection o accessi non correttamente separati.
La shadow AI si stabilizza, ma non scompare
Il 56% degli utenti AI osservati utilizza soltanto applicazioni gestite dall’organizzazione. Il 30% si affida esclusivamente a servizi personali e il restante 14% alterna strumenti aziendali e account privati.
La migrazione verso piattaforme amministrate si è fermata intorno a marzo 2026 e ha poi mostrato una lieve inversione. Le imprese sembrano orientarsi verso l’applicazione di guardrail anche ai servizi personali, invece di trasferire ogni caso d’uso su ambienti centralizzati.
Il perimetro della shadow AI, intanto, si è allargato. Oltre agli account personali comprende agenti non censiti, server MCP e infrastrutture locali, componenti difficili da individuare attraverso il solo inventario delle applicazioni SaaS.
Malware e link possono arrivare attraverso l’AI
Da marzo 2026 è aumentato il numero di utenti esposti a esche malevole con falsi marchi AI. Le campagne comprendono installer contraffatti, pagine di phishing e strumenti per sviluppatori compromessi da trojan.
Un secondo rischio riguarda i collegamenti dannosi restituiti direttamente dalle applicazioni AI. Come nei motori di ricerca, gli aggressori possono cercare di far emergere i propri contenuti attraverso tecniche di ottimizzazione, inserzioni o la compromissione di infrastrutture legittime. Gli eventi rilevati hanno oscillato da meno di 10 a più di 90 alla settimana.
La differenza è che un link può essere visitato da un agente senza l’intervento diretto dell’utente. La stessa automazione che rende produttivo il sistema può quindi ridurre il tempo disponibile per riconoscere e bloccare un contenuto pericoloso.
La sicurezza deve seguire l’intera transazione
La strategia si articola su tre livelli. La visibilità deve comprendere applicazioni gestite, shadow AI, infrastrutture locali e traffico MCP. La governance deve stabilire chi possa usare ogni applicazione, per quale attività e con quali dati. La protezione deve intervenire in tempo reale su prompt, risposte e azioni eseguite dagli agenti.
| Rischio | Visibilità | Governance | Protezione |
| Violazione upstream | Convogliare tutte le interazioni AI, soprattutto quelle con servizi shadow, attraverso un gateway o proxy centralizzato. | Incrociare applicazioni e casi d’uso autorizzati, con regole specifiche per codice sorgente, dati regolamentati e proprietà intellettuale. | Applicare controlli DLP in tempo reale ai dati inviati, distinguendo i trasferimenti consentiti da quelli incompatibili con il caso d’uso. |
| Violazione downstream | Ispezionare le risposte e rendere visibile il traffico MCP, non soltanto i prompt in uscita. | Associare gruppi di utenti e agenti ai livelli di accesso necessari, applicando il principio del privilegio minimo anche alle fonti collegate. | Verificare in tempo reale che i dati restituiti siano accessibili al destinatario e coerenti con l’attività autorizzata. |
| Content filtering | Analizzare sia le richieste sia le risposte, comprese quelle generate da applicazioni personali. | Allineare le regole alle policy HR, ai requisiti legali e alle norme di utilizzo accettabile valide nelle diverse aree geografiche. | Combinare guardrail sensibili al contesto e filtri per parole chiave, evitando di affidarsi a un solo tipo di rilevazione. |
| Prompt injection e jailbreaking | Monitorare anche modelli locali, agenti e contenuti esterni acquisiti durante l’esecuzione di un compito. | Sottoporre l’infrastruttura AI a una verifica dell’isolamento e dei guardrail prima della distribuzione. | Affiancare analisi semantica, behavioral analytics, protezione dei dati e ispezione del codice restituito. |
| Richieste di dati sensibili | Conservare un audit dei prompt e delle operazioni compiute dall’agente. | Assegnare responsabilità chiare sulle risorse e separare archivi, strumenti e contesti che non devono essere interrogati insieme. | Rilevare i tentativi di ricognizione con guardrail semantici, DLP e analisi del comportamento, correlando richieste e risposte. |
| Copyright e pirateria | Ispezionare i contenuti downstream, inclusi testo e codice generati. | Definire quali modelli e applicazioni possano produrre codice, testi e altri materiali destinati al riutilizzo. | Confrontare gli output con firme di software open source e repertori di marchi, limitando i casi d’uso non approvati. |
| Codice malevolo | Controllare tutto il codice e i comandi restituiti prima che raggiungano ambienti eseguibili. | Adottare una validazione zero trust nelle pipeline CI/CD e regole di sicurezza per modelli, strumenti, pacchetti e dipendenze. | Scansionare risposte e build, quindi usare behavioral analytics per individuare ricognizione, comunicazioni command-and-control ed esfiltrazione successive all’esecuzione. |
Un gateway centralizzato non sostituisce i controlli applicativi, le autorizzazioni sulle fonti o la sicurezza della supply chain: offre il punto di osservazione dal quale applicarli in modo coerente. Allo stesso modo, i guardrail semantici devono essere affiancati da verifiche deterministiche, registri di audit e controlli sul comportamento successivo all’interazione.
MITRE ATLAS e l’OWASP Top 10 per le applicazioni LLM aiutano a classificare gli attacchi e a collegarli ai controlli tecnici. Il punto operativo è considerare un agente non come un semplice chatbot, ma come un componente software che attraversa sistemi, recupera dati e compie azioni. La sicurezza deve seguirne l’intera attività: dalla richiesta iniziale alle fonti consultate, fino al contenuto restituito e alle operazioni effettivamente eseguite.
