Jacob Ideskog, CTO van Curity – Interviewserie

Jacob Ideskog Hij is Identity Specialist en CTO bij Curity. Hij houdt zich voornamelijk bezig met beveiligingsoplossingen voor API's en webapplicaties. Hij heeft ervaring met het ontwerpen en implementeren van OAuth- en OpenID Connect-oplossingen voor zowel grote bedrijven als kleine startups.

Curity Curity is een modern platform voor identiteits- en toegangsbeheer (IAM), gebouwd rond de Curity Identity Server. Deze op standaarden gebaseerde oplossing is ontworpen om authenticatie en autorisatie voor applicaties, API's en digitale diensten op grote schaal te beveiligen. Het ondersteunt protocollen zoals OAuth 2.0 en OpenID Connect om inlogprocessen te centraliseren, gedetailleerde toegangsregels af te dwingen en veilige tokens uit te geven voor zowel menselijke gebruikers als machineclients, inclusief API's en services. Het platform is ontworpen voor flexibiliteit en schaalbaarheid, waardoor organisaties het kunnen implementeren in cloud-, hybride of on-premise omgevingen, integreren met bestaande systemen en veilige, naadloze gebruikerservaringen bieden zonder afhankelijk te zijn van een op maat gemaakte beveiligingsinfrastructuur.

Je hebt een groot deel van je carrière besteed aan het ontwikkelen van identiteits- en API-beveiligingssystemen, van het medeoprichten van Curity tot het leiden ervan als CTO tijdens de opkomst van de cloud en nu AI. Hoe heeft die reis je visie gevormd dat AI-agenten moeten worden behandeld als volwaardige digitale identiteiten in plaats van slechts een stukje software?

In alle technologische vakgebieden waarin ik heb gewerkt, duikt één probleem steeds weer op. Of het nu gaat om cloudcomputing of, meer recent, AI, als software namens een persoon of een ander systeem handelt, ontstaat er een identiteitsprobleem.

Door de massale toepassing van AI-agenten wordt dit probleem verergerd. Hun gedrag is niet langer strak geprogrammeerd en ze opereren met een mate van autonomie die bedrijven nog nooit eerder hebben gezien. AI-agenten nemen beslissingen, roepen API's aan en koppelen acties aan elkaar in verschillende systemen – vaak zonder direct menselijk toezicht. Dit gedrag brengt uitdagingen met zich mee op het gebied van identiteit en toegang die fundamenteel verschillen van traditionele software.

Het behandelen van AI-agenten als volwaardige digitale identiteiten is de enige manier om dit probleem adequaat aan te pakken. Als organisaties ze beschouwen als slechts een proces of serviceaccount, verliezen ze zeer snel het overzicht en de controle – en dat is een recept voor een beveiligingscrisis.”

Veel bedrijven zijn enthousiast over agentische AI, maar zitten nog vast in de experimentele fase. Wat zijn volgens u de meest voorkomende lacunes op het gebied van identiteitsbeheer en governance die organisaties ervan weerhouden om agents veilig op te schalen, gebaseerd op uw ervaringen met daadwerkelijke implementaties?

De meeste experimenten vinden plaats in geïsoleerde testomgevingen die geen rekening houden met wat er op grotere schaal gebeurt. Tijdens vroege pilots geven teams agents vaak algemene API-sleutels, gedeelde inloggegevens of algemene cloudrechten, puur om de boel op gang te krijgen.

Die aanpak valt echter volledig in duigen zodra agents buiten de pilotfase worden ingezet. Dit komt doordat beveiligingsteams niet kunnen zien tot welke gegevens een agent toegang heeft gehad, welke acties de agent heeft ondernomen, of dat de agent zijn beoogde bereik heeft overschreden, al dan niet opzettelijk. Deze blinde vlekken maken het onmogelijk om agents veilig te beheren, en daarom hebben veel organisaties moeite om verder te komen dan de pilotfase.

Je hebt betoogd dat strikte waarborgen essentieel zijn voor AI-agenten. Hoe ziet een "goed" identiteitsontwerp voor AI-agenten er in de praktijk uit, en waar gaat het bij bedrijven doorgaans mis?

