Interviste
Jacob Ideskog, CTO di Curity – Serie di Interviste
Jacob Ideskog è uno specialista di identità e CTO di Curity. La maggior parte del suo tempo è spesa lavorando con soluzioni di sicurezza nello spazio API e Web. Ha lavorato sia progettando che implementando soluzioni OAuth e OpenID Connect per grandi aziende e piccole startup.
Curity è una piattaforma di gestione delle identità e degli accessi (IAM) moderna costruita intorno al Curity Identity Server, una soluzione basata su standard progettata per proteggere l’autenticazione e l’autorizzazione per applicazioni, API e servizi digitali su larga scala. Supporta protocolli come OAuth 2.0 e OpenID Connect per centralizzare i flussi di accesso, applicare politiche di accesso granulari e rilasciare token sicuri per utenti umani e client machine, inclusi API e servizi. La piattaforma è progettata per essere flessibile e scalabile, consentendo alle organizzazioni di distribuire su cloud, ambienti ibridi o locali, integrarsi con sistemi esistenti e offrire esperienze utente sicure e senza interruzioni senza affidarsi a infrastrutture di sicurezza personalizzate.
Hai trascorso gran parte della tua carriera costruendo sistemi di sicurezza per identità e API, dalla co-fondazione di Curity alla guida come CTO attraverso l’ascesa del cloud e ora dell’AI. Come ti ha influenzato questo percorso nella tua visione che gli agenti AI dovrebbero essere trattati come identità digitali di prima classe e non solo come un altro pezzo di software?
In ogni campo della tecnologia in cui ho lavorato, un problema continua a riproporsi. Che si tratti di cloud computing o ora di AI, se il software agisce per conto di una persona o di un altro sistema, si ha un problema di identità.
Con l’adozione di massa di AI agente, questo problema si complica. Il loro comportamento non è più strettamente scriptato e operano con un livello di autonomia che le aziende non hanno mai visto prima. Gli agenti AI prendono decisioni, chiamano API e concatenano azioni attraverso sistemi – spesso senza la diretta supervisione umana. Questo comportamento crea sfide di identità e accesso fondamentalmente diverse da quelle del software tradizionale.
Trattare gli agenti AI come identità digitali di prima classe è l’unico modo per affrontare questo problema correttamente. Se le organizzazioni li trattano come un altro processo o account di servizio, perdono visibilità e controllo molto rapidamente – e questo è una ricetta per una crisi di sicurezza.”
Molte aziende sono entusiaste dell’AI agente ma rimangono bloccate nella sperimentazione. Da ciò che vedi nelle distribuzioni reali, quali sono le lacune più comuni di identità e governance che impediscono alle organizzazioni di scalare gli agenti in modo sicuro?
La maggior parte della sperimentazione avviene in sandbox isolate che ignorano cosa succede su larga scala. Durante i primi piloti, i team spesso forniscono agli agenti chiavi API ampie, credenziali condivise o autorizzazioni cloud di tipo blanket solo per far partire le cose.
Questo approccio si sfalda nel momento in cui gli agenti vengono distribuiti oltre i piloti. Ciò avviene perché i team di sicurezza non possono vedere quali dati un agente ha accesso, le sue azioni o se può o ha superato il suo scopo previsto; sia accidentalmente che maliziosamente. Questi punti ciechi rendono impossibile governare gli agenti in modo sicuro, ed è per questo che molte organizzazioni lottano per andare oltre i piloti.”
Hai sostenuto che sono essenziali rigidi limiti per l’AI agente. Cosa significa “buon design” di identità per gli agenti AI nella pratica, e dove le aziende di solito sbagliano?
Un buon design di identità inizia con il principio del minimo privilegio e autorizzazioni legate a intenti espliciti. Ogni agente AI dovrebbe avere la sua identità, autorizzazioni a scopo limitato e relazioni di fiducia chiaramente definite (regole esplicite per i sistemi con cui è consentito interagire). Fondamentalmente, l’accesso dovrebbe essere vincolato allo scopo, limitato nel tempo e facile da revocare.
Le aziende sbagliano quando riutilizzano account di servizio esistenti o assumono che gli agenti interni siano sicuri per default. Questa assunzione non regge contro minacce reali. Gli attori malintenzionati cercano attivamente questi punti deboli, e gli agenti AI aumentano drasticamente il potenziale raggio di azione quando il design dell’identità è sciatto.”
Curity ha lavorato a lungo con standard come OAuth e OpenID Connect. Quanto sono critici gli standard di identità aperti per rendere l’AI agente interoperabile e sicuro attraverso ambienti aziendali complessi?
Gli standard aperti sono assolutamente critici. Le aziende già eseguono complessi tessuti di identità che coprono piattaforme cloud, servizi SaaS e API interne. L’AI agente aggiunge solo più complessità.
Senza standard, ogni agente diventa una propria integrazione e un’eccezione di sicurezza permanente. Con standard come OAuth e OpenID Connect, gli agenti possono essere autenticati, autorizzati e verificati come qualsiasi altro carico di lavoro. Questo è l’unico approccio che può facilitare la scalabilità sicura attraverso ambienti aziendali reali.”
Le identità non umane stanno diventando più comuni, dalle credenziali di servizio alle identità di macchina. Cosa rende gli agenti AI fondamentalmente diversi dalle precedenti identità non umane dal punto di vista della sicurezza?
La differenza chiave tra gli agenti AI moderni e le precedenti identità non umane (NHIs) è l’autonomia. Un account di servizio tradizionale fa esattamente ciò che il suo codice gli dice di fare, vincolato strettamente al suo compito. Un agente AI interpreta istruzioni, adatta il suo comportamento e compie azioni che non sono state mai esplicitamente scritte – aumentando il pericolo potenziale se non ci sono adeguate barriere di sicurezza.
Un piccolo errore di identità o accesso può rapidamente trasformarsi in una catastrofe, perché un agente può agire a velocità e su più sistemi. Dal punto di vista della sicurezza, questo presenta un rischio maggiore.”
Quanto sono importanti le tracce di audit e la registrazione basata sull’identità per la governance dell’AI agente, specialmente in settori regolamentati?
Le tracce di audit non dovrebbero essere “bello avere”. Devono essere costruite fin dall’inizio. In ambienti regolamentati, le organizzazioni sono tenute a rispondere a domande semplici ma critiche: cosa ha accesso questo agente, quando è successo e chi l’ha autorizzato?
La registrazione basata sull’identità è l’unico modo affidabile per ottenere quel livello di responsabilità. Gioca anche un ruolo chiave nella risposta agli incidenti. Senza un chiaro contesto di identità, è quasi impossibile sapere se un problema proveniva da un agente mal funzionante, un’identità compromessa o semplicemente una cattiva istruzione.”
Quali rischi reali vedi emergere quando le organizzazioni distribuiscono agenti AI sovra-privilegiati o scarsamente monitorati in produzione?
Un rischio comune è l’aggregazione silenziosa dei dati. Un agente sovra-privilegiato può estrarre informazioni sensibili da più sistemi (registri dei clienti, documenti interni, log) e poi esporre quei dati attraverso istruzioni, riassunti o integrazioni esterne.
Un altro rischio è che gli agenti con accesso amministrativo apportino modifiche significative a velocità di macchina, causando danni molto più gravi di quanto potrebbe fare un essere umano in un breve periodo di tempo. Ciò può includere la modifica di risorse cloud, la disabilitazione dei controlli di sicurezza o l’attivazione di workflow automatizzati senza supervisione.
Questi incidenti possono essere maliziosi, ma non devono esserlo. Un agente sovra-privilegiato o scarsamente monitorato potrebbe semplicemente operare su assunzioni obsolete o errate, amplificando errori su più sistemi prima che qualcuno se ne accorga.
Ma, dal punto di vista di un attaccante, un’identità di agente compromessa è estremamente preziosa. Consente il movimento laterale attraverso API e servizi, spesso con un livello di accesso che nessun utente umano avrebbe mai ricevuto. Senza controlli di identità forti e monitoraggio, le organizzazioni spesso scoprono questi fallimenti solo dopo che è stato fatto un danno reale.”
Per le aziende che passano dai piloti a distribuzioni reali di agenti, quali decisioni di identità e accesso dovrebbero essere prese precocemente per evitare costosi ridisegni successivi?
Le organizzazioni dovrebbero decidere precocemente come gli agenti ricevono identità, come le autorizzazioni vengono approvate e come l’accesso viene esaminato nel tempo, definendo i confini di identità in anticipo.
Introdurre controlli di identità in modo retroattivo è quasi sempre problematico. Gli agenti sono spesso integrati profondamente nei flussi di lavoro utilizzando credenziali condivise o ruoli ampi, quindi stringere l’accesso dopo il fatto rompe le assunzioni su cui il sistema si basa. Ciò alla fine fa fallire i flussi di lavoro e mina la fiducia nella tecnologia. È molto più economico, nonché più sicuro, progettare identità, ambiti e confini di accesso appropriati fin dall’inizio.”
Dove l’integrazione dell’identità diventa più spesso un collo di bottiglia quando si distribuisce l’AI agente, e quali best practice aiutano a ridurre l’attrito?
La gestione delle identità può diventare un collo di bottiglia, ma solo quando viene trattata come un pensiero successivo. I team si concentrano sul costruire capacità di agente impressionanti per poi rendersi conto che devono essere integrati con sistemi IAM, gateway API e piattaforme di logging per essere veramente sicuri.
L’approccio migliore è iniziare con una chiara comprensione e una corretta implementazione delle piattaforme di identità e poi progettare gli agenti per adattarsi a esse. Le organizzazioni dovrebbero riutilizzare standard e infrastrutture esistenti invece di bypassarle; tagliare questo angolo inevitabilmente causerà problemi in seguito. Quando l’identità è costruita fin dall’inizio, accelera la distribuzione invece di rallentarla.”
Per i leader di sicurezza e ingegneria che vogliono abbracciare l’AI agente ma sono preoccupati per la governance e il rischio, quale consiglio dareste mentre pianificano la loro roadmap?
Rallentate solo abbastanza per ottenere le fondamenta giuste. Gli agenti AI devono essere trattati come identità e quindi è necessario applicare la stessa governance che ci si aspetta per gli esseri umani, e insistere sulla visibilità fin dall’inizio. Se un’organizzazione fa questo, allora scalare l’AI agente diventa un esercizio di sicurezza, non un salto cieco e rischioso nella fede.”
Grazie per la grande intervista, i lettori che desiderano saperne di più possono visitare Curity.
