Jacob Ideskog, CTO van Curity – Interviewreeks

Jacob Ideskog is een identiteitsspecialist en CTO bij Curity. Het grootste deel van zijn tijd besteedt hij aan het werken met beveiligingsoplossingen in de API- en webruimte. Hij heeft gewerkt aan het ontwerpen en implementeren van OAuth- en OpenID Connect-oplossingen voor grote ondernemingsimplementaties en kleine start-ups.

Curity is een modern identiteits- en toegangsbeheerplatform (IAM) dat is gebouwd rond de Curity Identity Server, een op standaarden gebaseerde oplossing die is ontworpen om authenticatie en autorisatie voor toepassingen, API’s en digitale diensten op grote schaal te beveiligen. Het ondersteunt protocollen zoals OAuth 2.0 en OpenID Connect om inlogstromen te centraliseren, fijngewikkelde toegangsbeleiden af te dwingen en beveiligde tokens uit te geven voor zowel menselijke gebruikers als machineclients, waaronder API’s en diensten. Het platform is ontworpen voor flexibiliteit en schaalbaarheid, waardoor organisaties het kunnen implementeren in de cloud, hybride of on-premisesomgevingen, integreren met bestaande systemen en beveiligde, naadloze gebruikerservaringen bieden zonder afhankelijk te zijn van aangepaste beveiligingsinfrastructuur.

U hebt een groot deel van uw carrière besteed aan het bouwen van identiteits- en API-beveiligingssystemen, van het mede-oprichten van Curity tot het leiden ervan als CTO tijdens de opkomst van de cloud en nu AI. Hoe heeft die reis uw visie gevormd dat AI-agents moeten worden behandeld als eerste klas digitale identiteiten in plaats van alleen maar een stuk software?

Overal waar ik in de technologie heb gewerkt, komt één probleem steeds weer naar voren. Of het nu gaat om cloudcomputing of nu AI, als software namens een persoon of een ander systeem handelt, heb je een identiteitsprobleem.

Met de massale adoptie van agente AI wordt dit probleem verergerd. Hun gedrag is niet langer strikt vastgelegd en ze opereren met een niveau van autonomie dat ondernemingen nog nooit eerder hebben gezien. AI-agents nemen beslissingen, roepen API’s op en ketenen acties over systemen zonder directe menselijke toezicht. Dit gedrag creëert identiteits- en toegangsuitdagingen die wezenlijk verschillen van traditionele software.

Het behandelen van AI-agents als eerste klas digitale identiteiten is de enige manier om dit goed aan te pakken. Als organisaties ze behandelen als alleen maar een proces of een serviceaccount, verliezen ze snel zicht en controle – en dat is een recept voor een beveiligingscrisis.

Veel ondernemingen zijn enthousiast over agente AI, maar blijven vastzitten in experimenten. Wat zijn, volgens uw observaties van echte implementaties, de meest voorkomende identiteits- en governance-gaten die organisaties ervan weerhouden om agents veilig te schalen?

Het meeste experimenteerwerk gebeurt in geïsoleerde zandbakken die negeren wat er gebeurt op grote schaal. Tijdens vroege proefprojecten geven teams agents vaak brede API-sleutels, gedeelde referenties of blanco cloudmachtigingen om dingen op gang te krijgen.

Die aanpak houdt op te werken zodra agents buiten proefprojecten worden geïmplementeerd. Dit komt doordat beveiligingsteams niet kunnen zien welke gegevens een agent heeft toegankelijk gemaakt, zijn acties of of het zijn beoogde bereik heeft overschreden; of per ongeluk of kwaadwillig. Deze blinde vlekken maken het onmogelijk om agents veilig te beheren, en dat is waarom veel organisaties moeite hebben om verder te gaan dan proefprojecten.

U hebt betoogd dat strikte richtlijnen essentieel zijn voor agente AI. Wat ziet “goede” identiteitsontwerp eruit voor AI-agents in de praktijk, en waar maken bedrijven dit meestal verkeerd?

Goed identiteitsontwerp begint met het principe van het minste privilege en machtigingen gekoppeld aan expliciete bedoeling. Elke AI-agent moet zijn eigen identiteit hebben, smal toegestane machtigingen en duidelijk gedefinieerde vertrouwensrelaties (expliciete regels voor welke systemen het mag interactie aangaan). Fundamenteel moet toegang doelgebonden zijn, tijdelijk beperkt en gemakkelijk intrekbaar.

Waar bedrijven dit verkeerd doen, is door bestaande serviceaccounts te hergebruiken of te veronderstellen dat interne agents per definitie veilig zijn. Die veronderstelling houdt geen stand tegenover echte bedreigingen. Kwaadwillige actoren zoeken actief naar deze zwakke plekken, en AI-agents vergroten het potentieel voor schade aanzienlijk wanneer identiteitsontwerp slordig is.

Curity heeft lang gewerkt met standaarden zoals OAuth en OpenID Connect. Hoe kritiek zijn open identiteitsstandaarden voor het maken van agente AI interoperabel en beveiligd over complexe ondernemingsomgevingen?

Open standaarden zijn absoluut kritiek. Ondernemingen draaien al complexe identiteitsweefsels die cloudplatforms, SaaS-diensten en interne API’s omvatten. Agente AI voegt alleen maar meer complexiteit 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 geauditeerd net als elke andere workload. Dit is de enige aanpak die veilige schaalbaarheid over echte ondernemingsomgevingen kan faciliteren.

