Nati Hazut, CEO e cofondatore di Bold Security – Serie di interviste

Nati Hazut è CEO e cofondatore di Bold Security. In precedenza ha cofondato SAM Seamless Network e Polyrize, maturando esperienza nella sicurezza dei dispositivi connessi, nella gestione delle identità, nelle autorizzazioni cloud e nella protezione dei dati. In Bold applica queste competenze per proteggere le interazioni tra dipendenti, agenti di IA e dati aziendali sensibili.

Bold Security sviluppa una tecnologia di protezione dei dati sugli endpoint che utilizza modelli linguistici di piccole dimensioni, eseguiti direttamente sui dispositivi, per classificare le informazioni sensibili e capire come vengono utilizzate. La sua piattaforma offre ai team di sicurezza strumenti per guidare gli utenti, reindirizzare le attività o bloccare le azioni rischiose su browser, applicazioni desktop e agenti di IA. In questa intervista, Hazut parla di IA ombra, intelligenza on-device, agenti autonomi e dell’evoluzione del perimetro di sicurezza che protegge i dati aziendali.

In precedenza hai cofondato SAM Seamless Network e Polyrize, prima di avviare Bold Security con Hadar Krasner e Omri Mallis. Quali cambiamenti nella sicurezza aziendale e nell’IA ti hanno convinto della necessità di fondare da zero un’altra società di sicurezza?

Il principale effetto dell’IA è stato spostare il luogo in cui si svolge il lavoro. Per decenni, le attività più delicate che le persone svolgevano con i dati aziendali avvenivano nei browser e nelle applicazioni SaaS, proprio gli ambienti su cui si concentrava l’intero stack di sicurezza. Oggi una parte crescente di quel lavoro si svolge direttamente sul dispositivo: le persone preparano bozze con un assistente di IA desktop, incollano codice sorgente in un’app nativa o eseguono agenti che interagiscono direttamente con file, applicazioni e sistemi aziendali sul laptop.

Questo cambiamento ha fatto venir meno i presupposti su cui erano basati la maggior parte dei prodotti di sicurezza. L’ispezione di rete vede solo il traffico che vi transita, mentre le applicazioni desktop lo cifrano e aggirano il proxy. Le soluzioni CASB vedono le applicazioni cloud autorizzate. I sistemi DSPM vedono i dati archiviati nello spazio di archiviazione cloud. Nessuno di questi strumenti vede un file locale trasferito in un’app desktop di IA o un agente che sposta dati senza che nessuno sia alla tastiera.

Abbiamo fondato Bold perché l’endpoint è l’unico punto in cui tutto converge. Qui è possibile vedere i dati, il dipendente o l’agente che interagisce con essi, ciò che cerca di fare e la destinazione delle informazioni. Ed è possibile intervenire prima che i dati sensibili sfuggano al controllo dell’azienda.

L’IA ombra può comprendere diversi fenomeni: dai dipendenti che usano account personali di ChatGPT alle applicazioni desktop, alle estensioni del browser, alle API, alle connessioni tramite Model Context Protocol e, sempre più spesso, agli agenti autonomi. Quali forme di IA ombra sono oggi più difficili da rilevare e controllare per i team di sicurezza aziendale?

Un anno fa tutti erano preoccupati per l’«IA ombra», ma il dibattito sta diventando più articolato. I team di sicurezza aziendale stanno prendendo atto che i dipendenti adottano nuovi strumenti di IA più rapidamente che mai. La questione, quindi, non riguarda tanto il censimento degli strumenti quanto il controllo dei dati che vi transitano.

Naturalmente non si può controllare ciò che non si vede. E i canali più difficili da monitorare sono quelli che non transitano mai su un percorso di rete sorvegliato. Le applicazioni desktop leggono i file direttamente dal dispositivo e cifrano il traffico, che quindi non passa attraverso gli strumenti progettati per ispezionarlo. Gli agenti hanno accesso alle informazioni aziendali e continuano a utilizzarle senza che un dipendente debba fornire loro qualcosa ogni volta.

