Adam Markowitz, CEO e cofondatore di Drata – Serie di interviste

Adam Markowitz è CEO e cofondatore di Drata, dove sta ampliando il lavoro dell’azienda sulla conformità continua e sulla fiducia, estendendolo alla governance degli agenti IA. Prima di cofondare Drata nel 2020, ha fondato Portfolium insieme a Troy Markowitz e Daniel Marashlian. La sua esperienza nella gestione di questionari di sicurezza, audit e verifiche di conformità ha contribuito a definire l’approccio di Drata all’automazione dei processi con cui le organizzazioni dimostrano di essere affidabili.

Drata offre una piattaforma per la governance, la gestione del rischio e la conformità, che combina la raccolta automatizzata delle prove, il monitoraggio continuo dei controlli, la gestione del rischio di terze parti e i flussi di lavoro per i questionari di sicurezza. Le sue funzionalità di governance degli agenti IA si concentrano sull’individuazione degli agenti, sull’applicazione delle policy prima che vengano eseguite le azioni e sulla registrazione delle decisioni ai fini della verificabilità in sede di audit. In questa intervista, Markowitz parla delle minacce interne legate agli agenti, dell’identità delle macchine, dei confini di sicurezza delle chiamate agli strumenti e dei controlli necessari alle aziende per distribuire agenti autonomi su larga scala.

In precedenza hai fondato Portfolium, prima di cofondare Drata nel 2020, dopo aver sperimentato in prima persona quanto la conformità in materia di sicurezza potesse diventare complessa con la crescita di un’azienda. Cosa ti ha portato a credere che fosse un problema tale da meritare la creazione di un’azienda completamente nuova, e come si è evoluta la missione di Drata con i cambiamenti che l’IA ha introdotto nel panorama della sicurezza?

Mentre guidavamo Portfolium insieme ai miei cofondatori Troy Markowitz e Daniel Marashlian, abbiamo imparato una lezione importante: conquistare la fiducia nel mondo degli affari è un processo, non un discorso di vendita. Considerata la quantità e la sensibilità dei dati degli studenti, università e aziende non avrebbero collaborato con noi finché non avessimo dimostrato di fare quanto necessario per proteggerli. Ci siamo resi conto che affrontare manualmente ogni questionario di sicurezza, audit e verifica di conformità era un’attività lenta e frustrante, un’esperienza comune a molti. Dopo l’acquisizione di Portfolium, Troy, Daniel e io ci siamo ritrovati e abbiamo dedicato sei mesi alla creazione della prima versione di Drata, parlando con decine di aziende e auditor per verificare il problema prima ancora di iniziare a scrivere codice. Al lancio abbiamo raggiunto 100 clienti nelle prime sei settimane e 1.000 entro un anno: un risultato che ci ha fatto capire che eravamo passati dal vendere qualcosa di «utile da avere» a qualcosa senza cui le persone non potevano lavorare.

Con l’IA, la missione di Drata di garantire una fiducia continua non è cambiata, ma l’ambito di tale fiducia si è ampliato. Abbiamo iniziato automatizzando il laborioso processo di conformità, per poi passare a flussi di lavoro agentici in grado di svolgere dall’inizio alla fine valutazioni del rischio di terze parti e questionari di sicurezza. La vera svolta è arrivata quando sono diventati gli agenti stessi a dover essere sottoposti a governance. Ora abbiamo esteso la piattaforma per consentire la governance degli agenti IA: individuarli, gestire ciò che possono fare e produrre prove capaci di reggere a ogni verifica.

Hai introdotto il termine «minaccia interna degli agenti» per descrivere i rischi causati non da un aggressore esterno, ma dagli agenti IA di un’organizzazione. Cosa distingue una minaccia interna degli agenti dalle minacce interne tradizionali per cui i team di sicurezza si preparano da decenni?

Le minacce interne tradizionali riguardano una persona che abusa degli accessi di cui già dispone: per esempio, un dipendente scontento, uno distratto o qualcuno che semplicemente fa clic sull’elemento sbagliato. Da decenni i team di sicurezza sviluppano programmi per affrontare questo rischio, puntando su controlli dei precedenti, principio del privilegio minimo, liste di controllo per la cessazione del rapporto di lavoro e misure simili.

