Jacob Ideskog, CTO på Curity – Intervjuserie

Jacob Ideskog är en identitetsspecialist och CTO på Curity. Största delen av hans tid tillbringar han med att arbeta med säkerhetslösningar inom API och webbområdet. Han har arbetat med både design och implementering av OAuth- och OpenID Connect-lösningar för stora företagsdistributioner samt små start-ups.

Curity är en modern plattform för identitet och åtkomsthantering (IAM) som bygger på Curity Identity Server, en standardbaserad lösning som är utformad för att säkra autentisering och auktorisering för applikationer, API:er och digitala tjänster i stor skala. Den stöder protokoll som OAuth 2.0 och OpenID Connect för att centralisera inloggningsflöden, tillämpa finmaskiga åtkomstprinciper och utfärda säkra token för både mänskliga användare och maskin klienter, inklusive API:er och tjänster. Plattformen är utformad för flexibilitet och skalbarhet, vilket möjliggör för organisationer att distribuera över moln, hybrid- eller lokala miljöer, integrera med befintliga system och leverera säkra, sömlösa användarupplevelser utan att förlita sig på anpassad säkerhetsinfrastruktur.

Du har tillbringat största delen av din karriär med att bygga identitets- och API-säkerhetssystem, från att co-funda Curity till att leda det som CTO genom molnets och nu AI:s uppgång. Hur har den resan format din syn på att AI-agenter bör behandlas som första klassens digitala identiteter snarare än bara en annan typ av programvara?

Över alla teknologiområden jag har arbetat med finns ett problem som ständigt återkommer. Oavsett om det gäller molnberäkning eller nu AI, så har man ett identitetsproblem om programvara agerar på uppdrag av en person eller ett annat system.

Med den massiva antagandet av agenter med AI förstärks detta problem. Deras beteende är inte längre hårt skriptat och de opererar med en nivå av autonomi som företag aldrig tidigare har sett. AI-agenter fattar beslut, anropar API:er och kedjar åtgärder över system – ofta utan direkt mänsklig tillsyn. Detta beteende skapar identitets- och åtkomstutmaningar som är fundamentalt annorlunda än traditionell programvara.

Att behandla AI-agenter som första klassens digitala identiteter är det enda sättet att hantera detta problem på rätt sätt. Om organisationer behandlar dem som bara en annan process eller tjänstekonto, så förlorar de synlighet och kontroll mycket snabbt – och det är ett recept för en säkerhetskris.”

Många företag är entusiastiska över agenter med AI men är fortfarande fast i experiment. Utifrån vad du ser i riktiga distributioner, vad är de vanligaste identitets- och styrningsgapen som förhindrar organisationer från att skala agenter på ett säkert sätt?

De flesta experiment sker i isolerade sandlådor som ignorerar vad som händer i stor skala. Under tidiga piloter ger team ofta agenter breda API-nycklar, delade autentiseringsuppgifter eller blankettmolntillstånd bara för att komma igång.

Detta tillvägagångssätt fungerar inte när agenter distribueras bortom piloter. Detta beror på att säkerhetsteam inte kan se vilken data en agent har åtkomst till, dess åtgärder eller om den kan eller har överskridit sitt avsedda omfång; antingen oavsiktligt eller illvilligt. Dessa blind fläckar gör det omöjligt att styra agenter på ett säkert sätt, vilket är varför många organisationer kämpar med att gå bortom piloter.”

Du har hävdat att strikta skyddsräcken är essentiella för agenter med AI. Vad ser en bra identitetsdesign ut som för AI-agenter i praktiken, och var vanligtvis får företag detta fel?

Bra identitetsdesign börjar med principen om minsta behörighet och behörigheter som är bundna till explicit avsikt. Varje AI-agent bör ha sin egen identitet, smalt definierade behörigheter och tydligt definierade förtroenderelationer (explicita regler för vilka system den är tillåten att interagera med). I grunden bör åtkomst vara syftesbunden, tidsbegränsad och lätt att återkalla.

Där företag får detta fel är genom att återanvända befintliga tjänstekonton eller anta att interna agenter är säkra som standard. Det antagandet håller inte mot verkliga hot. Malicious aktörer letar aktivt efter exakt dessa svaga punkter, och AI-agenter ökar dramatiskt den potentiella skadeområdet när identitetsdesignen är slarvig.”

Curity har länge arbetat med standarder som OAuth och OpenID Connect. Hur kritiska är öppna identitetsstandarder för att göra agenter med AI interoperabla och säkra över komplexa företagsmiljöer?

Öppna standarder är absolut kritiska. Företag kör redan komplexa identitetstexter som omfattar molnplattformar, SaaS-tjänster och interna API:er. Agenter med AI lägger bara till mer komplexitet.

Utan standarder blir varje agent sin egen integration och en permanent säkerhetsundantag. Med standarder som OAuth och OpenID Connect kan agenter autentiseras, auktoriseras och granskas precis som vilken annan arbetsbelastning som helst. Detta är den enda tillvägagångssätt som kan underlätta säker skalning över verkliga företagsmiljöer.”