Tutti questi sono nuovi canali di esfiltrazione dei dati, e la questione centrale è capire che cosa vi transita. Il trasferimento di un documento pubblico a un account aziendale autorizzato non equivale al trasferimento di un database di clienti o di codice sorgente proprietario a un account personale; questa differenza è visibile solo nel luogo in cui risiedono i dati e avviene l’azione. Ecco perché l’IA ombra che non si riesce a vedere è anche quella per cui la questione dei dati è più importante.

Bold adotta un approccio che mette al primo posto l’endpoint, eseguendo l’IA localmente sul dispositivo anziché affidarsi principalmente al monitoraggio della rete o del cloud. Che cosa può comprendere un modello on-device di un’interazione con l’IA che i tradizionali strumenti di prevenzione della perdita di dati (DLP) non riescono a cogliere?

Bold si distingue per due aspetti. Primo, utilizziamo l’IA per proteggere i dati sensibili senza doverli inviare a un altro servizio di IA per l’analisi. I nostri modelli linguistici di piccole dimensioni vengono eseguiti direttamente sul dispositivo, dove possono capire quali dati sono sensibili, chi vi accede e dove vengono trasferiti. In questo modo possiamo individuare e bloccare le azioni rischiose in tempo reale, evitando la latenza e i costi associati all’invio di tutto al cloud.

Secondo, andiamo oltre i canali monitorati dai tradizionali strumenti di sicurezza. La maggior parte del settore continua a concentrarsi sui browser e sul traffico di rete, ma i dati sensibili passano sempre più spesso attraverso applicazioni desktop di IA, strumenti di programmazione, terminali e agenti autonomi. Per i prodotti convenzionali di DLP e sicurezza cloud è molto più difficile rilevarli.

Operando sull’endpoint, possiamo proteggere i dati in tutti questi ambienti e intervenire prima che le informazioni sensibili sfuggano al controllo dell’azienda.

La vostra tecnologia è progettata per comprendere non solo quali dati vengono consultati, ma anche il contesto e l’intento che stanno dietro a un’azione. Come distinguete l’uso legittimo di informazioni sensibili da un comportamento che rappresenta un effettivo rischio per la sicurezza, senza generare un numero eccessivo di falsi positivi?

Qui il contesto è tutto. Non si può trattare ogni caricamento di file o ogni accesso ai dati da parte di un agente come un incidente di sicurezza, altrimenti nessuno riuscirebbe a portare a termine il proprio lavoro.

Lo stesso file può essere normale in un contesto e costituire un problema serio in un altro. È normale trovare un elenco di clienti nello strumento di assistenza, ma è un vero problema se viene caricato su un account personale. Il codice sorgente deve stare nel repository, non in un prompt per uno strumento di IA destinato ai consumatori.

Uno strumento che sa soltanto che il contenuto corrisponde a una regola deve segnalare entrambi i casi oppure nessuno dei due. È così che si generano i falsi positivi. Sapere di quali dati si tratta, chi li sta trasferendo e dove sono diretti permette di distinguere l’uso normale dell’IA dai rischi reali.

Gli agenti di IA introducono un modello di sicurezza diverso, perché i software possono accedere sempre più spesso ai file, richiamare strumenti, connettersi tramite server MCP e compiere azioni con un coinvolgimento umano limitato. Come deve evolversi la sicurezza degli endpoint quando a interagire con i dati aziendali sensibili potrebbe essere un agente autonomo anziché un dipendente?

La sicurezza è stata concepita in gran parte intorno alle persone, ma oggi gli agenti possono agire alla velocità delle macchine, aprire file, richiamare strumenti e trasferire dati senza che qualcuno approvi ogni passaggio. La sicurezza deve operare alla stessa velocità. Molti prodotti usano l’IA per analizzare gli incidenti a posteriori. Noi la usiamo per individuare e fermare le azioni rischiose in tempo reale, comprese quelle che avvengono al di fuori del browser.

