Gli alert AI SOC di Intezer sono aumentati vertiginosamente, ma quasi tutti erano rumore

Gli alert AI SOC di Intezer sono aumentati del 685% da febbraio a giugno 2026, pur rappresentando appena lo 0,43% degli avvisi di sicurezza analizzati nello studio. Il contrasto è già evidente. L'AI aziendale non ha prodotto l'ondata di violazioni guidate da agenti che molti team di sicurezza temevano. Ha invece generato un flusso in rapida crescita di attività legittime che spesso assomigliano a un'intrusione.

Intezer ha esaminato circa 16,9 milioni di alert in diversi ambienti aziendali. Circa 73.000 riguardavano strumenti o agenti AI. I ricercatori li hanno classificati per il 94,1% come rumore, per il 5,8% come rischi di sicurezza reali e solo per lo 0,02% come attacchi effettivi.

Questo squilibrio contrappone una logica di rilevamento consolidata al normale lavoro assistito dall'AI. Claude, Codex, Cursor, ChatGPT e strumenti simili possono avviare processi, gestire file, invocare shell e connettersi a servizi. Queste azioni ricordano il comportamento di un attaccante quando vengono osservate senza considerare l'intento dell'utente.

Il risultato non è semplicemente più lavoro per un security operations center, o SOC. È un problema di contesto. I team devono distinguere l'attività legittima degli agenti da comportamenti non sicuri prima che i falsi allarmi nascondano le esposizioni rilevanti.

Gli alert AI SOC di Intezer sono cresciuti più rapidamente di quanto suggerisca la loro quota

Il dato importante non è l'attuale quota dell'AI sul volume degli alert. È la velocità e la composizione di questa crescita.

Secondo lo studio sugli alert AI di Intezer, l'attività correlata all'AI ha generato circa 73.000 dei 16,9 milioni di alert esaminati. Ciò rende la categoria piccola rispetto agli alert su endpoint, identità, email, cloud e rete che già raggiungono i SOC aziendali.

Tuttavia, il volume mensile legato all'AI è aumentato durante tutto il periodo di rilevazione stabile. Intezer ha misurato una crescita del 685% tra febbraio e giugno 2026. L'azienda ha descritto l'andamento come monotono, ovvero ogni mese completo superava quello precedente.

Questa traiettoria conta perché l'adozione aziendale non richiede una distribuzione formale a livello dell'intera organizzazione. I dipendenti possono connettere un chatbot consumer tramite OAuth, che consente a un'applicazione di accedere alle risorse approvate di un account. Gli sviluppatori possono installare agenti di coding che iniziano immediatamente a interagire con i sistemi locali.

Ogni azione aggiunge una nuova fonte di telemetria. Può inoltre attivare regole create anni prima che gli agenti generalisti iniziassero a operare sui computer dei dipendenti.

Intezer ha suddiviso gli alert risultanti in tre categorie. Il rumore comprendeva attività legittime che attivavano un rilevamento esistente. Il rischio di sicurezza comprendeva comportamenti non sicuri o esposizioni senza una compromissione confermata. Gli attacchi reali richiedevano prove di un'operazione effettiva condotta da un attaccante.

Il rumore ha dominato con il 94,1%. I rischi di sicurezza hanno rappresentato il 5,8%, mentre gli attacchi confermati circa lo 0,02%. Queste classificazioni derivano dalla piattaforma e dalla metodologia di Intezer, quindi studi indipendenti potrebbero produrre rapporti diversi.

I dati sulla gestione interna hanno mostrato un ulteriore livello dello stesso schema. Intezer ha dichiarato che il 79,8% degli alert legati all'AI ha ricevuto un verdetto benigno. Il suo sistema automatizzato ne ha soppresso l'81,7%, chiudendoli senza presentarli a un analista umano.

Solo il 5,4% è stato sottoposto a escalation verso un analista. Gli alert rimanenti sono stati segnalati per un follow-up anziché essere trattati immediatamente come incidenti.

Questi risultati supportano il triage automatizzato, ma evidenziano anche una dipendenza. L'automazione deve comprendere la relazione tra un agente, il suo utente e l'attività eseguita. Il solo nome di un processo o un comando raramente fornisce quel contesto.

