Micha Rave, CEO e co-fondatore di Hush Security – Serie di interviste

Micha Rave, CEO e co-fondatore di Hush Security, è un dirigente esperto di cybersecurity e tecnologia la cui carriera comprende ingegneria del software, gestione del prodotto, networking aziendale, sicurezza cloud e identità. Prima di co-fondare Hush Security nel 2024, ha trascorso più di cinque anni in Proofpoint come Senior Director of Product Management per la Cloud Security, dove era responsabile delle linee di prodotto Zero Trust Network Access (ZTNA) e Secure Web Gateway (SWG). In precedenza è stato VP of Product Management presso Meta Networks, concentrandosi sul networking aziendale e sulla sicurezza, e ha ricoperto ruoli di leadership di prodotto e ingegneria presso HARMAN International, Redbend, SanDisk, Hola, Jungo ed Elbit Systems. Il suo background combina sviluppo software pratico con oltre due decenni di esperienza nella creazione e commercializzazione di prodotti di sicurezza, networking, virtualizzazione e tecnologia embedded.

Hush Security è una società di cybersecurity focalizzata sulla protezione di agenti IA e altre identità non umane sostituendo credenziali a lunga scadenza e segreti statici con accessi basati su identità e controllati da policy. La sua piattaforma scopre gli agenti IA, inclusi agenti shadow e sviluppati internamente, assegna loro identità verificabili e gestisce le loro interazioni con i sistemi aziendali mediante permessi a scadenza breve e limitati, policy centralizzate e registri di attività auditabili. L’azienda è stata fondata da veterani della sicurezza del team dietro Meta Networks, che Proofpoint ha acquisito nel 2019. Nel luglio 2026, Hush ha raccolto $30 million Series A con Akamai Technologies che è entrata come investitore strategico insieme a Battery Ventures e YL Ventures, portando il finanziamento totale a $41 million mentre l’azienda espande la sua tecnologia per governare agenti IA aziendali e infrastrutture non umane.

Prima di fondare Hush Security, hai trascorso anni a costruire e guidare prodotti di sicurezza, inclusa la sicurezza cloud in Proofpoint. Cosa hai osservato nel mercato che ti ha convinto della necessità di avviare Hush, e in che modo quella tesi originale è evoluta con la rapida crescita dell’IA agentica?

Da Proofpoint abbiamo osservato le imprese risolvere l’identità umana mentre tutto ciò che è non umano continuava a funzionare con segreti statici. Account di servizio, workload, pipeline, tutti autenticati con chiavi che nessuno possedeva e che non scadevano. Il settore ha risposto con vault più avanzati. È una cassaforte migliore, non una soluzione.

La tesi fondante era spostare l’accesso non umano da segreti a identità. Identità verificabile per i workload, credenziali a breve durata emesse al momento, policy applicate in linea. Nessuna riscrittura del codice.

L’IA agentica ha reso ciò urgente. Un agente è un NHI che ragiona e decide in tempo reale quali strumenti invocare. Dargli una chiave statica significa concedere al software autonomo un accesso permanente alla produzione, e gli agenti vengono distribuiti al di fuori di qualsiasi processo di modifica; un sviluppatore collega un server MCP martedì e già venerdì sta toccando i dati dei clienti.

La tesi non è cambiata. È cambiato il contesto. L’accesso basato su identità era la risposta giusta per i workload. Per gli agenti è l’unica soluzione praticabile: conoscere ogni agente esistente, concedere a ciascuno la minima agenzia per impostazione predefinita e auditare ogni azione. Gli esseri umani hanno un IdP. Anche gli agenti ne hanno bisogno e questo è Hush.

Hush sostiene che gli agenti IA aziendali dovrebbero avere proprie identità e permessi delegati anziché ereditare semplicemente i diritti di accesso degli esseri umani che li utilizzano. Perché i tradizionali sistemi di Identity and Access Management (IAM) faticano con gli agenti autonomi, e cosa deve cambiare?

Il caso ovvio è un agente che agisce per un utente. Il caso più difficile è un agente senza alcun utente: un lavoro programmato, un risponditore SOC autonomo, una pipeline che ragiona e agisce da sola. Non c’è nessuno da cui delegare, così i team ricorrono all’unico strumento a disposizione, un account di servizio statico con permessi ampi e una chiave che non scade mai. È lo stesso modello di segreto condiviso che si rompe da un decennio, ora associato a software che improvvisa.