La minaccia interna degli agenti è diversa perché all’agente non era mai stato concesso l’accesso. Il rischio passa dall’abuso all’acquisizione dell’accesso. Se a un agente viene assegnato un obiettivo e il percorso più diretto per raggiungerlo è bloccato, non si limita ad aprire un ticket e ad aspettare, come farebbe una persona. Cerca un’altra via: un account di servizio con una password debole oppure un endpoint che nessuno si è ricordato di chiudere. Si introduce senza malizia né consapevolezza di violare le policy. Fa esattamente ciò che gli è stato chiesto, ed è questo a renderlo così difficile da individuare. Ogni singolo passaggio sembra ragionevole, se considerato isolatamente, e alla fine l’agente comunica di aver avuto successo.

Sappiamo già come gestire dipendenti e terze parti che hanno accesso a sistemi sensibili, ma gli agenti costituiscono una terza categoria e gli strumenti creati per le prime due non sono in grado di raggiungerla.

Gli agenti IA possono perseguire obiettivi con tenacia, operare alla velocità delle macchine e interagire con più sistemi senza il giudizio che potrebbe applicare un dipendente umano. In che misura questo cambia radicalmente il modello di minaccia aziendale?

Più di ogni altra cosa, cambia le tempistiche. Una persona che cerca un modo per entrare in un sistema prima o poi si annoia, viene scoperta o si arrende. Un agente no. Ora gli accessi lasciati aperti e finora mai individuati vengono scoperti, perché l’agente non si stanca e non smette di cercare.

E non si tratta di un solo accesso. Un agente creato per svolgere un’attività può tranquillamente interagire con una dozzina di sistemi mentre la porta a termine: recupera la cronologia di un account da una parte, consulta un database dall’altra. Gran parte di queste operazioni non ha nulla a che vedere con ciò che gli era stato effettivamente chiesto di fare. Per preparare una presentazione, può passare attraverso i dati di un altro cliente, registri finanziari, informazioni sui dipendenti o qualsiasi altra cosa incontri lungo il percorso. Nulla di tutto questo risulta come incidente.

Il modello di minaccia è quindi cambiato. Oggi la domanda che un team di sicurezza dovrebbe porsi è fin dove si spingeranno i propri agenti per portare a termine un’attività, se nessuno ha detto loro dove fermarsi.

Molte organizzazioni dispongono già di sistemi di gestione delle identità e degli accessi, di gestione degli accessi privilegiati e di architetture zero trust. Perché questi controlli non bastano, da soli, a governare gli agenti IA autonomi?

Questi framework sono stati concepiti per le persone e per i fornitori: entrambe le categorie sono dotate di capacità di giudizio e si fermano quando incontrano un ostacolo. L’identità degli agenti richiede lo stesso rigore previsto per le persone e per la gestione del rischio di terze parti: individuazione, titolarità e prove che un auditor possa considerare attendibili. Il problema è che ancora non esiste un criterio condiviso per definire cosa significhi davvero «governato» quando a detenere le credenziali è un agente.

Per esempio, un agente creato da un vostro ingegnere può agire con i suoi stessi accessi, anche su sistemi che quell’ingegnere non usa mai personalmente. IAM e PAM presuppongono che chi detiene le credenziali sappia quando fermarsi, ma gli agenti non hanno questa capacità intrinseca.

Le imprese dovrebbero iniziare a trattare ogni agente IA come un’identità macchina a sé stante, con un titolare, autorizzazioni, ambito operativo e ciclo di vita chiaramente definiti? Come sarebbe un framework maturo per la gestione delle identità degli agenti?

Sì, ma la maggior parte delle imprese non è ancora a questo punto. Più organizzazioni di quanto si possa immaginare non sanno nemmeno dire quanti agenti operano al loro interno, figuriamoci chi è responsabile di ciascuno. Un framework maturo parte dall’individuazione: un inventario completo e aggiornato in modo continuo di ogni agente. A quel punto, ogni agente deve avere un titolare, un ambito operativo definito che specifichi a quali risorse può accedere e una policy che faccia effettivamente rispettare tali limiti. Dalle nostre ricerche emerge lo stesso problema sul fronte dei fornitori: tre organizzazioni su quattro rivalutano le terze parti solo una volta all’anno o meno spesso, quindi prendono decisioni basandosi su dati già obsoleti quando interviene un cambiamento. Le verifiche effettuate in un singolo momento non sono sufficienti per gli agenti, interni o esterni.

