Jacob Ideskog, CTO i Curity – Intervju-serie

Jacob Ideskog er en identitetsspesialist og CTO i Curity. Det meste av hans tid brukes på å arbeide med sikkerhetsløsninger i API- og nettrommet. Han har arbeidet med både å designe og implementere OAuth- og OpenID Connect-løsninger for store bedriftsinstallasjoner samt små start-ups.

Curity er en moderne identitets- og tilgangsadministrasjonsplattform (IAM) bygget rundt Curity Identity Server, en standardbasert løsning designet for å sikre autentisering og autorisering for applikasjoner, API-er og digitale tjenester i stor skala. Den støtter protokoller som OAuth 2.0 og OpenID Connect for å sentralisere innloggingsflyter, pålegge finmasket tilgangspolitikk og utstede sikre token for både menneskelige brukere og maskinklienter, inkludert API-er og tjenester. Plattoformen er designet for fleksibilitet og skalerbarhet, og lar organisasjoner deployere over sky, hybrid eller på-prem-miljøer, integrere med eksisterende systemer og levere sikre, sammenhengende brukeropplevelser uten å avhenge av tilpasset sikkerhetsinfrastruktur.

Du har brukt mye av din karriere på å bygge identitets- og API-sikkerhetssystemer, fra å være med å grunnlegge Curity til å lede det som CTO gjennom skyens og nå AI-æraen. Hvordan har denne reisen formet din oppfatning av at AI-agenter bør behandles som førsteklasses digitale identiteter, og ikke bare som et annet stykke programvare?

Over hver eneste teknologifelt jeg har arbeidet med, dukker ett problem opp igjen. Uansett om det er skydatamaskiner eller nå AI, hvis programvaren handler på vegne av en person eller et annet system, har du et identitetsproblem.

Med den massive tilpasningen av agens AI, blir dette problemet forsterket. Deres atferd er ikke lenger tett skrevet og de opererer med en grad av autonomi som bedrifter aldri har sett før. AI-agenter tar beslutninger, kaller API-er og kjeder handlinger over systemer – ofte uten direkte menneskelig tilsyn. Dette oppførslet skaper identitets- og tilgangsutfordringer som er fundamentalt forskjellige fra tradisjonell programvare.

Å behandle AI-agenter som førsteklasses digitale identiteter er den eneste måten å håndtere dette på. Hvis organisasjoner behandler dem som bare et annet prosess eller tjenekonto, mister de synlighet og kontroll raskt – og det er en oppskrift for en sikkerhetskriser.”

Mange bedrifter er begeistret for agens AI, men sitter fast i eksperimentelle fasen. Fra det du ser i virkelige deployeringer, hva er de vanligste identitets- og styringsgapene som forhindrer organisasjoner fra å skalerer agenter trygt?

De fleste eksperimentene skjer i isolerte sandkasser som ignorerer hva som skjer i stor skala. Under tidlige piloter, gir team ofte agenter brede API-nøkler, delt autentisering eller blankettsky-permisjoner bare for å komme i gang.

Dette tilretteleggingen faller fra hverandre øyeblikket agenter deployeres utenfor piloter. Dette skyldes at sikkerhetsteam ikke kan se hva data en agent har aksessert, dens handlinger eller om den kan eller har overskredet sin ment å omfatte; enten utilsiktet eller ondsinnet. Disse blinde flekkene gjør det umulig å styre agenter trygt, og det er derfor mange organisasjoner sliter med å flytte seg beyond piloter.”

Du har argumentert for at strenge retningslinjer er essensielle for agens AI. Hva ser “god” identitetsdesign ut som for AI-agenter i praksis, og hvor feiler selskaper vanligvis?

God identitetsdesign starter med prinsippet om minst mulig privilegium og tillatelser knyttet til eksplisitt intensjon. Hver AI-agent bør ha sin egen identitet, smalt definerte tillatelser og tydelig definerte tillitsforhold (eksplisitte regler for hvilke systemer det er tillatt å samhandle med). Grunnleggende sett bør tilgang være formål-bundet, tidsbegrenset og lett å tilbakekalle.

Hvor selskaper feiler i dette, er ved å gjenbruke eksisterende tjenekontoer eller anta at interne agenter er trygge som standard. Den antagelsen holder ikke mot virkelige trusler. Ondsinnede aktører søker aktivt etter nettopp disse svake punktene, og AI-agenter øker potensielt skadeområdet når identitetsdesign er slapt.”

Curity har lenge arbeidet med standarder som OAuth og OpenID Connect. Hvor kritisk er åpne identitetsstandarder for å gjøre agens AI interoperabel og sikker over komplekse bedriftsmiljøer?

Åpne standarder er absolutt kritisk. Bedrifter kjører allerede komplekse identitetsvev over skyplattformer, SaaS-tjenester og interne API-er. Agens AI legger bare til mer kompleksitet.

Uten standarder, blir hver agent sin egen integrasjon og en permanent sikkerhetsunntak. Med standarder som OAuth og OpenID Connect, kan agenter autentiseres, autoriseres og auditeres akkurat som noen annen arbeidsbyrde. Dette er den eneste tilnærmingen som kan fasilitere sikker skalerings over virkelige bedriftsmiljøer.”