Un cliente ha generato, tramite un singolo rilevamento, il 55% di tutti gli alert critici correlati all'AI nel dataset. La regola identificava il binario Windows Expand.exe come possibile strumento di trasferimento laterale.

Un'analisi più approfondita ha rilevato che un agente di coding stava preparando un ambiente shell. L'attività era normale per quel flusso di lavoro, anche se i singoli segnali tecnici assomigliavano al comportamento di un attaccante.

Un'etichetta di gravità tradizionale avrebbe collocato questi alert vicino all'inizio della coda di un analista. Il contesto li ha spostati verso la chiusura automatica. Questa differenza diventa costosa quando lo stesso schema si ripete su migliaia di endpoint.

Lo studio non dimostra che tutti gli alert AI ad alta gravità siano innocui. Dimostra che la gravità perde significato quando la logica di rilevamento non riesce a riconoscere il normale comportamento degli agenti.

Questo è il primo cambiamento operativo per i responsabili SOC. L'attività AI richiede una propria baseline, inclusi strumenti approvati, processi padre previsti, destinazioni abituali e azioni consentite. Senza questa baseline, la crescita dell'adozione diventa crescita di un'urgenza falsa.

L'adozione dell'AI a livello aziendale cambia la forma del flusso di alert

L'AI aziendale crea contemporaneamente due flussi di sicurezza: l'esecuzione rumorosa degli agenti e il movimento silenzioso dei dati aziendali.

Il flusso rumoroso proviene principalmente dagli utenti tecnici. Gli agenti di coding possono creare script, avviare interpreti, installare pacchetti, ispezionare repository, aprire porte o eseguire strumenti di sviluppo. Ogni azione può assomigliare a una fase di un'intrusione.

Uno sviluppatore potrebbe chiedere a un agente di avviare un server di test locale. L'agente potrebbe avviare PowerShell, individuare una porta inutilizzata, eseguire Python e reindirizzare l'output nei log del progetto. Un prodotto endpoint rileva una catena di processi insolita prima di rilevare un obiettivo di sviluppo benigno.

Intezer ha rilevato che un binario sandbox firmato di OpenAI Codex produceva questo schema. PowerShell avviava quindi cmd.exe, python.exe e conhost.exe durante la preparazione di un ambiente di progetto locale.

Una regola convenzionale ha interpretato la sequenza come una possibile reverse shell. Il testo del comando mostrava invece un'orchestrazione locale su 127.0.0.1, l'indirizzo di loopback utilizzato per raggiungere lo stesso computer.

Gli installer creano collisioni simili. Intezer ha riferito che il legittimo installer di Claude Desktop ha attivato rilevamenti associati al comportamento ransomware e all'esecuzione PowerShell codificata. La firma del codice ha confermato l'identità del pacchetto, ma le regole comportamentali hanno comunque trattato la sequenza di installazione come sospetta.

Ciò non rende obsoleto il rilevamento comportamentale. Il software firmato può diventare dannoso e le applicazioni affidabili possono essere sfruttate. Significa che il rilevamento necessita di contesto a supporto prima che un analista possa attribuire un intento.

Il flusso silenzioso deriva dall'adozione non tecnica. I dipendenti possono concedere a un servizio AI l'accesso ad account aziendali, caricare documenti o incollare materiale sensibile nei prompt. Queste azioni potrebbero non creare mai un processo endpoint insolito.

Intezer ha osservato autorizzazioni OAuth concesse a ChatGPT in più tenant. Ha inoltre rilevato i primi accessi a un'applicazione OpenAI e un gruppo di alert di protezione dei dati relativi a caricamenti su AI generativa presso un cliente.

La maggior parte degli eventi era benigna. Tuttavia, rappresentavano informazioni aziendali trasferite verso servizi al di fuori del controllo immediato dell'endpoint.

Questa distinzione spiega perché bloccare alcuni eseguibili non può risolvere la sicurezza dell'AI aziendale. Una parte del rischio risiede nei processi. Un'altra risiede nelle sessioni del browser, nelle autorizzazioni di identità, nelle integrazioni software e nei flussi di dati.

Un inventario utile necessita quindi di qualcosa in più di un elenco di applicazioni approvate. Deve collegare utenti, identità, agenti, estensioni, concessioni OAuth, destinazioni dei dati e le risorse a cui ogni strumento può accedere.