I sistemi all’altro capo peggiorano la situazione. La maggior parte delle API interne, dei database e dei server MCP non eseguono una vera autorizzazione. Controllano solo se possiedi un token valido, non cosa sei autorizzato a fare con esso. Possesso equivale a permesso.

Cosa deve cambiare: ogni agente ottiene la propria identità, emessa crittograficamente, indipendentemente dal fatto che vi sia un umano dietro di essa. L’accesso viene concesso per azione, a breve durata e limitato, con policy applicate in linea anziché affidate al sistema di destinazione. Quando c’è un utente, i permessi dell’agente sono l’intersezione tra ciò che l’utente può fare e ciò che quell’agente è autorizzato a fare per quel compito. Quando non c’è, l’identità e la policy dell’agente costituiscono l’intera storia. Gli esseri umani hanno il principio del minimo privilegio. Gli agenti hanno bisogno del minimo di agenzia.

Utilizzi il concetto di “least agency” quando discuti della sicurezza dell’IA. In che modo il minimo di agenzia differisce dal tradizionale principio di cybersecurity del minimo privilegio, e come le organizzazioni possono determinare esattamente cosa un agente IA dovrebbe poter fare per un compito specifico?

Gli agenti non hanno un comportamento fisso. Concedere a uno l’accesso in lettura a un CRM e l’accesso in scrittura all’email non significa aver concesso due permessi, ma aver concesso ogni percorso tra i due. Il minimo privilegio delimita ciò che un agente può toccare. Non dice nulla su cosa debba fare con esso.

Least agency aggiunge la dimensione mancante: quali azioni, per quale compito, in questo momento. Un agente che smista ticket deve leggere e commentare. Non ha bisogno di chiudere, eliminare o toccare la fatturazione, anche se il token lo consente. Quando il compito termina, termina anche l’accesso.

Decidere cosa è consentito inizia con l’osservazione, non con le congetture. Esegui l’agente, osserva cosa chiama realmente e lascia che questo definisca la baseline. Poi restringi usando tre input: il compito per cui esiste, l’utente per cui agisce (mai più di quanto quell’utente possa fare) e il raggio d’azione di ogni azione, perché pubblicare un commento e effettuare un pagamento non dovrebbero condividere lo stesso percorso di approvazione.

Il principio del minimo privilegio decide chi ottiene le chiavi. Il principio della minima agenzia decide cosa possono fare una volta dentro.

Spesso “prestatamo” la nostra identità al nostro agente, ma non vogliamo che l’agente abbia lo stesso livello di permessi che abbiamo noi – questa è la definizione di minima agenzia.

Hush ha recentemente raccolto un Serie A da 30 milioni di dollari, portando il finanziamento totale a $41 million, con Akamai che si unisce come investitore strategico insieme a Battery Ventures e YL Ventures. Cosa porta il coinvolgimento di Akamai oltre al capitale, e come prevedi che la partnership influenzerà l’espansione di Hush nella sicurezza degli agenti IA per le imprese?

Akamai si trova nel percorso di traffico della maggior parte delle imprese mondiali, ed è proprio lì che la sicurezza degli agenti deve operare. Non si governa un agente da una dashboard dopo il fatto. Lo si governa inline, nel momento in cui chiama uno strumento o un’API. Akamai ha costruito il suo modello di business su questo principio.

Oltre al capitale, apportano tre elementi: distribuzione verso i CISO che già chiedono come controllare gli agenti e il traffico MCP; convalida che l’identità dell’agente è una categoria reale, non una semplice funzionalità; e decenni di esperienza nella protezione del traffico machine‑to‑machine su scala globale, che è ciò che il traffico agente‑to‑tool sta per diventare.

Model Context Protocol (MCP) sta rapidamente diventando uno strato importante per collegare gli agenti IA con strumenti e dati aziendali. Da un punto di vista della sicurezza, quali nuovi rischi introduce MCP e come dovrebbero le organizzazioni pensare all’identità e all’autorizzazione tra l’agente, il server MCP e la risorsa sottostante?