Ikke-menneskelige identiteter blir mer vanlige, fra tjenekontoer til maskinidentiteter. Hva gjør AI-agenter fundamentalt forskjellige fra tidligere ikke-menneskelige identiteter fra et sikkerhetsperspektiv?

Forskjellen mellom moderne AI-agenter og eldre ikke-menneskelige identiteter (NHI) er autonomi. En tradisjonell tjenekonto gjør eksakt hva dens kode forteller den å gjøre, bundet strengt til sin oppgave. En AI-agent tolker instruksjoner, tilpasser sin atferd og tar handlinger som aldri ble eksplisitt skrevet –  alt øker den potensielle faren hvis det ikke er passende retningslinjer.

En liten identitets- eller tilgangsfeil kan raskt bli en katastrofe, fordi en agent kan handle med hastighet og over flere systemer. Fra et sikkerhetsperspektiv, presenterer dette en stor risiko.

Hvor viktig er audit-spor og identitetsbasert logging for å styre agens AI, spesielt i regulerte industrier?

Audit-spor bør ikke være “hyggelig å ha”. De må være bygget inn fra starten. I regulerte miljøer, forventes organisasjoner å svare på enkle, men kritiske spørsmål: hva aksesserte denne agenten, når skjedde det, og hvem autoriserte det?

Identitetsbasert logging er den eneste pålitelige måten å få denne nivået av ansvar. Det spiller også en nøkkelrolle i hendelsesrespons. Uten tydelig identitetskontekst, er det nesten umulig å vite om et problem kom fra en mislykket agent, en kompromittert identitet eller bare en dårlig prompt.

Hva virkelige risikoer ser du når organisasjoner deployer over-privilegerede eller dårlig overvåkede AI-agenter i produksjon?

En vanlig risiko er stille dataaggregasjon. En over-privilegeret agent kan trekke sensitiv informasjon fra flere systemer (kunderekorder, interne dokumenter, logger) og så eksponere denne dataen gjennom promter, sammenfatninger eller eksterne integrasjoner.

En annen risiko er agenter med administrativ tilgang som gjør store endringer med maskinhastighet, og forårsaker langt mer skade enn en menneskelig kunne i en kort periode. Dette kan inkludere å modifisere skyressurser, deaktivere sikkerhetskontroller eller utløse automatiske arbeidsflyter uten tilsyn.

Disse hendelsene kan være ondsinnet, men de må ikke være det. En over-privilegeret eller dårlig overvåket agent kunne bare operere på stale eller feilaktige antagelser, og forsterke feil over flere systemer før noen legger merke til.

Men, fra en angripers perspektiv, er en kompromittert agentidentitet ekstremt verdifull. Den muliggjør laterale bevegelser over API-er og tjenester, ofte med en tilgangsnivå som ingen menneskelig bruker noen gang ville bli tildelt. Uten sterke identitetskontroller og overvåking, oppdager organisasjoner ofte bare feilene etter at virkelig skade er gjort.”

For selskaper som flytter fra piloter til virkelige agens-deployeringer, hva identitets- og tilgangsbeslutninger bør tas tidlig for å unngå dyre omkonstruksjoner senere?

Organisasjoner bør bestemme tidlig hvordan agenter utstedes identiteter, hvordan tillatelser godkjennes og hvordan tilgang gjennomgås over tid, og definere identitetsgrenser på forhånd.

Å bringe inn identitetskontroller retroaktivt er nesten alltid problematisk. Agenter er ofte dypt integrert i arbeidsflyter med delt autentisering eller brede roller, så å stramme tilgang etter faktum bryter antagelser systemet avhenger av. Dette fører til at arbeidsflyter feiler og undergraver tillit til teknologien. Det er langt billigere, og ikke minst tryggere, å designe korrekte identiteter, omfang og tilgangsgrenser fra starten.

Hvor blir identitets-integrasjon oftest en flaskehals når man ruller ut agens AI, og hva er best praksis for å redusere friksjon?

Identitetsstyring kan bli en flaskehals, men bare når det behandles som en ettertanke. Team fokuserer på å bygge imponerende agent-kapasiteter først, og senere innser de at de må integreres med IAM-systemer, API-gateway og logging-plattformer for å være trygg.

Den beste tilnærmingen er å starte med en tydelig forståelse og korrekt implementering av identitetsplattformer, og deretter designe agenter til å passe innenfor dem. Organisasjoner bør gjenbruke eksisterende standarder og infrastruktur i stedet for å omgå dem; å kutte denne hjørnet vil uunngåelig føre til problemer senere. Når identitet er bygget inn fra starten, akselerer det deployering i stedet for å bremse den.

For sikkerhets- og ingeniørledere som ønsker å omfavne agens AI, men er bekymret for styring og risiko, hva råd ville du gi dem når de planlegger sin veikart?

Senk farten bare nok til å få grunnlaget riktig. AI-agenter må behandles som identiteter, og du må bruke samme styring du forventer for mennesker, og insisterer på synlighet fra starten. Hvis en organisasjon gjør det, blir skalerings agens AI en øvelse i sikkerhet, ikke et blindt og risikofylt sprang.

Takk for det flotte intervjuet, lesere som ønsker å lære mer, kan besøke Curity.