Un agente potrebbe operare tramite un’applicazione desktop, un terminale o un altro strumento che scopre mentre svolge un’attività. La sicurezza deve seguire i dati e le azioni in tutti questi ambienti, indipendentemente dal fatto che a esserne responsabile sia una persona o un agente.

Questo solleva anche una domanda che i team di sicurezza non avevano mai dovuto porsi prima. Quando accade qualcosa di rischioso, la persona voleva farlo oppure l’agente ha commesso un errore? Sono situazioni che richiedono risposte diverse. Se un dipendente sta prendendo una decisione sbagliata, lo si guida. Se un agente sta facendo qualcosa che nessuno gli ha chiesto, lo si ferma.

È sull’endpoint che si può cogliere la differenza, perché è lì che dati, processi e azioni si manifestano insieme.

Molte aziende hanno reagito ai rischi dell’IA generativa limitando o vietando determinati strumenti. Pensa che le organizzazioni si stiano orientando verso un modello in cui si possa autorizzare praticamente qualsiasi strumento di IA, purché siano previsti controlli sui dati a cui può accedere e sulle destinazioni verso cui può inviarli?

I divieti generalizzati non risolveranno il problema. I dipendenti possono trovare un nuovo strumento di IA e iniziare a usarlo in pochi secondi, e la maggior parte di loro non cerca di aggirare le misure di sicurezza. Vuole semplicemente svolgere il proprio lavoro più velocemente.

La domanda giusta è che cosa succede ai dati aziendali quando si usano questi strumenti.

Se qualcuno usa un account personale di IA per un’attività innocua, magari basta indirizzarlo verso l’account aziendale. Se sta per inviare codice sorgente, informazioni sui clienti o credenziali a una destinazione non autorizzata dall’azienda, allora deve intervenire il team di sicurezza.

Credo che la direzione sia questa: lasciare alle persone la possibilità di usare l’IA, ma introdurre controlli sui dati. Sapere a quali dati si accede, dove vengono inviati e quando è necessario intervenire.

L’esecuzione locale dell’IA può offrire vantaggi in termini di latenza e privacy, ma i dispositivi endpoint dispongono anche di capacità di calcolo e memoria limitate. Quali compromessi tecnici avete dovuto affrontare per realizzare modelli in grado di classificare semanticamente i dati e applicare controlli in tempo reale direttamente sui dispositivi dei dipendenti?

Non si può installare un modello enorme sul portatile di qualcuno, prosciugarne la CPU e la memoria e chiamarla sicurezza. Se il prodotto di sicurezza rende il computer insopportabile da usare, i dipendenti lo detesteranno e il reparto IT lo disattiverà.

I compromessi sono quindi molto concreti. Il modello deve comprendere i dati abbastanza bene da distinguere ciò che è innocuo da ciò che è sensibile, ma deve anche essere abbastanza veloce, leggero e affidabile da funzionare continuamente in background.

Il lavoro iniziale è consistito nello sviluppare modelli capaci di classificare i dati in modo utile su diversi tipi di computer senza rallentarli. Abbiamo già svolto questo lavoro di progettazione e sviluppo, così i clienti non devono affrontare da soli questi compromessi.

Durante tutto lo sviluppo, la priorità assoluta è stata l’esperienza utente. Il nostro prodotto utilizza circa il 20% delle risorse di calcolo impiegate dagli agenti non basati sull’IA dei concorrenti storici, prendendo decisioni localmente nel momento in cui avviene un’azione. Non è necessario che i dati sensibili lascino il dispositivo per stabilire se siano sensibili.

Bold è in grado di identificare strumenti di IA, account e attività degli agenti, fornendo indicazioni, reindirizzando o bloccando le azioni rischiose. Come stabilite quando il sistema deve limitarsi ad avvisare l’utente e quando, invece, deve bloccare automaticamente un’azione?

Pensate a come si comporterebbe un buon collega. Se steste per incollare una bozza nel vostro ChatGPT personale, si avvicinerebbe e direbbe: «Ehi, abbiamo un account aziendale per questo». Se steste per caricare il database dei clienti sul vostro Drive personale, vi afferrerebbe per un braccio.