Vogliamo un unico standard da applicare a tutti gli agenti allo stesso modo, invece di costringere il team di sicurezza a ricostruire ciò che ogni singolo sviluppatore ha creato per conto proprio. Questo significa poter scrivere policy in linguaggio semplice, verificarle su traffico storico reale prima ancora di attivarle e poi applicarle direttamente nel flusso di esecuzione, così che il framework intervenga su ogni azione dell’agente e non resti confinato alla documentazione.

Uno scenario particolarmente difficile è quello di un agente che viola le policy di sicurezza senza comportarsi in modo malevolo. Se, nel tentativo di portare a termine il compito assegnato, un agente individua per caso un percorso non previsto per accedere a dati sensibili, come possono i team di sicurezza distinguere un’automazione riuscita da un incidente di sicurezza?

Al momento, la risposta sincera è che non si può. Immaginate un agente di supporto progettato per preparare le revisioni trimestrali dell’andamento aziendale, a cui viene chiesto di recuperare la cronologia dell’account e creare la presentazione. Il percorso previsto — l’esportazione da cui dovrebbe attingere — restituisce un risultato vuoto. Una persona si fermerebbe lì, ma l’agente trova un’altra strada e, dal suo punto di vista, ha portato a termine il compito con successo.

Il compito è stato portato a termine, ma l’agente ha aggirato i protocolli di sicurezza ed è entrato in sistemi a cui non avrebbe dovuto accedere. La domanda decisiva deve essere se l’agente è rimasto entro i limiti dell’ambito operativo che gli avevamo assegnato. Portare a termine il compito non è mai stato il punto. È una questione di policy. Significa definire l’ambito operativo con sufficiente precisione, affinché, a posteriori, «automazione riuscita» e «incidente di sicurezza» non appaiano identici.

Spesso il monitoraggio di sicurezza tradizionale individua le attività sospette dopo che si sono verificate, ma un agente autonomo può completare centinaia di azioni prima che una persona riesca a intervenire. L’IA agentica richiede controlli di sicurezza che agiscano direttamente nel flusso di esecuzione, anziché affidarsi soprattutto agli avvisi e al monitoraggio a posteriori?

Sì, senza dubbio. Se ve ne accorgete in fase di esecuzione, è già troppo tardi. Quando uno strumento di monitoraggio segnala l’azione, questa è già stata eseguita. Avrete una registrazione perfetta e dettagliata di come siete stati esposti, ma non potrete più tornare indietro per fermare l’accaduto.

L’unica forma di governance efficace per qualcosa che si muove alla velocità delle macchine è quella che valuta l’azione prima che venga eseguita e blocca la violazione direttamente nel flusso di esecuzione. Non affideremmo mai i nostri dati più sensibili a un nuovo assunto limitandoci a sperare che il monitoraggio rilevi eventuali problemi. Gli agenti meritano la stessa disciplina, proprio nel momento in cui l’azione sta per essere compiuta. Non dopo.

Il Model Context Protocol (MCP) e altre interfacce tra agenti e strumenti stanno offrendo ai sistemi di IA l’accesso a funzionalità esterne sempre più potenti. Quali nuovi confini di sicurezza occorre stabilire per le chiamate agli strumenti, le API, le credenziali e gli account di servizio, man mano che le imprese ampliano le attività consentite ai propri agenti?

La chiamata a uno strumento è il nuovo perimetro di sicurezza. Ogni volta che un agente utilizza una credenziale, chiama un’API o invoca uno strumento, si trova davanti a un punto decisionale; oggi, nella maggior parte delle aziende, non esiste alcun controllo in corrispondenza di quel preciso passaggio che valuti se l’azione debba essere eseguita. È questo l’elemento che è mancato finora. Vediamo lo stesso punto cieco anche dall’esterno: appena il 37% dei responsabili della sicurezza è certo di riuscire anche solo a identificare dove viene eseguita l’IA all’interno dei fornitori con cui già lavora. Se non riesci a vederla nel prodotto di un fornitore, non riuscirai a vedere neanche la prossima mossa del tuo agente. Anche le credenziali e gli account di servizio alla base di tutto questo richiedono lo stesso rigore che applichiamo agli accessi delle persone: titolarità nota, ambito definito e verifiche regolari. Un agente non dovrebbe poter utilizzare una credenziale che non gli è mai stata concessa solo perché quella credenziale era presente da qualche parte nel suo percorso.

