Jacob Ideskog, CTO af Curity – Intervju-serie

Jacob Ideskog er en identitetsspecialist og CTO i Curity. Det meste af hans tid bruges på at arbejde med sikkerheds løsninger i API og web-rummet. Han har arbejdet med både design og implementering af OAuth og OpenID Connect-løsninger for store virksomhedsinstallationer såvel som små start-ups.

Curity er en moderne identitet- og adgangs-styresystem (IAM) platform bygget omkring Curity Identity Server, en standard-baseret løsning designet til at sikre autentificering og autorisation for applikationer, API’er og digitale tjenester i stor målestok. Den understøtter protokoller som OAuth 2.0 og OpenID Connect til at centralisere login-flows, gennemtvinge finmasket adgangspolitik og udstede sikre tokens for både menneskelige brugere og maskin-klienter, herunder API’er og tjenester. Platformen er designet til fleksibilitet og skalerbarhed, hvilket giver virksomheder mulighed for at installere på tværs af cloud, hybrid- eller on-premises-miljøer, integrere med eksisterende systemer og levere sikre, ubrudte brugeroplevelser uden at afhænge af brugerdefineret sikkerheds-infrastruktur.

De har brugt meget af deres karriere på at bygge identitet- og API-sikkerhedssystemer, fra at co-founde Curity til at lede det som CTO gennem skyens og nu AI’s opkomst. Hvordan har denne rejse formet deres syn på, at AI-agenter skal behandles som førsteklasses digitale identiteter og ikke kun som et stykke software?

Over hver enkelt teknologi, jeg har arbejdet med, dukker ét problem op. Enten det er sky-computing eller nu AI, hvis software handler på vegne af en person eller et andet system, har man et identitetsproblem.

Med den massive tilgang af agentic AI, kompliceres dette problem. Deres adfærd er ikke længere strengt scriptet, og de opererer med en niveau af autonomi, som virksomheder aldrig har set før. AI-agenter tager beslutninger, kalder API’er og kæder handlinger på tværs af systemer – ofte uden direkte menneskelig oversigt. Dette adfærd skaber identitets- og adgangsudfordringer, som er fundamentalt forskellige fra traditionel software.

At behandle AI-agenter som førsteklasses digitale identiteter er den eneste måde at tackle dette problem på. Hvis virksomheder behandler dem som bare et andet process eller service-konto, mister de synlighed og kontrol meget hurtigt – og det er en opskrift på en sikkerhedskrise.”

Mange virksomheder er begejstret for agentic AI, men er fastlåst i eksperimentation. Fra hvad de ser i rigtige installationer, hvad er de mest almindelige identitets- og styre-lukker, der forhindrer virksomheder i at skala agenter sikkert?

De fleste eksperimenter sker i isolerede sandkasser, der ignorerer, hvad der sker i stor målestok. Under tidlige piloter giver teams ofte agenter brede API-nøgler, fælles legitimationsoplysninger eller blanket-cloud-tilgange bare for at komme i gang.

Denne tilgang falder fra hinanden, øjeblikket agenter er installeret ud over piloter. Dette skyldes, at sikkerhedsteams ikke kan se, hvilke data en agent har adgang til, dens handlinger eller om den kan eller har overskredet sin intentionerede omfang; enten utilsigtet eller ondsindet. Disse blinde pletter gør det umuligt at styre agenter sikkert, hvilket er, hvorfor mange virksomheder kæmper med at flytte sig ud over piloter.”

De har argumenteret for, at strenge guardrails er essentielle for agentic AI. Hvad ser “god” identitetsdesign ud som for AI-agenter i praksis, og hvor fejler virksomheder typisk?

God identitetsdesign starter med principperne om mindst mulig tilladelse og tilladelser knyttet til eksplicit intention. Hver AI-agent skal have sin egen identitet, snævert definerede tilladelser og klart definerede tillidsforhold (eksplicit regler for, hvilke systemer den er tilladt at interagere med). Grundlæggende skal adgang være formål-bunden, tidsbegrænset og let at tilbagekalde.

Hvor virksomheder fejler, er ved at genbruge eksisterende service-konti eller antage, at interne agenter er sikre som standard. Den antagelse holder ikke op mod virkelige trusler. Ondsindede aktører søger aktivt efter netop disse svage punkter, og AI-agenter øger dramatisk det potentielle skadeområde, når identitetsdesign er slapt.”

Curity har længe arbejdet med standarder som OAuth og OpenID Connect. Hvordan kritisk er åbne identitetsstandarder for at gøre agentic AI interoperabel og sikker på tværs af komplekse virksomheds-miljøer?

Åbne standarder er absolut kritisk. Virksomheder kører allerede komplekse identitets-tekstiler, der spænder over cloud-platforme, SaaS-tjenester og interne API’er. Agentic AI tilføjer endnu mere kompleksitet.

Uden standarder bliver hver agent sin egen integration og en permanent sikkerheds-undtagelse. Med standarder som OAuth og OpenID Connect kan agenter være autentificeret, autoriseret og auditeret ligesom enhver anden workload. Dette er den eneste tilgang, der kan faciliterer sikker skalerbarhed på tværs af rigtige virksomheds-miljøer.”