Icke-mänskliga identiteter blir allt vanligare, från tjänstekonton till maskinidentiteter. Vad gör agenter med AI fundamentalt annorlunda än tidigare icke-mänskliga identiteter från ett säkerhetsperspektiv?

Den viktigaste skillnaden mellan moderna agenter med AI och äldre icke-mänskliga identiteter (NHIs) är autonomi. Ett traditionellt tjänstekonto gör exakt vad dess kod säger att det ska göra, bundet strikt till sin uppgift. En agent med AI tolkar instruktioner, anpassar sitt beteende och vidtar åtgärder som aldrig explicit skrivits – vilket ökar den potentiella faran om det inte finns lämpliga skyddsräcken.

En liten identitets- eller åtkomstfel kan snabbt förvandlas till en katastrof, eftersom en agent kan agera med hastighet och över flera system. Från ett säkerhetsperspektiv presenterar detta en stor risk.

Hur viktiga är granskningsloggningar och identitetsbaserad loggning för att styra agenter med AI, särskilt i reglerade branscher?

Granskningsloggningar bör inte vara “nice to have”. De måste byggas in från början. I reglerade miljöer förväntas organisationer svara på enkla men kritiska frågor: vad åtkomstade denna agent, när hände det och vem auktoriserade det?

Identitetsbaserad loggning är den enda tillförlitliga metoden för att få den nivån av ansvar. Den spelar också en nyckelroll i incidenthantering. Utan tydlig identitetskontext är det nästan omöjligt att veta om ett problem kom från en misskött agent, en komprometterad identitet eller bara en dålig prompt.

Vilka verkliga risker ser du som uppstår när organisationer distribuerar överprivilegierade eller dåligt övervakade agenter med AI i produktion?

En vanlig risk är tyst dataaggregering. En överprivilegierad agent kan hämta känslig information från flera system (kundregister, interna dokument, loggar) och sedan exponera den informationen genom prompter, sammanfattningar eller externa integrationer.

En annan risk är agenter med administrativ åtkomst som gör stora förändringar med maskinhastighet, vilket orsakar betydligt mer skada än en människa någonsin kunde under en kort period. Detta kan inkludera att modifiera molnresurser, inaktivera säkerhetskontroller eller utlösa automatiserade arbetsflöden utan tillsyn.

Detta kan vara avsiktligt, men det behöver inte vara det. En överprivilegierad eller dåligt övervakad agent kan helt enkelt operera på föråldrad eller felaktig information, förstärka misstag över flera system innan någon märker det.

Men från en angriparens perspektiv är en komprometterad agentidentitet extremt värdefull. Den möjliggör lateralt rörelse över API:er och tjänster, ofta med en nivå av åtkomst som ingen mänsklig användare någonsin skulle få. Utan starka identitetskontroller och övervakning upptäcker organisationer ofta bara dessa misslyckanden efter att verklig skada har skett.”

För företag som flyttar från piloter till riktiga distributioner av agenter med AI, vilka identitets- och åtkomstbeslut bör fattas tidigt för att undvika dyra omkonstruktioner senare?

Organisationer bör besluta tidigt om hur agenter tilldelas identiteter, hur behörigheter godkänns och hur åtkomst granskas över tid, och definiera identitetsgränser på förhand.

Att införa identitetskontroller i efterhand är nästan alltid problematiskt. Agenter är ofta inbäddade djupt i arbetsflöden med delade autentiseringsuppgifter eller breda roller, så att begränsa åtkomst i efterhand bryter mot antaganden som systemet förlitar sig på. Detta orsakar i slutändan att arbetsflöden misslyckas och undergräver förtroendet för tekniken. Det är mycket billigare, för att inte tala om säkrare, att utforma rätt identiteter, omfång och åtkomstgränser från början.

Där blir identitetsintegration ofta en flaskhals när man distribuerar agenter med AI, och vilka bästa metoder hjälper till att minska friktionen?

Identitetshantering kan bli en flaskhals, men bara när den behandlas som en eftertanke. Team fokuserar på att bygga imponerande agentfunktioner först, för att sedan inse att de måste integreras med IAM-system, API-gateways och loggningsplattformar för att vara riktigt säkra.

Det bästa tillvägagångssättet är att börja med en tydlig förståelse och korrekt implementering av identitetsplattformar, och sedan utforma agenter för att passa inom dem. Organisationer bör återanvända befintliga standarder och infrastruktur istället för att kringgå dem; att klippa hörnen kommer oundvikligen att orsaka problem längre fram. När identitet byggs in från början, så accelererar det distributionen istället för att sakta ner den.

För säkerhets- och teknikledare som vill anta agenter med AI men är oroliga för styrning och risk, vad skulle du ge för råd när de planerar sin väg?

Sakta ner tillräckligt för att få grunderna rätt. AI-agenter måste behandlas som identiteter, och så måste du tillämpa samma styrning som du förväntar dig av människor, och insistera på synlighet från början. Om en organisation gör det, så blir skalning av agenter med AI en övning i säkerhet, inte ett blind och riskfyllt språng.

Tack för den underbara intervjun, läsare som vill lära sig mer kan besöka Curity.