L’IA aziendale sommerge i SOC di avvisi innocui e nasconde i rischi reali

Gli avvisi legati all’IA sono aumentati del 685% in quattro mesi

L’adozione aziendale dell’IA generativa sta creando un nuovo problema per le operations di sicurezza: gli strumenti legittimi si comportano sempre più spesso come software che le regole di rilevamento dei SOC erano progettate per intercettare.

Una recente analisi di circa 16,9 milioni di avvisi dei SOC ne ha identificati circa 73.000 legati ad attività di IA, pari allo 0,43% del totale. La percentuale resta contenuta, ma il volume sottostante è aumentato ogni mese del periodo esaminato.

Nel periodo di rilevazione stabile, da febbraio a giugno 2026, gli avvisi legati all’IA sono aumentati del 685%. L’accelerazione è stata particolarmente marcata a maggio 2026, a indicare che lo 0,43% rappresenta un punto di partenza, non una quota stabile del carico di lavoro dei SOC.

Gli avvisi rientravano in tre categorie nettamente sbilanciate:

• Il 94,1% era rumore di rilevamento, solitamente dovuto ad azioni legittime di agenti IA classificate erroneamente dai controlli di sicurezza esistenti.
• Il 5,8% rappresentava un rischio concreto per la sicurezza, incluse configurazioni non sicure o automazioni potenzialmente pericolose, senza prove di compromissione.
• Lo 0,02% corrispondeva ad attacchi confermati, principalmente phishing e frodi che sfruttavano l’interesse per i prodotti di IA.

Il problema immediato, quindi, non è un’epidemia di attaccanti che compromettono gli agenti di programmazione aziendali. È piuttosto lo scontro tra software autonomo e logiche di rilevamento progettate per un mondo in cui ogni comando sensibile veniva avviato da una persona, da uno script o da un processo malware.

Questo scontro assorbe capacità investigative. Può inoltre nascondere il gruppo più ristretto di eventi che coinvolgono credenziali esposte, esecuzione senza restrizioni, autorizzazioni OAuth rischiose e attività di social engineering reali.

Gli agenti di programmazione assomigliano sorprendentemente agli intrusi

Gli agenti di programmazione moderni fanno molto più che generare testo. A seconda della configurazione e dell’attività assegnata, possono avviare shell di comandi, installare pacchetti, esaminare credenziali, eseguire utility di sicurezza, manipolare file ed esporre servizi di sviluppo a reti esterne.

Ogni singola azione può essere legittima. Nel loro insieme, però, possono assomigliare alle fasi di discovery, accesso alle credenziali e command and control di un’intrusione.

Un cliente ha incontrato questo problema con il binario Windows Expand.exe. Un rilevamento relativo al trasferimento laterale di strumenti che coinvolgeva l’eseguibile ha prodotto il 55% di tutti gli avvisi classificati come “critici” nel campione analizzato. L’indagine ha rilevato che l’agente di programmazione di uno sviluppatore stava configurando un ambiente shell, non trasferendo strumenti dell’attaccante.

Anche le applicazioni degli stessi fornitori di IA hanno attivato rilevamenti gravi. Un installer autentico e correttamente firmato di Anthropic Claude Desktop ha attivato, presso diverse organizzazioni, regole EDR etichettate “Ransomware Operations detected” e “Encoded PowerShell Download and Run”.

Non sono state rese note le versioni dei prodotti Claude Desktop, Cursor o delle altre applicazioni di IA osservate. Di conseguenza, i risultati non devono essere interpretati come l’identificazione di una vulnerabilità limitata a una specifica release. Riguardano il comportamento delle applicazioni, la configurazione degli utenti e i controlli di sicurezza che circondano l’esecuzione dell’IA.

La gravità era una scorciatoia poco affidabile per determinare l’intento. Una classificazione critica può indicare un comando tecnicamente pericoloso, ma non stabilisce chi lo abbia richiesto, perché sia stato eseguito o se fosse presente un attaccante.

Gli analisti dei SOC hanno ora bisogno del contesto di esecuzione che spesso manca ai rilevamenti endpoint tradizionali. Questo include il processo padre dell’agente, l’attività dell’utente, il repository interessato, la cronologia dei comandi, la modalità delle autorizzazioni e gli eventuali contenuti non attendibili elaborati prima dell’avvio dell’attività.

L’automazione non sicura crea esposizione senza una violazione