Ikke-menneskelige identiteter bliver mere almindelige, fra service-konti til maskin-identiteter. Hvad gør AI-agenter fundamentalt forskellige fra tidligere ikke-menneskelige identiteter fra et sikkerhedsperspektiv?

Nøgleforskellen mellem moderne AI-agenter og ældre ikke-menneskelige identiteter (NHIs) er autonomi. En traditionel service-konto gør præcis, hvad dens kode siger den skal gøre, strengt bundet til dens opgave. En AI-agent fortolker instruktioner, tilpasser sin adfærd og tager handlinger, der aldrig blev eksplisit skrevet – og det øger den potentielle fare, hvis der ikke er passende guardrails.

En lille identitets- eller adgangsfejl kan hurtigt udvikle sig til en katastrofe, fordi en agent kan handle med hast og på tværs af multiple systemer. Fra et sikkerhedsperspektiv præsenterer dette en stor risiko.

Hvor vigtig er audit-spor og identitets-baseret logging for at styre agentic AI, især i regulerede brancher?

Audit-spor skal ikke være “rart at have”. De skal være bygget ind fra starten. I regulerede miljøer forventes virksomheder at svare på simple, men kritiske spørgsmål: Hvad har denne agent adgang til, hvornår skete det, og hvem autoriserede det?

Identitets-baseret logging er den eneste pålidelige måde at få det niveau af ansvarlighed. Det spiller også en nøglerolle i incident-svar. Uden klart identitetskontekst er det næsten umuligt at vide, om et problem kommer fra en misbehaving agent, en kompromitteret identitet eller bare en dårlig prompt.

Hvilke virkelige risici ser de, når virksomheder installerer over-privilegerede eller dårligt overvågede AI-agenter i produktion?

En almindelig risiko er stille data-aggregat. En over-privilegeret agent kan trække følsomme oplysninger fra multiple systemer (kundeoptegnelser, interne dokumenter, logs) og derefter eksponere disse data via prompts, sammenfattelser eller eksterne integrationer.

En anden risiko er agenter med administrator-adgang, der foretager store ændringer med maskine-hast, og forårsager langt mere skade end et menneske nogensinde kunne på en kort periode. Dette kan inkludere ændring af cloud-resourcer, deaktivering af sikkerheds-kontroller eller udløsning af automatiserede arbejdsgange uden oversigt.

Disse episoder kan være ondsindede, men de behøver ikke at være det. En over-privilegeret eller dårligt overvåget agent kan blot operere på forældede eller forkerte antagelser, og forstærke fejl på tværs af multiple systemer, før nogen lægger mærke til det.

Men fra en angribers perspektiv er en kompromitteret agent-identitet ekstremt værdifuld. Den giver mulighed for lateral bevægelse på tværs af API’er og tjenester, ofte med et niveau af adgang, som ingen menneskelig bruger nogensinde ville blive tildelt. Uden stærke identitets-kontroller og overvågning opdager virksomheder ofte kun disse fejl efter, at reel skade er sket.”

For virksomheder, der flytter fra piloter til rigtige agentic-installationer, hvilke identitets- og adgangs-beslutninger skal være truffet tidligt for at undgå dyre om-designs senere?

Virksomheder skal beslutte tidligt, hvordan agenter tildeles identiteter, hvordan tilladelser godkendes og hvordan adgang gennemgås over tid, og definere identitets-grænser på forhånd.

At bringe identitets-kontroller retroaktivt er næsten altid problematisk. Agenter er ofte integreret dybt i arbejdsgange med fælles legitimationsoplysninger eller brede roller, så at stramme adgang efterfølgende bryder antagelser, som systemet afhænger af. Dette underminerer tillid til teknologien. Det er langt billigere, og ikke mindst langt sikrere, at designe ordentlige identiteter, omfang og adgangs-grænser fra starten.

Hvor bliver identitets-integration oftest en flaskehals, når man ruller ud agentic AI, og hvilke bedste praksis hjælper med at reducere friktion?

Identitets-styring kan blive en flaskehals, men kun når det behandles som en eftertanke. Teams fokuserer på at bygge imponerende agent-kapaciteter først og læser derefter, at de skal integreres med IAM-systemer, API-gateways og logging-platforme for at være rigtig sikre.

Den bedste tilgang er at starte med en klar forståelse og ordentlig implementering af identitets-platforme og derefter designe agenter til at passe indenfor dem. Virksomheder skal genbruge eksisterende standarder og infrastruktur i stedet for at omgå dem; at skære denne hjørne vil uundgåeligt skabe problemer længere nede på linjen. Når identitet er bygget ind fra starten, accelererer det installationen i stedet for at bremse den.

For sikkerheds- og ingeniørledere, der ønsker at omfavne agentic AI, men er bekymret for styring og risiko, hvilket råd ville de give, mens de planlægger deres vejviser?

Langsomt nok til at få grundlaget rigtigt. AI-agenter skal behandles som identiteter, og så skal man anvende samme styring, som man forventer af mennesker, og insisterer på synlighed fra starten. Hvis en virksomhed gør det, bliver skalerbarhed af agentic AI en øvelse i sikkerhed, og ikke et blindt og risikabelt spring.

Tak for det store interview, læsere, der ønsker at lære mere, skal besøge Curity.