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 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 garantire 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 fine-granulari e rilasciare token sicuri per utenti umani e client di macchina, comprese API e servizi. La piattaforma è progettata per essere flessibile e scalabile, consentendo alle organizzazioni di distribuire su cloud, ibrido o ambienti locali, integrarsi con sistemi esistenti e offrire esperienze utente sicure e senza interruzioni senza affidarsi a infrastrutture di sicurezza personalizzate.

Ha trascorso gran parte della sua carriera costruendo sistemi di identità e sicurezza API, dal cofondare Curity al guidarla come CTO attraverso l’ascesa del cloud e ora dell’AI. Come ha plasmato la sua visione che gli agenti AI dovrebbero essere trattati come identità digitali di prima classe e non solo come un altro pezzo di software?

Attraverso ogni campo della tecnologia in cui ho lavorato, un problema continua a riemergere. Che si tratti di cloud computing o ora di AI, se un 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 predefinito 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 supervisione diretta umana. Questo comportamento crea sfide di identità e accesso che sono fondamentalmente diverse da quelle del software tradizionale.

Trattare gli agenti AI come identità digitali di prima classe è l’unico modo per affrontare questo problema in modo appropriato. Se le organizzazioni li trattano come un processo o un 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 vede nelle distribuzioni reali, quali sono le lacune di identità e governance più comuni 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 base solo per far partire le cose.

Questo approccio si dissolve non appena gli agenti vengono distribuiti oltre i piloti. Ciò accade 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 con cattive intenzioni. Queste aree cieche rendono impossibile governare gli agenti in modo sicuro, ed è per questo che molte organizzazioni lottano per andare oltre i piloti”.

Ha sostenuto che le barriere di protezione rigorose sono essenziali per l’AI agente. Cosa significa “buon design di identità” per gli agenti AI nella pratica e dove le aziende sbagliano tipicamente?

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 suppongono che gli agenti interni siano sicuri per default. Questa supposizione non regge contro minacce reali. Gli attori malintenzionati cercano attivamente proprio questi punti deboli, e gli agenti AI aumentano notevolmente il 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 in ambienti aziendali complessi?

Gli standard aperti sono assolutamente critici. Le aziende già eseguono complesse stoffe 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 proprio 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 identità non umane precedenti da una prospettiva di sicurezza?

La differenza chiave tra gli agenti AI moderni e le identità non umane (NHIs) più vecchie è l’autonomia. Un account di servizio tradizionale fa esattamente ciò che il suo codice gli dice di fare, strettamente vincolato al suo compito. Un agente AI interpreta istruzioni, adatta il suo comportamento e intraprende azioni che non sono mai state esplicitamente scritte – aumentando il pericolo potenziale se non ci sono adeguate barriere di protezione.

Un piccolo errore di identità o accesso può rapidamente trasformarsi in una catastrofe, poiché un agente può agire a velocità e su più sistemi. Da una prospettiva di 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 “belle da 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 contesto di identità chiaro, è quasi impossibile sapere se un problema proveniva da un agente mal funzionante, un’identità compromessa o semplicemente una cattiva istruzione.

Quali rischi reali vede 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 (record 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 molto più danno di quanto potrebbe fare un essere umano in un breve periodo di tempo. Ciò può includere la modifica delle risorse cloud, la disabilitazione dei controlli di sicurezza o l’attivazione di flussi di lavoro automatizzati senza supervisione.

Questi incidenti possono essere malintenzionati, 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, dalla prospettiva 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à e monitoraggio solidi, le organizzazioni scoprono spesso questi fallimenti solo dopo che è stato fatto un danno reale”.

Per le aziende che passano da piloti a distribuzioni di agenti AI reali, quali decisioni di identità e accesso dovrebbero essere prese presto per evitare costosi ridisegni successivi?

Le organizzazioni dovrebbero decidere presto come vengono rilasciate le identità degli agenti, come vengono approvate le autorizzazioni 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 sulle quali 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 sono le migliori pratiche per ridurre l’attrito?

La gestione delle identità può diventare un collo di bottiglia, ma solo quando viene trattata come un ripensamento. I team si concentrano sul costruire capacità di agente impressionanti per primo e solo successivamente si rendono conto di doverle integrare con sistemi IAM, gateway API e piattaforme di registrazione per essere veramente sicuri.

Il miglior approccio è iniziare con una chiara comprensione e una corretta implementazione delle piattaforme di identità e quindi 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 futuro. Quando l’identità è costruita fin dall’inizio, accelera la distribuzione invece di rallentarla.

Per i leader di sicurezza e ingegneria che desiderano abbracciare l’AI agente ma sono preoccupati per la governance e il rischio, quali consigli darebbe mentre pianificano la loro roadmap?

Rallentare 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 la scalabilità dell’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.