Jacob Ideskog, CTO di Curity – Serie di interviste

Jacob Ideskog È Identity Specialist e CTO presso Curity. Dedica la maggior parte del suo tempo a soluzioni di sicurezza in ambito API e web. Ha collaborato alla progettazione e all'implementazione di soluzioni OAuth e OpenID Connect per grandi aziende e piccole startup.

Sicurezza è una moderna piattaforma di gestione delle identità e degli accessi (IAM) basata su 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 policy di accesso granulari ed emettere token sicuri sia per gli utenti umani che per i client macchina, incluse API e servizi. La piattaforma è progettata per garantire flessibilità e scalabilità, consentendo alle organizzazioni di implementare in ambienti cloud, ibridi o on-premise, integrarsi con i sistemi esistenti e offrire esperienze utente sicure e fluide senza dover ricorrere a un'infrastruttura di sicurezza personalizzata.

Hai dedicato gran parte della tua carriera allo sviluppo di sistemi di sicurezza per identità e API, dalla co-fondazione di Curity alla sua guida come CTO, passando per l'ascesa del cloud e ora dell'intelligenza artificiale. In che modo questo percorso ha plasmato la tua visione secondo cui gli agenti di intelligenza artificiale dovrebbero essere trattati come identità digitali di prima classe piuttosto che come un semplice software?

In ogni campo della tecnologia in cui ho lavorato, un problema continua a riemergere. Che si tratti di cloud computing o, ora, di intelligenza artificiale, 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 dell'intelligenza artificiale agentiva, questo problema si aggrava. Il loro comportamento non è più rigidamente programmato e operano con un livello di autonomia che le aziende non hanno mai visto prima. Gli agenti di intelligenza artificiale prendono decisioni, richiamano API e concatenano azioni tra i sistemi, spesso senza la supervisione umana diretta. Questo comportamento crea sfide di identità e accesso fondamentalmente diverse da quelle dei software tradizionali.

Trattare gli agenti di intelligenza artificiale come identità digitali di prima classe è l'unico modo per affrontare adeguatamente la situazione. Se le organizzazioni li trattano come un semplice account di processo o servizio, perdono visibilità e controllo molto rapidamente, e questa è la ricetta per una crisi di sicurezza".

Molte aziende sono entusiaste dell'intelligenza artificiale agentica, ma rimangono bloccate nella sperimentazione. Da quanto si osserva nelle implementazioni reali, quali sono le lacune più comuni in termini 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 ciò che accade su larga scala. Durante i primi progetti pilota, i team spesso forniscono agli agenti chiavi API generiche, credenziali condivise o autorizzazioni cloud generiche solo per far partire il progetto.

Questo approccio fallisce nel momento in cui gli agenti vengono distribuiti oltre i progetti pilota. Questo perché i team di sicurezza non possono vedere a quali dati ha avuto accesso un agente, le sue azioni o se ha superato o superato l'ambito previsto, accidentalmente o intenzionalmente. Questi punti ciechi rendono impossibile governare gli agenti in modo sicuro, motivo per cui molte organizzazioni faticano ad andare oltre i progetti pilota.

Hai sostenuto che per l'intelligenza artificiale agentica sono essenziali rigidi limiti di sicurezza. Come si presenta nella pratica una "buona" progettazione dell'identità per gli agenti di intelligenza artificiale e dove le aziende in genere sbagliano?

Una buona progettazione dell'identità inizia con il principio del privilegio minimo e con autorizzazioni legate a un intento esplicito. Ogni agente di intelligenza artificiale dovrebbe avere una propria identità, autorizzazioni limitate e relazioni di fiducia chiaramente definite (regole esplicite per stabilire con quali sistemi è autorizzato a interagire). Fondamentalmente, l'accesso dovrebbe essere vincolato a uno scopo, limitato nel tempo e facilmente revocabile.

Le aziende sbagliano quando riutilizzano gli account di servizio esistenti o danno per scontato che gli agenti interni siano sicuri di default. Questa supposizione non regge di fronte alle minacce del mondo reale. I malintenzionati cercano attivamente proprio questi punti deboli e gli agenti di intelligenza artificiale aumentano drasticamente il potenziale raggio di azione quando la progettazione dell'identità è approssimativa.

Curity collabora da tempo con standard come OAuth e OpenID Connect. Quanto sono importanti gli standard di identità aperti per rendere l'IA agentica interoperabile e sicura in ambienti aziendali complessi?

Gli standard aperti sono assolutamente essenziali. Le aziende gestiscono già complesse infrastrutture di identità che abbracciano piattaforme cloud, servizi SaaS e API interne. L'intelligenza artificiale agentica non fa che aggiungere ulteriore complessità.

Senza standard, ogni agente diventa un'integrazione a sé stante 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 in grado di facilitare la scalabilità sicura in ambienti aziendali reali.

Le identità non umane stanno diventando sempre più comuni, dagli account di servizio alle identità delle macchine. Cosa rende gli agenti di intelligenza artificiale fondamentalmente diversi dalle precedenti identità non umane dal punto di vista della sicurezza?

La differenza fondamentale tra i moderni agenti di intelligenza artificiale e le vecchie identità non umane (NHI) è l'autonomia. Un account di servizio tradizionale fa esattamente ciò che il suo codice gli dice di fare, strettamente legato al suo compito. Un agente di intelligenza artificiale interpreta le istruzioni, adatta il suo comportamento e intraprende azioni che non sono mai state esplicitamente programmate, il che aumenta il potenziale pericolo in assenza di adeguate misure di sicurezza.