Questo lavoro va oltre il SOC. I team identity gestiscono consenso e accesso. I team di data governance definiscono le informazioni sensibili. I responsabili engineering decidono quali configurazioni degli agenti siano accettabili.

I team procurement e legale valutano i termini di gestione da parte di terzi. I responsabili aziendali stabiliscono se i dipendenti dispongano di alternative approvate realmente utilizzabili.

Il SOC resta il punto in cui questi segnali convergono. Riceve gli alert quando uno strumento avvia un comando sospetto, apre un tunnel o accede a informazioni protette.

L'adozione a livello aziendale cambia anche il significato dell'attribuzione. Prima degli agenti generalisti, un comando eseguito con l'account di un utente rifletteva di norma l'utente stesso o un attaccante che controllava quell'account.

Un agente introduce un terzo attore. Opera con l'autorità dell'utente, ma può selezionare comandi che l'utente non ha mai esaminato. L'attività appartiene all'account senza riflettere pienamente l'azione diretta del titolare dell'account.

Questo divario è particolarmente importante per le timeline degli incidenti. Gli analisti devono sapere se un umano ha digitato un comando, se lo ha generato un agente approvato o se contenuti dannosi hanno manipolato l'agente.

I team di sicurezza necessitano inoltre di un contesto organizzativo duraturo. Una base di conoscenza engineering ricercabile può preservare flussi di lavoro approvati e decisioni tecniche locali. Tuttavia, la documentazione deve collegarsi alle attuali evidenze di identità ed endpoint per supportare il triage.

L'obiettivo operativo non è una visibilità perfetta su ogni prompt. È disporre di abbastanza contesto verificato per separare il lavoro approvato, il comportamento non sicuro e l'attività avversaria senza sorvegliare i dipendenti più del necessario.

La logica di rilevamento legacy entra in conflitto con il normale comportamento degli agenti

La competizione principale è tra la logica di rilevamento legacy e il contesto degli agenti AI, non tra analisti umani e automazione.

I prodotti di sicurezza spesso rilevano tecniche anziché intenti. Accesso alle credenziali, esecuzione di comandi, persistenza, tunneling e raccolta dati restano pericolosi indipendentemente dall'applicazione che li avvia.

Gli agenti AI complicano questo modello perché gli strumenti legittimi ora eseguono combinazioni un tempo associate soprattutto ad amministratori, penetration tester e attaccanti. La sovrapposizione è strutturale, non accidentale.

Intezer ha rilevato tassi di benignità dal 77% al 99% tra i gruppi di rilevamento AI più rumorosi. Diverse regole erano errate sul comportamento generato dall'AI più di quattro volte su cinque.

Un esempio riguardava OpenAI Codex avviato tramite Node.js con flag come --yolo o --dangerously-skip-permissions. L'attività risultante ha attivato rilevamenti relativi a ClickFix, strumenti disabilitati e DLL injection.

I flag di bypass delle autorizzazioni rimuovono le richieste di approvazione prima che un agente intraprenda azioni. Gli sviluppatori li usano per ridurre le interruzioni, ma la stessa comodità indebolisce un importante confine di controllo.

Il cluster ClickFix è stato un'eccezione nei risultati di Intezer sul rumore. Solo il 37% di quegli alert era benigno. Questo risultato non rende ogni alert un attacco, ma attribuisce al cluster un maggiore valore investigativo.

Qui è dove le semplici allowlist falliscono. Dichiarare affidabili Codex, Claude o Cursor ridurrebbe il rumore, ma potrebbe anche nascondere azioni non sicure avviate tramite tali strumenti.

L'approccio più sicuro valuta l'intera catena. Il SOC dovrebbe considerare l'applicazione firmata, l'utente che avvia l'azione, la configurazione dell'agente, l'attività richiesta, i processi figlio, le risorse a cui si accede, la destinazione di rete e il conseguente movimento dei dati.

La matrice delle minacce AI di MITRE riflette questa visione più ampia. Include invocazione di strumenti da parte di agenti, raccolta di credenziali, prompt injection, reverse shell ed esfiltrazione tramite meccanismi legati all'AI.

Queste tecniche spiegano perché un agente approvato non può ricevere una fiducia generale permanente. Lo strumento può essere legittimo, mentre una specifica invocazione può restare non sicura.