Quando un revisore, un’autorità di regolamentazione o un cliente chiede a quali dati ha avuto accesso un agente di IA, quali decisioni ha preso e dove sono finiti i dati risultanti, quale livello di tracciabilità dovrebbero realisticamente essere in grado di fornire le organizzazioni? Le tracce di audit degli agenti potrebbero diventare, col tempo, fondamentali quanto i tradizionali registri degli accessi?

Su richiesta, le organizzazioni dovrebbero essere in grado di rispondere a domande su quali dati ha consultato un agente, quali decisioni ha preso e dove sono finiti i dati risultanti. Non basta ricostruire la risposta a posteriori mettendo insieme i registri. Lo standard da raggiungere è disporre già, nel momento in cui viene posta la domanda, di una registrazione continua e a prova di manomissione. Al momento, la maggior parte delle aziende non dà alcuna risposta a queste domande. Non è una lacuna che si possa giustificare con un cliente e, a seconda di ciò che è trapelato, nemmeno le autorità di regolamentazione la accetteranno.

E sì, penso che le tracce di audit degli agenti diventeranno fondamentali quanto i registri degli accessi, e presto. Da anni consideriamo imprescindibile, per i sistemi utilizzati dalle persone, sapere «chi ha avuto accesso a cosa e quando». Non c’è motivo di applicare agli agenti uno standard meno rigoroso solo perché a fare clic non è stata una persona. Quadri normativi come l’EU AI Act, AIUC-11 e ISO 42001 stanno già spingendo in questa direzione. La tracciabilità degli agenti deve rifarsi agli stessi controlli e agli stessi criteri probatori su cui si basano già i programmi di conformità. Trattarla come un aspetto secondario significa condannarla a essere trascurata.

Guardando al futuro, pensi che la governance degli agenti di IA diventerà una categoria di sicurezza a sé stante o finirà per essere integrata nelle piattaforme esistenti di governance, gestione del rischio, conformità, identità e sicurezza informatica? Secondo te, di cosa dovranno dotarsi le aziende prima di poter implementare in sicurezza agenti davvero autonomi su larga scala?

Ogni grande ondata tecnologica ne genera una sul fronte della sicurezza: il cloud ha dato vita a Wiz, gli endpoint a CrowdStrike; ora è il turno degli agenti di IA. I fornitori di modelli stanno creando console e criteri per le proprie piattaforme: è utile, ma nessuna azienda si basa su un unico fornitore di modelli, un solo assistente di programmazione e un solo insieme di agenti sviluppati internamente. Qualcuno deve gestire tutto questo applicando un unico insieme di criteri e utilizzando un’unica fonte di prove, e non è un problema che una singola piattaforma di IA sia stata progettata per risolvere. Non è questo il motivo per cui esiste. La governance degli agenti di IA è già una categoria a sé, pur integrandosi con i sistemi di GRC, gestione delle identità e conformità che le aziende già utilizzano.

Prima di poter implementare agenti davvero autonomi su larga scala, le aziende devono predisporre quattro elementi, e la maggior parte non ne ha ancora nessuno. Il primo è il rilevamento in tempo reale: sapere, nel momento stesso in cui viene creato, ogni agente in esecuzione, chi ne è responsabile e con quale identità opera.

Il secondo è l’applicazione delle regole in linea, prima che un’azione venga eseguita. Terzo, le aziende hanno bisogno di un monitoraggio continuo delle derive, perché gli agenti restano attivi anche dopo la fine della sessione che li ha creati e il loro ambito operativo può ampliarsi senza che nessuno se ne accorga. Infine, serve una registrazione a prova di manomissione di ogni decisione presa da un agente, collegata ai quadri di riferimento effettivamente riconosciuti da revisori e autorità di regolamentazione. È questo il livello di controllo che stiamo sviluppando in Drata. Senza di esso, un’azienda che implementa agenti autonomi su larga scala non fa altro che affidarsi alla speranza.

Grazie per questa splendida intervista. I lettori che desiderano approfondire la governance degli agenti di IA, la conformità continua e i controlli contro le minacce interne legate agli agenti possono visitare Drata.