Cerchiamo di agire allo stesso modo e constatiamo che il coaching riesce a indirizzare gli utenti verso l’alternativa sicura in almeno il 90% dei casi. Nella maggior parte dei casi, si tratta di qualcuno che per errore sta usando l’account sbagliato oppure non conosce le regole aziendali su dove possono essere trasferiti i dati.

La decisione su cosa bloccare spetta in definitiva al cliente, e ogni azienda traccia quel confine in modo diverso. Il nostro compito è fornire il contesto e la sicurezza necessari per prendere la decisione giusta. Nei flussi a rischio più complessi, questo significa considerare il contesto di cui abbiamo parlato prima, confrontandolo con la cronologia dell’utente e persino con quella dei suoi pari.

La tua carriera è passata dalla protezione dei dispositivi connessi in SAM alle identità e alle autorizzazioni cloud in Polyrize, fino all’attuale protezione delle interazioni tra persone, agenti di IA e dati aziendali in Bold. Come è cambiata, nel corso di queste tre generazioni di cybersicurezza, la tua visione del confine fondamentale della sicurezza?

La mia visione dei principi fondamentali si è affinata. Il filo conduttore è avvicinare la sicurezza al luogo in cui avviene l’azione e farla funzionare su larga scala.

In SAM abbiamo portato una sicurezza di livello aziendale sui router, nonostante le risorse molto limitate. Questo ci ha insegnato come implementare in modo efficiente tecnologie avanzate sull’edge. In Polyrize ci siamo concentrati sulla protezione dei dati negli ambienti cloud e SaaS, garantendo visibilità e gestendo la postura di sicurezza. Capire il livello di esposizione è essenziale, ma non consente necessariamente di impedire un’azione rischiosa.

Bold riunisce queste lezioni. Portiamo l’intelligenza sugli endpoint, dove le persone e gli agenti di IA interagiscono con i dati, e forniamo ai team di sicurezza il contesto necessario per comprendere i rischi e intervenire in tempo reale.

La sicurezza di rete e del cloud resta importante, ma l’endpoint può rilevare le attività svolte tramite applicazioni desktop, file locali, account personali e agenti in esecuzione sul dispositivo. Ho imparato che il luogo e il momento in cui interviene la sicurezza contano quanto il suo livello di intelligenza.

Guardando ai prossimi tre-cinque anni, man mano che i dipendenti lavoreranno fianco a fianco con agenti di IA sempre più autonomi, in cosa pensi che si trasformerà l’endpoint aziendale? Potremmo arrivare al punto in cui ogni dispositivo dispone, di fatto, di un proprio livello di sicurezza intelligente che decide in modo continuo quali persone e agenti possono interagire con determinati dati?

Credo che sia proprio questa la direzione verso cui stiamo andando.

L’endpoint diventa un livello di sicurezza intelligente che comprende i dati presenti sul dispositivo, sa se a interagire con essi è una persona o un agente e decide localmente cosa si può e cosa non si può fare.

Questo aspetto diventa ancora più importante man mano che gli agenti acquisiscono autonomia. Una persona potrebbe avere contemporaneamente diversi agenti che lavorano per suo conto su file, applicazioni e sistemi aziendali. La sicurezza non può dipendere dall’approvazione di ogni singolo passaggio da parte di quella persona, perché sempre più spesso non starà a controllare.

I dati devono comunque essere protetti, ma il numero di soggetti che vi accedono crescerà ben oltre una sola persona davanti a una tastiera. I sistemi di sicurezza dovranno comunicare con gli agenti, prendere decisioni e reagire autonomamente man mano che si verificano le azioni. Chi gestisce questi sistemi si occuperà sempre più di supervisionare i controlli e le decisioni, anziché esaminare ogni singolo evento. L’endpoint è il luogo in cui queste decisioni possono essere prese mentre i dati sono ancora sotto il controllo dell’azienda.

Grazie per questa splendida intervista. I lettori che desiderano approfondire la protezione dei dati sugli endpoint e l’adozione sicura dell’IA in azienda possono visitare Bold Security.