Il detection engineering deve quindi diventare più condizionale. Un server locale avviato all'interno di un noto repository di sviluppo può essere ordinario. Lo stesso interprete che crea un tunnel esterno da una workstation finance merita un trattamento diverso.

Un agente di coding che legge il proprio token di configurazione può essere previsto. Scaricare l'intero portachiavi macOS in un file temporaneo non è proporzionato a quell'attività.

Intezer ha osservato esattamente questo schema. Un agente ha usato security dump-keychain e ha reindirizzato l'output a una posizione temporanea nel tentativo di recuperare credenziali memorizzate.

L'attività prevista non richiedeva intenti malevoli. Il metodo scelto ha comunque esposto più informazioni del necessario e ha creato un bersaglio di valore sul disco.

Un altro caso ha riguardato un editor di codice AI che ha avviato PowerShell e poi ngrok, un servizio che crea tunnel accessibili da internet. Ha aperto un tunnel inverso con nome usando il token di autenticazione del dipendente.

Lo scopo dell'utente poteva essere una legittima attività di troubleshooting o sviluppo. Eppure, l'azione ha creato un percorso reale dall'internet pubblico verso un ambiente aziendale.

Un terzo esempio ha riguardato Cursor, che ha avviato una catena di processi basata su un noto metodo di dump della memoria. Cursor ha avviato PowerShell, che ha chiamato rundll32.exe e la funzionalità MiniDump in comsvcs.dll.

Questa tecnica può estrarre segreti dalla memoria dei processi. Anche quando un agente la seleziona per il debugging, il comportamento crea un rischio di accesso alle credenziali che merita un'indagine.

Questi esempi sostengono una policy basata su azioni e confini, non soltanto sui nomi dei prodotti. Anche gli agenti approvati dovrebbero affrontare restrizioni su archivi di credenziali, sistemi di produzione, tunnel pubblici e repository sensibili.

L'isolamento può essere utile. Intezer raccomanda di eseguire gli strumenti AI in ambienti vincolati, inclusi container o macchine virtuali, quando il flusso di lavoro lo consente.

Un container raggruppa un processo con risorse e limiti di accesso definiti. Una macchina virtuale fornisce un ambiente operativo separato con un isolamento più forte in molte configurazioni.

Nessuno dei due controlli è assoluto. I container possono essere configurati in modo errato, mentre le macchine virtuali necessitano comunque di controlli su identità, rete, archiviazione e aggiornamenti. Entrambi possono ridurre il numero di risorse che un agente raggiunge per impostazione predefinita.

Migliorano anche l'attribuzione. L'attività che ha origine all'interno di un ambiente assegnato a un agente è più semplice da distinguere dalla normale attività desktop di un utente.

Il cambiamento richiede misurazioni accurate. I team dovrebbero monitorare i tassi di falsi positivi per rilevamento, agente, configurazione e unità aziendale. Dovrebbero inoltre registrare quali soppressioni hanno richiesto successivamente una correzione.

Una riduzione generalizzata del volume di avvisi non equivale al successo. La misura utile è se l'ottimizzazione elimina il rumore prevedibile senza nascondere l'accesso alle credenziali, l'esposizione esterna o lo spostamento di dati sensibili.

I rischi silenziosi della sicurezza AI contano più degli avvisi più rumorosi

I rischi AI più rilevanti nei dati di Intezer erano spesso esposizioni, non compromissioni confermate o avvisi di massima gravità.

Intezer ha classificato il 5,8% della popolazione correlata all'AI come rischi di sicurezza autentici. Questi eventi non dimostravano che un attaccante avesse ottenuto accesso. Mostravano condizioni che avrebbero potuto rendere più dannosa una compromissione successiva.

L'aggiramento delle autorizzazioni era un esempio centrale. Un agente che opera senza prompt di approvazione può eseguire una lunga sequenza prima che un utente ne veda i dettagli.

Questo design diventa più pericoloso quando l'agente legge codice, siti web, ticket, email o documenti non attendibili. Istruzioni malevole nascoste in tali fonti possono influenzare le scelte dell'agente.

La prompt injection è un tentativo di indurre un modello a seguire istruzioni ostili incorporate nel suo input. Diventa più seria quando un agente può utilizzare strumenti o accedere a dati aziendali.