Il 5,8% classificato come rischio concreto è probabilmente il gruppo più rilevante dal punto di vista operativo. Non si trattava di compromissioni confermate, ma gli eventi hanno creato condizioni che potevano esporre sistemi o credenziali.

La fonte principale erano gli agenti di programmazione avviati con le protezioni sulle autorizzazioni disattivate. In questa modalità, l’agente può eseguire comandi senza chiedere all’utente di approvare ogni azione sensibile.

Ogni invocazione analizzata con l’elusione delle autorizzazioni era associata ad attività di sviluppo legittime. Questo non rende sicura la configurazione. Significa che le organizzazioni stanno rimuovendo sistematicamente un controllo che potrebbe interrompere comandi distruttivi o finalizzati al furto di credenziali.

Un agente operativo senza richieste di conferma può rimanere innocuo mentre lavora su codice attendibile. Il rischio cambia quando elabora un repository dannoso, istruzioni manipolate, documentazione controllata da un attaccante o altri input non attendibili. Un incidente di supply chain documentato pubblicamente aveva già dimostrato come, in questa condizione, fosse possibile eseguire codice dannoso senza restrizioni.

Quando l’esecuzione automatica non presidiata è necessaria, le organizzazioni dovrebbero aggiungere misure di sicurezza programmatiche, spesso chiamate harness, che applichino le policy in modo indipendente dal modello. Questi controlli possono bloccare l’estrazione di credenziali, limitare i tunnel in uscita, circoscrivere i percorsi scrivibili e richiedere l’approvazione per i comandi ad alto rischio.

Diversi comportamenti osservati mostrano perché questo sia importante.

In un ambiente, un editor di codice basato sull’IA ha avviato PowerShell, che a sua volta ha eseguito ngrok e creato un tunnel inverso denominato utilizzando il token di autenticazione dello sviluppatore. L’intento apparente era innocuo, ma il risultato è stato un collegamento raggiungibile dall’esterno verso un sistema di sviluppo.

In un altro caso, un agente ha tentato di recuperare il proprio token e le credenziali cloud eseguendo:

security dump-keychain > /tmp/

Invece di estrarre un singolo segreto necessario, il comando ha scritto il contenuto del portachiavi macOS in una posizione temporanea. Un’attività di autenticazione circoscritta si è così trasformata in un’esposizione estesa delle credenziali.

È stato inoltre osservato che Cursor avviava una catena di processi più grave:

Cursor.exe → powershell.exe → rundll32.exe

La sequenza utilizzava la funzionalità MiniDump di comsvcs.dll, script PowerShell temporanei e comandi per il dump della memoria. Potrebbe essere stata generata durante attività di debugging, ma la tecnica può esporre credenziali e altri segreti conservati nella memoria dei processi.

Questi casi non possono essere liquidati con sicurezza come falsi positivi. Si tratta di attività legittime con conseguenze simili a quelle di un attacco.

L’esposizione dei dati è più silenziosa dell’esecuzione sull’endpoint

Non tutti i rischi legati all’IA aziendale producono un albero di processi sospetto. I dipendenti collegano inoltre applicazioni di IA di terze parti tramite OAuth, si autenticano con identità aziendali e caricano informazioni di lavoro su servizi di IA generativa.

Tra le attività analizzate figuravano consensi OAuth concessi a ChatGPT in più tenant, oltre a eventi “First sign-in to a new application: OpenAI”. Un cliente ha inoltre generato un gruppo consistente di avvisi di protezione dei dati relativi a caricamenti su piattaforme di IA generativa.

La maggior parte degli eventi era innocua, ma l’autorizzazione non elimina l’esposizione. Le concessioni OAuth possono permettere a un provider esterno di leggere dati aziendali, mentre un account IA compromesso o un percorso di prompt injection potrebbe abusare delle autorizzazioni già esistenti.

I caricamenti presentano un problema di visibilità diverso. Una piattaforma EDR può osservare un agente di programmazione che avvia rundll32.exe, ma potrebbe non riconoscere il testo sensibile incollato in un servizio di IA accessibile tramite browser. Le organizzazioni hanno quindi bisogno della telemetria relativa a identità, SaaS e protezione dei dati, oltre al monitoraggio degli endpoint.