MCP ha reso banale collegare un agente a uno strumento. Questo è il rischio. Uno sviluppatore aggiunge un server a un file di configurazione e il modello può ora leggere Jira, interrogare un database o inviare email. Nessuna revisione, nessun inventario, nessuna policy. La sicurezza lo scopre solo quando qualcosa si rompe.

Ci sono ora tre nuovi problemi:

1. Shadow MCP – nessuno sa quanti server sono in esecuzione o a cosa accedono.
2. Spargimento di credenziali – la maggior parte dei server si autentica con un token statico che concede l’intera superficie, quindi l’agente ottiene tutto ciò che il token può fare.
3. La catena collassata – la risorsa vede solo le credenziali del server MCP, quindi non può capire quale agente, per quale utente, ha effettuato la chiamata. L’identità deve essere alla base di ogni interazione, l’accesso dovrebbe essere effimero, limitato e basato sui permessi dell’agente e dell’utente.

Hush è stato originariamente costruito attorno all’idea che segreti statici e credenziali a lunga durata siano una base difettosa per l’accesso delle macchine. Poiché la maggior parte dell’infrastruttura aziendale si basa ancora pesantemente su chiavi API, token e altri segreti, come possono le aziende passare realisticamente a un accesso basato sull’identità, a breve termine, senza ricostruire l’intero stack tecnologico?

Non ricostruisci. Nessuno che afferma il contrario ha mai incontrato un’azienda. Gran parte di ciò che proteggiamo precede il concetto di identità non umana, e non sta per essere riscritto.

Quindi non lo chiediamo. Hush si distribuisce senza modifiche al codice e si colloca nel percorso di accesso. Il primo passo è la scoperta: ogni segreto, chi lo usa, a cosa arriva, cosa fa realmente a runtime. La maggior parte delle aziende non ha mai visto questa immagine.

Poi è un percorso, non una migrazione. La scoperta mostra quali segreti sono inutili, sovra‑scoperti o ad alto rischio. Si correggono prima questi. Poi si sostituiscono le chiavi statiche con credenziali a breve durata, emesse dall’identità, un sistema alla volta. L’applicazione pensa ancora di usare una chiave. La chiave semplicemente non è più a lunga durata, e la policy passa a noi.

Lo stesso modello copre un servizio Java di quindici anni e un server MCP messo in piedi la scorsa settimana. Inizia dove c’è il rischio, dimostralo, continua.

Gli agenti IA lavoreranno sempre più spesso per conto degli esseri umani e, in molti casi, delegheranno compiti ad altri agenti. Man mano che questi flussi di lavoro multi‑agente diventano più complessi, come si mantiene una catena chiara di identità, autorizzazione, proprietà e responsabilità per ogni azione che avviene?

Il caso di errore: un utente chiede a un orchestratore, che delega a un secondo agente, che chiama uno strumento tramite un server MCP, che a sua volta contatta un database con un account di servizio. Quattro hop più tardi il log mostra un’unica cosa, un token valido. Chi ha chiesto, chi ha deciso e chi è responsabile sono scomparsi.

La soluzione è rifiutare che l’identità collassi a qualsiasi hop. Ogni agente ha la propria identità crittografica. Quando delega, non passa il proprio token. Emissione di una delega limitata: questo sotto‑agente, questo compito, queste azioni, per conto di questo utente. Ogni hop trasporta l’intera catena e le proprie autorizzazioni.

La responsabilità deriva dall’applicare e registrare inline, al punto di azione. Il registro del gateway di ciò che gli è stato consentito fare, di ciò che ha chiamato e della catena sottostante.

I sistemi multi-agente diventeranno più difficili da comprendere. La catena di custodia per ogni azione non deve esserlo.

L’iniezione di prompt e altri attacchi possono potenzialmente manipolare un agente IA altrimenti legittimo inducendolo a compiere azioni che il suo operatore non ha mai inteso. In che misura i controlli di accesso basati sull’identità possono limitare i danni causati da un agente compromesso o manipolato, anche quando il modello IA sottostante si comporta in modo errato?

Non si può fermare l’iniezione di prompt a livello del modello. I modelli leggono contenuti non attendibili per progettazione. Si deve presumere che l’agente alla fine venga convinto a fare qualcosa di sbagliato. La domanda è cosa può fare quando ciò accade.