Un'iniezione indiretta può arrivare attraverso contenuti che l'utente non considera affatto un'istruzione. Una pagina web o un file del repository può contenere testo destinato all'agente anziché al lettore umano.

Il profilo sull'AI generativa del NIST raccomanda di governare, mappare, misurare e gestire i rischi AI durante l'intero ciclo di vita del sistema. Questo modello si adatta agli agenti aziendali perché il rischio attraversa confini tecnologici e organizzativi.

Un avviso endpoint potrebbe rivelare il comando finale senza cogliere il contenuto che ha influenzato il modello. Un registro delle identità potrebbe rivelare una concessione OAuth senza mostrare quali documenti siano successivamente entrati nel servizio.

Un prodotto di prevenzione della perdita di dati potrebbe rilevare un caricamento, ma non conoscerne lo scopo aziendale. Ogni strumento osserva un solo frammento dell'evento.

Il SOC necessita di correlazione tra questi frammenti. Dovrebbe collegare utente, agente, fonte del prompt, autorizzazioni, attività dei processi, destinazione e classificazione dei dati quando la telemetria disponibile lo consente.

Questo non richiede di raccogliere ogni conversazione dei dipendenti. Privacy e proporzionalità restano importanti. Le organizzazioni dovrebbero acquisire la quantità minima di evidenze necessaria per applicare le policy consolidate e indagare rischi significativi.

Una policy chiara è importante anche perché la stessa azione può avere conseguenze diverse nei vari reparti. Caricare testi pubblici di marketing è diverso dal caricare dati dei clienti, informazioni finanziarie non pubblicate o codice sorgente contenente segreti.

Gli strumenti approvati non eliminano questa differenza. Le licenze enterprise possono migliorare i controlli amministrativi, ma non possono stabilire se ogni dato sia appropriato per ogni prompt.

Il consenso OAuth merita un'attenzione analoga. OAuth consente a un utente di autorizzare un'applicazione senza consegnare una password. Il token risultante può comunque fornire un accesso sostanziale a email, file, calendari o altri servizi.

Gli ambiti richiesti da un'applicazione AI legittima possono eccedere l'attività immediata. Un account compromesso o un agente manipolato può quindi usare tali autorizzazioni in modi che il dipendente non aveva mai previsto.

I team SOC dovrebbero esaminare le concessioni di consenso ad alto rischio, le applicazioni insolite usate per la prima volta e le autorizzazioni che attraversano sistemi sensibili. Dovrebbero inoltre offrire agli utenti un percorso rapido per richiedere integrazioni approvate.

Se la governance procede troppo lentamente, i dipendenti la aggireranno. Ciò crea shadow AI, ossia strumenti o utilizzi che operano al di fuori dell'approvazione e della supervisione organizzativa stabilite.

La risposta non è un divieto indiscriminato. Un divieto può ridurre l'attività visibile spingendo al contempo il lavoro utile verso account personali e sessioni browser non gestite.

I team di sicurezza necessitano di un percorso autorizzato e pratico, con controlli appropriati. I dipendenti dovrebbero sapere quali strumenti possono usare, quali informazioni possono condividere e quando un agente necessita di un ambiente isolato.

CISA e partner internazionali hanno posto un'enfasi simile su responsabilità, trasparenza e progettazione sicura nelle loro linee guida sulla sicurezza AI. Questi principi si applicano ai fornitori, ma anche gli acquirenti aziendali devono valutarli.

Le domande di procurement dovrebbero riguardare logging, conservazione, addestramento dei modelli, ambiti di accesso, controlli amministrativi, notifica degli incidenti e cancellazione dei dati. I test tecnici dovrebbero verificare le dichiarazioni importanti ove possibile.

I playbook SOC devono quindi tradurre la policy in passaggi investigativi. Un analista che rileva un tunnel sconosciuto dovrebbe poter identificare rapidamente l'agente, l'utente, l'attività e la destinazione responsabili.

Il playbook non dovrebbe chiudere automaticamente l'evento perché lo ha avviato uno strumento approvato. Dovrebbe determinare se l'azione è rimasta entro un confine approvato.

Lo stesso principio si applica all'accesso alle credenziali. Un agente che legge un segreto limitato tramite un broker approvato è diverso dall'esportare un intero archivio di credenziali.