Niet-menselijke identiteiten worden steeds vaker gebruikt, van serviceaccounts tot machine-identiteiten. Wat maakt AI-agents wezenlijk anders dan eerdere niet-menselijke identiteiten vanuit een beveiligingsperspectief?

Het belangrijkste verschil tussen moderne AI-agents en oudere niet-menselijke identiteiten (NHI’s) is autonomie. Een traditionele serviceaccount doet precies wat zijn code hem vertelt te doen, strikt gebonden aan zijn taak. Een AI-agent interpreteert instructies, past zijn gedrag aan en neemt acties die nooit expliciet zijn vastgelegd – allemaal verhogend het potentieel gevaar als er geen passende richtlijnen zijn.

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

Hoe belangrijk zijn audittrails en identiteitsgebaseerde logging voor het beheren van agente AI, vooral in gereguleerde industrieën?

Audittrails moeten geen “leuke extra” zijn. Ze moeten vanaf het begin worden ingebouwd. In gereguleerde omgevingen worden organisaties verwacht om eenvoudige maar kritieke vragen te beantwoorden: wat heeft deze agent toegankelijk gemaakt, wanneer gebeurde het en wie heeft het geautoriseerd?

Identiteitsgebaseerde logging is de enige betrouwbare manier om dat niveau van verantwoordelijkheid te krijgen. Het speelt ook een sleutelrol in incidentrespons. Zonder duidelijke identiteitscontext is het bijna onmogelijk om te weten of een probleem afkomstig was van een misdragende agent, een gecompromitteerde identiteit of gewoon een slechte prompt.

Welke reële risico’s ziet u ontstaan wanneer organisaties over-gepriviligede of slecht gemonitorde AI-agents in productie implementeren?

Een veelvoorkomend risico is stille gegevensaggregatie. Een over-gepriviligede agent kan gevoelige informatie uit meerdere systemen (klantrecords, interne documenten, logs) trekken en vervolgens die gegevens blootstellen via prompts, samenvattingen of externe integraties.

Een ander risico is agents met administratieve toegang die grote veranderingen aanbrengen met machinesnelheid, waardoor veel meer schade kan worden aangericht dan een mens ooit in korte tijd kan. Dit kan cloudbronnen modificeren, beveiligingscontroles uitschakelen of geautomatiseerde workflows zonder toezicht activeren.

Deze incidenten kunnen kwaadwillig zijn, maar dat hoeven ze niet te zijn. Een over-gepriviligede of slecht gemonitorde agent kan eenvoudigweg op basis van verouderde of onjuiste aannamen opereren, waardoor fouten over meerdere systemen worden vermenigvuldigd voordat iemand het opmerkt.

Maar vanuit het perspectief van een aanvaller is een gecompromitteerde agentidentiteit extremadamente waardevol. Het maakt laterale beweging over API’s en diensten mogelijk, vaak met een niveau van toegang dat geen enkele menselijke gebruiker ooit zou krijgen. Zonder sterke identiteitscontroles en monitoring ontdekken organisaties deze mislukkingen vaak pas nadat er echte schade is aangericht.

Welke identiteits- en toegangsbeslissingen moeten bedrijven vroeg nemen om dure herontwerpen later te voorkomen als ze overstappen van proefprojecten naar echte agente-implementaties?

Organisaties moeten vroeg beslissen hoe agents identiteiten krijgen, hoe machtigingen worden goedgekeurd en hoe toegang in de loop van de tijd wordt beoordeeld, door identiteitsgrenzen van tevoren te definiëren.

Het invoeren van identiteitscontroles achteraf is bijna altijd problematisch. Agents zijn vaak diep ingebed in workflows met gedeelde referenties of brede rollen, dus het aanscherpen van toegang achteraf breekt aannamen waarop het systeem vertrouwt. Dit zorgt er uiteindelijk voor dat workflows falen en het vertrouwen in de technologie ondermijnt. Het is veel goedkoper, en niet te vergeten veel veiliger, om vanaf het begin een goed identiteitsontwerp, reikwijdte en toegangsgrenzen te definiëren.

Waar wordt identiteitsintegratie meestal een bottleneck bij het implementeren van agente AI, en welke beste praktijken helpen de wrijving te verminderen?

Identiteitsbeheer kan een bottleneck worden, maar alleen als het als een bijzaak wordt behandeld. Teams focussen eerst op het bouwen van indrukwekkende agentcapaciteiten en realiseren zich later dat ze moeten worden geïntegreerd met IAM-systemen, API-gateways en logplatforms om echt veilig te zijn.

De beste aanpak is om te beginnen met een duidelijk begrip en een juiste implementatie van identiteitsplatforms en vervolgens agents te ontwerpen die daarbinnen passen. Organisaties moeten bestaande standaarden en infrastructuur hergebruiken in plaats van deze te omzeilen; het afsnijden van deze hoek zal onvermijdelijk problemen veroorzaken verderop in de lijn. Wanneer identiteit vanaf het begin is ingebouwd, versnelt het de implementatie in plaats van deze te vertragen.

Wat is uw advies aan beveiligings- en ingenieursleiders die agente AI willen omarmen, maar bezorgd zijn over governance en risico’s, terwijl ze hun roadmap plannen?

Vertraag uw tempo net genoeg om de fundamenten goed te krijgen. AI-agents moeten worden behandeld als identiteiten en u moet dezelfde governance toepassen die u van mensen verwacht, en vanaf het begin zichtbaarheid eisen. Als een organisatie dat doet, wordt het schalen van agente AI een oefening in beveiliging, in plaats van een blinde en riskante sprong van vertrouwen.

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