I team SOC dovrebbero esaminare l’ampiezza delle concessioni OAuth legate all’IA, identificare gli eventi di primo utilizzo e stabilire se il dipendente avesse una motivazione aziendale per autorizzare l’applicazione. Le policy di governance dei dati dovrebbero inoltre definire quali informazioni possono essere inviate a modelli esterni e come individuare le violazioni.

Gli attacchi reali hanno usato l’IA come esca, non come exploit

Le attività dannose confermate rappresentavano circa lo 0,02% degli avvisi legati all’IA. Nessuna delle compromissioni rilevate è stata attribuita all’agente IA di un’organizzazione.

Gli avvisi che inizialmente sembravano mostrare un agente mentre eseguiva Mimikatz, apriva una shell inversa o sottraeva credenziali sono stati infine ricondotti ad attività di sviluppo legittime o a comportamenti innocui classificati erroneamente dalle regole di rilevamento.

Gli attaccanti reali hanno invece sfruttato la credibilità di marchi IA conosciuti.

Un’email di frode nei pagamenti utilizzava l’oggetto “RE: Anthropic Engagement approval & payment” per sostenere una storia inventata su un contratto o una fattura. Anthropic forniva il pretesto, ma non era il mittente né la fonte dell’attacco.

Un’altra campagna imitava un invito a un workspace Google/Gemini Ads. L’infrastruttura del mittente e quella per le risposte non erano collegate a Google, e il messaggio indirizzava i destinatari verso il dominio sospetto:

gemini-advertisers[.]com

Il marchio OpenAI compariva in un invito fraudolento all’“OpenAI Partner Summit 2026”, inviato da [email protected]. L’infrastruttura Zoom legittima contribuiva a rendere credibile la procedura di registrazione. Il marchio OpenAI è stato utilizzato anche in uno scenario di phishing basato su device code.

Questi incidenti richiedono una distinzione analitica chiara. Un avviso che menziona un prodotto di IA può descrivere l’esecuzione di un agente, un’automazione non sicura, un’applicazione esterna che riceve dati oppure un attaccante estraneo che sfrutta un marchio riconoscibile.

Ai SOC serve una soppressione basata sul contesto, non eccezioni generalizzate

L’automazione ha già gestito la maggior parte del volume osservato. La piattaforma di triage ha assegnato un verdetto innocuo al 79,8% degli avvisi legati all’IA e ne ha soppresso automaticamente l’81,7%. Solo il 5,4% è arrivato a un analista umano, mentre i restanti avvisi sono stati conservati per ulteriori verifiche.

Questi dati mostrano che il triage automatizzato è necessario, ma che consentire tutto indiscriminatamente sarebbe pericoloso. La stessa shell, lo stesso tunnel o lo stesso comando di accesso alle credenziali possono rappresentare attività di sviluppo ordinaria, un comportamento non sicuro dell’agente o una compromissione in corso.

I team di sicurezza dovrebbero invece ottimizzare i controlli in base a un contesto specifico:

1. Definire una baseline degli strumenti IA approvati e degli alberi di processo attesi. Agli installer firmati e ai workflow noti degli agenti può essere assegnata una priorità inferiore, senza esentare ogni processo figlio.
2. Rilevare l’esecuzione con elusione delle autorizzazioni. Le sessioni degli agenti senza restrizioni devono essere inventariate, limitate e monitorate separatamente.
3. Preservare la visibilità sui comandi ad alto rischio. I dump della memoria, le esportazioni del portachiavi, i tunnel inversi e l’accesso agli archivi delle credenziali richiedono comunque una verifica, anche quando sono stati avviati da un agente IA.
4. Correlare la telemetria degli endpoint con quella delle identità. I consensi OAuth, gli accessi iniziali a nuove applicazioni IA e i caricamenti di dati anomali possono rivelare rischi che l’EDR non è in grado di vedere.
5. Formare i dipendenti sulle frodi a tema IA. Le richieste di pagamento, gli inviti a workspace, le registrazioni a conferenze e le richieste di device code devono essere verificate al di fuori del messaggio ricevuto.
6. Misurare la crescita, non solo la quota attuale. Una categoria cresciuta del 685% da febbraio a giugno 2026 non può essere gestita in base al volume precedente.

Il compito centrale non è rilevare se sia stata coinvolta l’IA. I SOC devono stabilire se l’attività fosse prevista, pericolosamente sovra-autorizzata o dannosa, e farlo prima che l’automazione innocua seppellisca il segnale.