Questo modello incentrato sulle azioni preserva rilevamenti utili riducendo al contempo il rumore evitabile. Inoltre, allinea gli avvisi ai rischi che l'organizzazione ha effettivamente deciso di gestire.

Cosa i dati di Intezer non dimostrano ancora

Le conclusioni di Intezer offrono un'utile istantanea operativa, ma non sono una misurazione universale del rischio AI aziendale.

Lo studio copre gli avvisi visibili negli ambienti connessi alla piattaforma di Intezer. Non rappresenta ogni azienda, stack di sicurezza, settore, area geografica o stile di implementazione dell'AI.

Intezer non ha pubblicato nell'articolo un conteggio completo dei clienti né una ripartizione dettagliata per settore. Ha inoltre anonimizzato le informazioni relative a clienti, host, utenti e identificatori.

Questo protegge le organizzazioni, ma limita la riproducibilità indipendente. I lettori non possono determinare quanto un singolo grande ambiente abbia influenzato ogni categoria oltre gli esempi divulgati da Intezer.

La ricerca misura inoltre gli avvisi, non tutta l'attività AI. Un'azione che non attiva mai un controllo connesso potrebbe essere assente dal dataset.

Questo è particolarmente rilevante per gli strumenti basati su browser, gli account personali, le estensioni non autorizzate e gli scambi di dati che i prodotti endpoint non riescono a osservare. L'utilizzo silenzioso potrebbe essere sottorappresentato rispetto all'attività degli agenti eseguibili.

Il dato del 94,1% di rumore dovrebbe quindi guidare l'ottimizzazione dei rilevamenti, non diventare un tasso universale di falsi positivi. Un'altra organizzazione può avere agenti, policy, utenti o telemetria diversi.

Anche la quota di attacchi dello 0,02% richiede un'interpretazione attenta. Non dimostra che gli agenti AI siano intrinsecamente sicuri né che gli attacchi abilitati dagli agenti siano trascurabili ovunque.

Mostra che gli attacchi confermati erano estremamente rari all'interno di questa specifica popolazione di avvisi correlati all'AI. Intezer ha affermato che nessuno di questi attacchi confermati è derivato da un agente dell'organizzazione stessa che abbia causato una compromissione.

Gli attacchi autentici identificati utilizzavano marchi AI familiari come esche di phishing. Gli attaccanti impersonavano nomi quali Anthropic, Gemini e OpenAI perché i dipendenti li riconoscono e si fidano sempre più di essi.

Un'email faceva riferimento a una presunta collaborazione con Anthropic e a una richiesta di pagamento. Un'altra utilizzava un falso invito pubblicitario Gemini con infrastruttura non correlata a Google.

Una terza impersonava un evento partner OpenAI, utilizzando però infrastruttura Zoom legittima per rendere l'invito credibile. In ogni caso, l'adozione dell'AI ha rafforzato il pretesto anziché fornire una nuova tecnica di attacco.

Questa distinzione è utile, ma può cambiare. Autorizzazioni più ampie per gli agenti, capacità autonome più forti e integrazioni aziendali più profonde aumentano le conseguenze della manipolazione.

L'assenza di molte compromissioni confermate causate da agenti in questo dataset non è una prova che le implementazioni future resteranno sicure. È una base di riferimento per osservare la transizione.

Anche gli incentivi del fornitore meritano attenzione. Intezer vende una piattaforma AI SOC e servizi automatizzati di triage. La sua ricerca evidenzia naturalmente problemi che l'indagine contestuale e l'automazione possono affrontare.

Questo non invalida i dati. Significa che gli acquirenti dovrebbero confrontare i risultati con la propria telemetria, le conclusioni dei red team e la cronologia degli incidenti prima di modificare i controlli.

I team di sicurezza dovrebbero verificare se i verdetti automatizzati restano accurati nel loro ambiente. Dovrebbero campionare gli avvisi soppressi, riesaminare le classificazioni incerte e monitorare le evidenze successive che contraddicono una decisione precedente.

Dovrebbero inoltre documentare la differenza tra risultati verificati e dichiarazioni del fornitore. Per esempio, Intezer afferma che la sua piattaforma più ampia può indagare gli avvisi su larga scala, ma questo studio non convalida in modo indipendente ogni dichiarazione sulle prestazioni.