Een goed identiteitsontwerp begint met het principe van minimale bevoegdheden en machtigingen die gekoppeld zijn aan een expliciet doel. Elke AI-agent moet een eigen identiteit hebben, nauwkeurig afgebakende machtigingen en duidelijk gedefinieerde vertrouwensrelaties (expliciete regels voor met welke systemen de agent mag interageren). In principe moet toegang doelgericht, tijdsgebonden en gemakkelijk intrekbaar zijn.

Bedrijven maken hier vaak een fout door bestaande serviceaccounts te hergebruiken of ervan uit te gaan dat interne agents standaard veilig zijn. Die aanname houdt geen stand tegenover bedreigingen in de praktijk. Kwaadwillenden zoeken juist actief naar deze zwakke plekken, en AI-agents vergroten de potentiële impact aanzienlijk wanneer het identiteitsontwerp slordig is.

Curity werkt al lange tijd met standaarden zoals OAuth en OpenID Connect. Hoe belangrijk zijn open identiteitsstandaarden voor het interoperabel en veilig maken van agentische AI ​​in complexe bedrijfsomgevingen?

Open standaarden zijn absoluut cruciaal. Bedrijven beheren al complexe identiteitssystemen die zich uitstrekken over cloudplatforms, SaaS-diensten en interne API's. Agentische AI ​​voegt daar alleen maar meer complexiteit aan toe.

Zonder standaarden wordt elke agent een eigen integratie en een permanente beveiligingsuitzondering. Met standaarden zoals OAuth en OpenID Connect kunnen agents worden geauthenticeerd, geautoriseerd en gecontroleerd, net als elke andere workload. Dit is de enige aanpak die veilige schaalbaarheid in echte bedrijfsomgevingen mogelijk maakt.”

Niet-menselijke identiteiten komen steeds vaker voor, van serviceaccounts tot machine-identiteiten. Wat maakt AI-agenten vanuit een beveiligingsperspectief fundamenteel anders dan eerdere niet-menselijke identiteiten?