L’accesso basato sull’identità limita il raggio d’azione. Un agente manipolato con la minima autonomia può abusare solo delle azioni che gli sono state concesse per quel compito. Se può leggere ticket e pubblicare commenti, nessuna iniezione lo farà esfiltrare il database dei clienti. Il token non ha quella portata.

L’attribuzione dell’utente mantiene intatta la catena: quale utente, quale agente, quale compito, a ogni chiamata. L’agente non supera mai ciò che l’utente potrebbe fare, e ogni azione risale alla fonte.

Il rilevamento delle anomalie intercetta ciò che la politica consente ma l’intento non ha previsto. Un agente che normalmente legge cinque record e improvvisamente ne estrae cinquemila è fuori dal suo comportamento abituale anche se ogni chiamata è autorizzata. Poiché il gateway è inline e conosce la baseline, può segnalare o bloccare ciò in tempo reale.

Il modello sarà talvolta errato. L’identità a scopo limitato, l’attribuzione e le baseline comportamentali rendono gli errori gestibili.

Hush è principalmente focalizzata sulla sicurezza dell’IA, ma come state utilizzando l’IA all’interno di Hush stessa? Esistono aree come la scoperta di identità non umane, l’analisi dei pattern di accesso, la priorizzazione del rischio o l’applicazione di politiche dove l’IA può migliorare materialmente la piattaforma di sicurezza?

La utilizziamo ovunque dimostri il suo valore.

Nel prodotto, la parte difficile non è trovare i segreti, ma comprenderli. Una chiave appare nel traffico. Identità del carico di lavoro, integrazione del fornitore, token di test di sviluppo, credenziale inattiva? Un LLM legge il contesto di runtime e i segnali del proprietario e propone una risposta con un punteggio di confidenza. Riassume ciò che un’identità fa realmente in linguaggio umano semplice, così la politica è una che un umano approverà. Classifica il rischio in base al reale raggio d’azione e impatto, non alla gravità statica. L’applicazione rimane deterministica. L’IA aiuta a scrivere la politica – non ottiene un voto in fase di esecuzione.

All’interno di Hush, la programmazione agentica ha cambiato i nostri tempi. Funzionalità che richiedevano uno sprint ora richiedono giorni, e rilasciamo integrazioni a una velocità che un team di Serie A non potrebbe permettersi. Gli LLM gestiscono i ticket di supporto, raggruppano le cause radice e mettono in evidenza le richieste dei clienti per le discussioni sulla roadmap. Il nostro gateway MCP si pone davanti a tutto, aiutando i clienti a ragionare e a gestire NHI e il rischio agentico.

Hush afferma che diverse aziende Fortune 500 stanno ora utilizzando la sua tecnologia, mentre Kyndryl ha implementato Hush internamente e ha iniziato a rivenderla ai clienti enterprise. Cosa state apprendendo da queste implementazioni su larga scala riguardo ai problemi di governance reali che le aziende incontrano quando gli agenti IA passano dalla sperimentazione alla produzione?

Nessuno sa cosa possiede. Ogni grande implementazione inizia allo stesso modo: la sicurezza pensa che ci siano una dozzina di agenti in produzione, la scoperta ne trova centinaia, già a contatto con i dati dei clienti. Il problema di governance non è la politica, ma prima l’inventario.

Le credenziali sono peggio degli agenti. Quasi tutti gli agenti in produzione funzionano su un account di servizio statico che lo precede, con permessi accumulati negli anni per altro. Non ha ricevuto un accesso a scopo limitato.

Manca la proprietà. Chiedi chi è responsabile di un agente, o di un NHI, e ottieni al meglio il nome di un team, un collaboratore uscito, o il silenzio.

E l’acquirente è cambiato. Questo era un problema del team di piattaforma. Ora è il CISO a possederlo perché il consiglio lo richiede. Questo ci ha spostati dai progetti pilota ai rollout aziendali, ed è il motivo per cui Kyndryl ha implementato internamente prima di rivendere.

Gli agenti non hanno creato nuovi problemi di governance. Hanno preso quelli che le imprese hanno ignorato per un decennio con gli account di servizio e li hanno resi molto più gravi.

Grazie per la grande intervista, i lettori che desiderano saperne di più dovrebbero visitare Hush Security.