La questione più difficile riguarda i segnali mancanti. Un SOC può ridurre il rumore visibile e continuare a non avere copertura per strumenti browser non autorizzati o condivisioni di dati rischiose.

Per questo la riduzione degli avvisi non può essere l'unica metrica di successo. I team necessitano anche di copertura dell'inventario degli agenti, conteggi delle autorizzazioni rischiose, tendenze nei caricamenti sensibili e tempo necessario per ricondurre un'azione alla sua origine.

Un'organizzazione con meno avvisi ma senza visibilità su OAuth o sull'attività browser non ha necessariamente migliorato la propria sicurezza. Potrebbe aver spostato il rischio al di fuori del canale misurato.

Tre segnali mostreranno se i SOC si stanno adattando

Il prossimo test è se i team di sicurezza riusciranno a migliorare il contesto più rapidamente di quanto si espanda l'attività AI.

Il primo segnale è la performance dei falsi positivi per i rilevamenti correlati agli agenti. I responsabili SOC dovrebbero misurare i tassi di eventi benigni prima e dopo l'ottimizzazione delle regole più rumorose.

Un cambiamento efficace ridurrà gli avvisi ripetuti generati da installatori noti, server di sviluppo locali e catene di processi approvate. Manterrà invece la revisione per l'aggiramento delle autorizzazioni, l'estrazione di credenziali, i tunnel esterni e movimenti insoliti di dati.

Se i tassi di eventi benigni diminuiscono senza un aumento degli incidenti non rilevati, il SOC sta imparando a riconoscere il normale comportamento dell'AI. Se gli analisti continuano a chiudere manualmente gli stessi schemi, l'adozione sta ancora superando l'ingegneria del rilevamento.

Il secondo segnale è la copertura aziendale di identità, browser, endpoint, cloud e controlli sui dati. Un elenco di agenti di coding installati non costituisce un inventario completo dell'AI.

I team dovrebbero cercare nuove concessioni OAuth, primi accessi ad applicazioni AI, estensioni non gestite, uso di account personali e connessioni tra agenti e repository sensibili.

Una copertura migliore inizialmente rivelerà una maggiore esposizione silenziosa. Questo aumento temporaneo non va scambiato per un peggioramento della sicurezza. Una misurazione più accurata rende spesso visibile il rischio esistente prima che i controlli lo riducano.

Il terzo segnale è se le implementazioni degli agenti adottano per impostazione predefinita un'esecuzione vincolata. Richieste di autorizzazione, credenziali limitate, ambienti isolati e accesso alla rete ristretto forniscono confini misurabili.

Le organizzazioni dovrebbero monitorare la quota di agenti avviati con flag di aggiramento. Dovrebbero inoltre controllare quanto spesso gli agenti tentano comandi vietati, anche quando un controllo ne blocca l'esecuzione.

Un calo del tasso di aggiramento rafforzerebbe l'idea che la governance stia diventando operativa. Una crescita continua mostrerebbe che la comodità prevale ancora sul contenimento.

I test di sicurezza dovrebbero includere flussi di lavoro realistici degli agenti, non soltanto prompt per i modelli. Una valutazione può inserire istruzioni non affidabili nel codice, nei documenti, nei ticket o nei contenuti web e osservare la risposta dell'agente.

L'obiettivo è testare l'intero sistema. Ciò include autorizzazioni di identità, strumenti, memoria, contenuti esterni, controlli di esecuzione, registrazione e approvazione umana.

Gli avvisi SOC di Intezer AI offrono una prima visione di questa transizione. Il risultato principale è rassicurante solo a prima vista. Gli attacchi confermati erano rari, ma l'esposizione e il rumore operativo stavano già crescendo rapidamente.

Per i team SOC, la domanda immediata è concreta: riescono a identificare il comportamento normale degli agenti senza concedere loro una fiducia indiscriminata?

Si inizi dai rilevamenti che generano il maggior numero di avvisi benigni ripetuti. Quindi si confronti questa ottimizzazione con l'aggiramento delle autorizzazioni, l'accesso alle credenziali, i tunnel, le concessioni OAuth e i caricamenti di dati sensibili. Se questi segnali di maggior valore diventano più facili da individuare, il SOC si sta adattando. Se il numero di avvisi diminuisce mentre la visibilità resta frammentata, l'apparente miglioramento è soltanto un'incertezza più silenziosa.