Het belangrijkste verschil tussen moderne AI-agenten en oudere niet-menselijke identiteiten (NHI's) is autonomie. Een traditioneel serviceaccount doet precies wat de code voorschrijft en is strikt gebonden aan zijn taak. Een AI-agent interpreteert instructies, past zijn gedrag aan en onderneemt acties die nooit expliciet zijn geprogrammeerd – wat het potentiële gevaar vergroot als er geen passende waarborgen zijn.

Een kleine identiteits- of toegangsfout kan snel uitgroeien tot een ramp, omdat een agent razendsnel en op meerdere systemen tegelijk kan handelen. Vanuit een beveiligingsperspectief vormt dit een groot risico.

Hoe belangrijk zijn audit trails en identiteitsgebaseerde logging voor het beheren van agentische AI, met name in gereguleerde sectoren?

Audit trails mogen geen "leuk extraatje" zijn. Ze moeten vanaf het begin ingebouwd zijn. In gereguleerde omgevingen wordt van organisaties verwacht dat ze eenvoudige maar cruciale vragen beantwoorden: tot welke gegevens heeft deze agent toegang gehad, wanneer is dat gebeurd en wie heeft dat geautoriseerd?

Identiteitsgebaseerde logging is de enige betrouwbare manier om dat niveau van verantwoording te bereiken. Het speelt ook een cruciale rol bij incidentrespons. Zonder duidelijke identiteitscontext is het vrijwel onmogelijk om te weten of een probleem is veroorzaakt door een agent die zich misdraagt, een gecompromitteerde identiteit of simpelweg een foutieve prompt.

Welke reële risico's ziet u ontstaan ​​wanneer organisaties AI-agents met te veel bevoegdheden of met gebrekkige monitoring in productie nemen?

Een veelvoorkomend risico is stilletjes het verzamelen van gegevens. Een agent met te veel bevoegdheden kan gevoelige informatie uit meerdere systemen (klantgegevens, interne documenten, logbestanden) ophalen en die gegevens vervolgens openbaar maken via meldingen, samenvattingen of externe integraties.

Een ander risico is dat agenten met beheerdersrechten razendsnel grote wijzigingen aanbrengen, waardoor in korte tijd veel meer schade kan worden aangericht dan een mens ooit zou kunnen. Dit kan bijvoorbeeld het wijzigen van cloudbronnen, het uitschakelen van beveiligingsmaatregelen of het ongecontroleerd activeren van geautomatiseerde workflows omvatten.

Deze incidenten kunnen kwaadwillig zijn, maar dat hoeft niet per se zo te zijn. Een agent met te veel bevoegdheden of een gebrekkige monitoring kan simpelweg werken met verouderde of onjuiste aannames, waardoor fouten in meerdere systemen worden versterkt voordat iemand het merkt.

Vanuit het perspectief van een aanvaller is een gecompromitteerde agentidentiteit echter uiterst waardevol. Het maakt laterale verplaatsing mogelijk tussen API's en services, vaak met een toegangsniveau dat geen enkele menselijke gebruiker ooit zou krijgen. Zonder sterke identiteitscontroles en monitoring ontdekken organisaties deze kwetsbaarheden vaak pas nadat er al aanzienlijke schade is aangericht.

Welke identiteits- en toegangsbeslissingen moeten bedrijven die overstappen van pilotprojecten naar daadwerkelijke implementaties met agents, vroegtijdig nemen om kostbare herontwerpen later te voorkomen?

Organisaties moeten al in een vroeg stadium beslissen hoe agenten identiteiten krijgen toegewezen, hoe machtigingen worden goedgekeurd en hoe de toegang in de loop der tijd wordt gecontroleerd, en daarbij vooraf de identiteitsgrenzen vaststellen.

Het achteraf invoeren van identiteitsbeheer is vrijwel altijd problematisch. Agenten zijn vaak diep ingebed in workflows met behulp van gedeelde referenties of brede rollen, waardoor het achteraf beperken van de toegang de aannames waarop het systeem is gebaseerd, ondermijnt. Dit leidt uiteindelijk tot het mislukken van workflows en ondermijnt het vertrouwen in de technologie. Het is veel goedkoper, en bovendien veel veiliger, om vanaf het begin de juiste identiteiten, reikwijdtes en toegangsgrenzen te ontwerpen.

Waar vormt identiteitsintegratie het vaakst een knelpunt bij de uitrol van agentische AI, en welke best practices helpen om wrijving te verminderen?

Identiteitsbeheer kan een knelpunt worden, maar alleen wanneer het als een bijzaak wordt beschouwd. Teams richten zich eerst op het ontwikkelen van indrukwekkende agentfunctionaliteiten, om er later achter te komen dat deze geïntegreerd moeten worden met IAM-systemen, API-gateways en logplatformen om echt veilig te zijn.

De beste aanpak is om te beginnen met een helder begrip en een correcte implementatie van identiteitsplatformen en vervolgens agents te ontwerpen die daarin passen. Organisaties zouden bestaande standaarden en infrastructuur moeten hergebruiken in plaats van deze te omzeilen; het nemen van shortcuts zal onvermijdelijk problemen veroorzaken. Wanneer identiteit vanaf het begin wordt geïntegreerd, versnelt dit de implementatie in plaats van deze te vertragen.

Welk advies zou u geven aan leiders op het gebied van beveiliging en engineering die agentische AI ​​willen omarmen, maar zich zorgen maken over governance en risico's, bij het opstellen van hun routekaart?

Neem net genoeg tijd om de basis goed te leggen. AI-agenten moeten als identiteiten worden behandeld, dus je moet dezelfde governance toepassen als voor mensen, en vanaf het begin transparantie eisen. Als een organisatie dat doet, wordt het opschalen van AI-agenten een kwestie van beveiliging, in plaats van een blinde en riskante sprong in het diepe.

Bedankt voor het geweldige interview, lezers die meer willen weten, zouden moeten bezoeken Curity.