Un piccolo errore di identità o di accesso può trasformarsi rapidamente in una catastrofe, perché un agente può agire rapidamente e su più sistemi. Dal punto di vista della sicurezza, questo rappresenta un rischio significativo.

Quanto sono importanti i tracciati di controllo e la registrazione basata sull'identità per la gestione dell'intelligenza artificiale agentiva, soprattutto nei settori regolamentati?

Le tracce di controllo non dovrebbero essere un "optional". Devono essere integrate fin dall'inizio. Negli ambienti regolamentati, le organizzazioni sono tenute a rispondere a domande semplici ma cruciali: a cosa ha avuto accesso questo agente, quando è successo e chi lo ha autorizzato?

La registrazione basata sull'identità è l'unico modo affidabile per ottenere questo livello di responsabilità. Svolge anche un ruolo chiave nella risposta agli incidenti. Senza un contesto di identità chiaro, è quasi impossibile sapere se un problema deriva da un agente che si comporta male, da un'identità compromessa o semplicemente da un prompt errato.

Quali rischi reali si presentano quando le organizzazioni implementano agenti di intelligenza artificiale con privilegi eccessivi o scarsamente monitorati in produzione?

Un rischio comune è l'aggregazione silenziosa dei dati. Un agente con privilegi eccessivi può estrarre informazioni sensibili da più sistemi (record dei clienti, documenti interni, log) e quindi esporre tali dati tramite prompt, riepiloghi o integrazioni esterne.

Un altro rischio è che gli agenti con accesso amministrativo apportino modifiche sostanziali alla velocità della macchina, causando danni molto maggiori di quelli che un essere umano potrebbe mai causare in un breve lasso di tempo. Questo può includere la modifica delle risorse cloud, la disattivazione dei controlli di sicurezza o l'attivazione di flussi di lavoro automatizzati senza supervisione.

Questi incidenti potrebbero essere dolosi, ma non necessariamente. Un agente con privilegi eccessivi o scarsamente monitorato potrebbe semplicemente operare sulla base di presupposti obsoleti o errati, amplificando gli errori su più sistemi prima che qualcuno se ne accorga.

Tuttavia, dal punto di vista di un aggressore, l'identità di un agente compromessa è estremamente preziosa. Consente spostamenti laterali tra API e servizi, spesso con un livello di accesso che nessun utente umano potrebbe mai ottenere. Senza controlli e monitoraggio rigorosi dell'identità, le organizzazioni spesso scoprono questi fallimenti solo dopo che il danno è stato effettivamente causato.

Per le aziende che passano dai progetti pilota alle vere e proprie implementazioni agentiche, quali decisioni in materia di identità e accesso dovrebbero essere prese tempestivamente per evitare costose riprogettazioni in seguito?

Le organizzazioni dovrebbero decidere in anticipo come vengono assegnate le identità agli agenti, come vengono approvate le autorizzazioni e come viene verificato l'accesso nel tempo, definendo in anticipo i limiti delle identità.

L'introduzione retroattiva dei controlli di identità è quasi sempre problematica. Gli agenti sono spesso integrati in profondità nei flussi di lavoro utilizzando credenziali condivise o ruoli ampi, quindi restringere l'accesso a posteriori compromette i presupposti su cui si basa il sistema. Questo, in ultima analisi, causa il fallimento dei flussi di lavoro e mina la fiducia nella tecnologia. È molto più economico, per non dire molto più sicuro, progettare identità, ambiti e limiti di accesso adeguati fin dall'inizio.

In quali punti l'integrazione delle identità diventa più spesso un collo di bottiglia quando si implementa l'intelligenza artificiale agentiva e quali best practice aiutano a ridurre gli attriti?

La gestione delle identità può diventare un collo di bottiglia, ma solo se viene gestita in un secondo momento. I team si concentrano inizialmente sullo sviluppo di potenti funzionalità per gli agenti, per poi rendersi conto che devono essere integrate con sistemi IAM, gateway API e piattaforme di logging per essere realmente sicure.

L'approccio migliore è iniziare con una chiara comprensione e una corretta implementazione delle piattaforme di identità, per poi progettare agenti che si adattino a esse. Le organizzazioni dovrebbero riutilizzare gli standard e le infrastrutture esistenti anziché aggirarli; tagliare questo limite causerà inevitabilmente problemi in futuro. Quando l'identità è integrata fin dall'inizio, accelera l'implementazione anziché rallentarla.

Che consiglio daresti ai responsabili della sicurezza e dell'ingegneria che desiderano adottare l'intelligenza artificiale agentiva ma sono preoccupati per la governance e il rischio nella pianificazione della loro roadmap?

Rallentate quel tanto che basta per gettare le basi giuste. Gli agenti di intelligenza artificiale devono essere trattati come identità, quindi è necessario applicare la stessa governance che ci si aspetta per gli esseri umani, insistendo sulla visibilità fin dall'inizio. Se un'organizzazione adotta questo approccio, scalare l'intelligenza artificiale agentica diventa un esercizio di sicurezza, non un cieco e rischioso atto di fede.

Grazie per l'ottima intervista, i lettori che desiderano saperne di più dovrebbero visitare Sicurezza.