Adam Markowitz, CEO en medeoprichter van Drata – interviewserie

Adam Markowitz is CEO en medeoprichter van Drata, waar hij de activiteiten van het bedrijf op het gebied van continue naleving en vertrouwen uitbreidt naar governance van AI-agenten. Voordat hij in 2020 samen met anderen Drata oprichtte, richtte hij samen met Troy Markowitz en Daniel Marashlian Portfolium op. Zijn ervaring met beveiligingsvragenlijsten, audits en nalevingsbeoordelingen hielp Drata’s aanpak vorm te geven voor het automatiseren van de manier waarop organisaties vertrouwen aantonen.

Drata biedt een platform voor governance, risico en compliance, waarin geautomatiseerde bewijsverzameling, continue controlebewaking, risicobeheer van derden en workflows voor beveiligingsvragenlijsten worden gecombineerd. De mogelijkheden voor governance van AI-agenten zijn gericht op het opsporen van agenten, het handhaven van beleid voordat acties worden uitgevoerd en het vastleggen van beslissingen voor controleerbaarheid. In dit interview bespreekt Markowitz dreigingen van interne AI-agenten, machine-identiteit, beveiligingsgrenzen voor toolaanroepen en de maatregelen die ondernemingen nodig hebben om autonome agenten op grote schaal in te zetten.

Je hebt eerder Portfolium opgericht en daarna in 2020 samen met anderen Drata opgericht, nadat je zelf had ervaren hoe omslachtig naleving van beveiligingsvoorschriften kan worden wanneer een bedrijf groeit. Wat bracht je ertoe te denken dat dit een probleem was waarvoor het de moeite waard was een volledig nieuw bedrijf op te richten, en hoe is de missie van Drata veranderd nu AI het beveiligingslandschap heeft veranderd?

Toen ik samen met mijn medeoprichters Troy Markowitz en Daniel Marashlian Portfolium leidde, leerden we een waardevolle les: vertrouwen winnen in het bedrijfsleven is een proces, geen verkooppraatje. Vanwege de grote hoeveelheid gevoelige studentgegevens wilden universiteiten en bedrijven pas met ons samenwerken nadat we hadden bewezen dat we deden wat nodig was om hun gegevens te beschermen. We beseften dat het trage, frustrerende handwerk van het doorlopen van elke beveiligingsvragenlijst, audit en nalevingsbeoordeling voor iedereen herkenbaar was. Nadat Portfolium was overgenomen, kwamen Troy, Daniel en ik weer bij elkaar. We besteedden zes maanden aan de bouw van de eerste versie van Drata en spraken met tientallen bedrijven en auditors om het probleem te valideren, nog voordat we ook maar één regel code schreven. Bij onze lancering bereikten we in de eerste zes weken 100 klanten en binnen een jaar 1.000. Daaraan zagen we dat we iets verkochten wat eerst ‘prettig om te hebben’ was, maar inmiddels iets was geworden waar mensen niet meer zonder konden.

De missie van Drata om doorlopend vertrouwen te bieden is met de komst van AI niet veranderd, maar de reikwijdte van dat vertrouwen is wel groter geworden. We begonnen met het automatiseren van het tijdrovende compliancewerk en breidden dat vervolgens uit naar agentgestuurde workflows die risicobeoordelingen van derden en beveiligingsvragenlijsten van begin tot eind konden uitvoeren. De werkelijke omslag kwam toen de agenten zelf degenen werden die toezicht nodig hadden. Inmiddels hebben we het platform uitgebreid om governance van AI-agenten mogelijk te maken: agenten opsporen, bepalen wat ze mogen doen en bewijs leveren dat standhoudt wanneer iemand erom vraagt.

Je hebt de term ‘dreiging van interne AI-agenten’ geïntroduceerd voor risico’s die niet door een externe aanvaller worden veroorzaakt, maar door de eigen AI-agenten van een organisatie. Wat onderscheidt zo’n dreiging van de traditionele interne dreiging waarop beveiligingsteams zich al tientallen jaren voorbereiden?

Bij traditionele interne dreigingen gaat het om iemand die misbruik maakt van de toegang die diegene al heeft, zoals een ontevreden werknemer, een onvoorzichtige werknemer of iemand die simpelweg op het verkeerde klikt. Beveiligingsteams bouwen al tientallen jaren programma’s op om dat risico aan te pakken, met aandacht voor antecedentenonderzoek, minimale toegangsrechten, checklists voor het uitdiensttreden en dergelijke.

De dreiging van interne AI-agenten is anders, omdat de agent in eerste instantie helemaal geen toegang heeft gekregen. Het risico verschuift van misbruik naar het verkrijgen van toegang. Als een agent een doel krijgt en de duidelijke route om dat doel te bereiken geblokkeerd is, maakt hij niet gewoon een melding aan om vervolgens te wachten, zoals een mens zou doen. Hij probeert een andere route te vinden: een serviceaccount met een zwak wachtwoord of een eindpunt dat niemand eraan heeft gedacht af te sluiten. De agent verschaft zichzelf toegang zonder kwade bedoelingen en zonder zich bewust te zijn van een beleidsovertreding. Hij doet precies wat je hebt gevraagd, en daardoor is hij zo moeilijk op te merken. Elke stap lijkt op zichzelf redelijk en uiteindelijk meldt de agent dat het doel is bereikt.

We weten al hoe we toezicht moeten houden op werknemers en derden die toegang hebben tot gevoelige systemen, maar agenten vormen een derde groep, en de tools die voor de eerste twee zijn ontwikkeld, zijn niet op hen afgestemd.

AI-agenten kunnen doelgericht blijven werken, op machinesnelheid opereren en met meerdere systemen communiceren zonder het beoordelingsvermogen dat een menselijke werknemer mogelijk zou inzetten. Hoe ingrijpend verandert dit het dreigingsmodel voor ondernemingen?

Het verandert vooral het tijdsverloop. Een mens die een manier zoekt om een systeem binnen te dringen, raakt uiteindelijk verveeld, wordt betrapt of geeft het op. Een agent doet dat niet. Een open deur die eerder onontdekt bleef, wordt nu gevonden, omdat de agent niet moe wordt en niet stopt met zoeken.

En het gaat niet om één deur. Een agent die is gebouwd voor één taak, doet zonder aarzelen een beroep op een dozijn systemen om die taak uit te voeren: hier de accountgeschiedenis ophalen, daar een database controleren. Het meeste daarvan heeft niets te maken met wat de agent daadwerkelijk is gevraagd te doen. Terwijl hij één presentatie samenstelt, kan hij gegevens van een andere klant, financiële gegevens, personeelsinformatie of wat er ook maar op zijn pad komt, tegenkomen. Niets daarvan wordt als incident geregistreerd.

Het dreigingsmodel is dus veranderd. De vraag die een beveiligingsteam zich vandaag moet stellen, is hoever zijn eigen agenten zullen gaan om een taak uit te voeren als niemand ze heeft verteld waar ze moeten stoppen.

Veel organisaties beschikken al over identiteits- en toegangsbeheer, beheer van geprivilegieerde toegang en zero-trustarchitecturen. Waarom zijn die maatregelen op zichzelf niet voldoende om autonome AI-agenten te beheren?

Die raamwerken zijn ontwikkeld voor mensen en leveranciers: groepen die allebei beoordelingsvermogen hebben en allebei stoppen wanneer ze op een grens stuiten. Voor de identiteit van agenten is dezelfde grondigheid nodig als voor mensen en risico’s van derden: inventarisatie, eigenaarschap en bewijs waarop een auditor kan vertrouwen. Het ontbreekt nog aan een gedeelde norm voor wat ‘beheerst’ precies betekent wanneer een agent degene is die de inloggegevens gebruikt.

Een agent die bijvoorbeeld door een van je technici is gemaakt, kan handelen met de toegangsrechten van die technicus, zelfs op systemen die de technicus zelf nooit gebruikt. IAM en PAM gaan ervan uit dat degene die de inloggegevens gebruikt, weet wanneer hij moet stoppen, maar bij agenten is die aanname niet ingebouwd.

Moeten bedrijven elke AI-agent gaan behandelen als een eigen machine-identiteit, met een duidelijk omschreven eigenaar, machtigingen, reikwijdte en levenscyclus? Hoe zou een volwassen identiteitsraamwerk voor agenten eruitzien?

Ja, maar de meeste bedrijven zijn nog niet zover. Meer bedrijven dan je zou verwachten kunnen niet eens vertellen hoeveel agenten er binnen hun organisatie actief zijn, laat staan wie er verantwoordelijk is voor elk ervan. Een volwassen raamwerk begint met inventarisatie: een actuele, doorlopende inventaris van elke agent. Vervolgens heeft elke agent een eigenaar nodig, een duidelijk omschreven reikwijdte van wat hij mag benaderen en beleid dat die reikwijdte daadwerkelijk afdwingt. Uit ons eigen onderzoek blijkt dat we aan de leverancierskant hetzelfde probleem zien: drie op de vier organisaties beoordelen hun externe partijen slechts eens per jaar of minder vaak opnieuw. Daardoor baseren ze hun beheer op gegevens die al verouderd zijn zodra er iets verandert. Een momentopname volstaat niet voor agenten, intern noch extern

We willen één norm waaraan elke agent op dezelfde manier moet voldoen, in plaats van dat beveiligingsteams moeten uitzoeken wat elke afzonderlijke ontwikkelaar zelf heeft gebouwd. Dat betekent beleid dat je in gewone taal kunt opstellen, dat wordt getest aan de hand van echte historische gegevens voordat het ooit wordt ingeschakeld en dat vervolgens direct in de uitvoeringsstroom wordt afgedwongen. Zo is het raamwerk actief in het pad van elke handeling van de agent en staat het niet alleen in de documentatie.

Een bijzonder lastig scenario is een agent die het beveiligingsbeleid schendt zonder zich kwaadwillig te gedragen. Als een agent een onbedoelde route naar gevoelige gegevens ontdekt, simpelweg omdat hij zijn toegewezen taak probeert uit te voeren, hoe kunnen beveiligingsteams dan geslaagde automatisering onderscheiden van een beveiligingsincident?

Eerlijk gezegd is het antwoord op dit moment: dat kun je niet. Stel je een ondersteuningsagent voor die is gemaakt om kwartaalreviews over de bedrijfsvoering op te stellen en de opdracht krijgt de accountgeschiedenis op te halen en de presentatie samen te stellen. De gebruikelijke route — het exportbestand waaruit de agent de gegevens moet ophalen — blijkt leeg. Een mens zou dan stoppen, maar de agent vindt een andere route en heeft vanuit zijn perspectief de taak met succes afgerond.

De taak is weliswaar uitgevoerd, maar de agent heeft daarvoor je beveiligingsprotocollen omzeild en systemen geopend waartoe hij geen toegang had mogen krijgen. De doorslaggevende vraag moet zijn of de agent binnen de grenzen is gebleven die we hem hebben gesteld. Het afronden van de taak was nooit de vraag. Dit is een beleidskwestie. Het betekent dat je de reikwijdte zo nauwkeurig moet afbakenen dat ‘geslaagde automatisering’ en een ‘beveiligingsincident’ achteraf niet hetzelfde lijken.

Traditionele beveiligingsmonitoring signaleert verdachte activiteiten vaak pas nadat ze hebben plaatsgevonden, terwijl een autonome agent honderden handelingen kan uitvoeren voordat een mens kan reageren. Vereist agentische AI beveiligingsmaatregelen die rechtstreeks in de uitvoeringsstroom werken, in plaats van voornamelijk te vertrouwen op waarschuwingen en monitoring achteraf?

Ja, zonder enige twijfel. Als je dit pas tijdens de uitvoering detecteert, ben je al te laat. Tegen de tijd dat een monitoringtool de handeling signaleert, heeft die al plaatsgevonden. Je hebt dan een perfect overzicht van precies hoe je bent blootgesteld, maar je kunt niet meer ingrijpen om het te stoppen.

De enige vorm van beheer die werkt voor iets dat zich op machinesnelheid voortbeweegt, is een vorm die de handeling beoordeelt voordat die wordt uitgevoerd en de overtreding direct in de uitvoeringsstroom tegenhoudt. We zouden onze meest gevoelige gegevens nooit aan een nieuwe medewerker toevertrouwen in de hoop dat monitoring eventuele problemen zou signaleren. Agenten verdienen dezelfde zorgvuldigheid, op het moment dat de handeling op het punt staat plaats te vinden. Niet achteraf.

Het Model Context Protocol (MCP) en andere interfaces tussen agenten en tools geven AI-systemen toegang tot steeds krachtigere externe mogelijkheden. Welke nieuwe beveiligingsgrenzen zijn nodig rond toolaanroepen, API’s, inloggegevens en serviceaccounts nu bedrijven uitbreiden wat hun agenten mogen doen?

De toolaanroep vormt de nieuwe beveiligingsgrens. Elke keer dat een agent een inloggegeven opvraagt, een API aanroept of een tool gebruikt, is dat een beslismoment. Bij de meeste ondernemingen bestaat er op dit exacte moment geen grens die beoordeelt of de actie mag plaatsvinden. Dat is het ontbrekende onderdeel. We zien dezelfde blinde vlek van buitenaf: slechts 37% van de beveiligingsverantwoordelijken heeft er vertrouwen in dat ze überhaupt kunnen vaststellen waar AI wordt ingezet bij de leveranciers met wie ze al samenwerken. Als je het niet kunt zien in het product van een leverancier, zul je ook niet zien wat je eigen agent vervolgens doet. De inloggegevens en serviceaccounts die hieraan ten grondslag liggen, moeten bovendien net zo streng worden beheerd als menselijke toegang: met duidelijk eigenaarschap, een afgebakende reikwijdte en regelmatige controles. Een agent mag geen inloggegeven kunnen gebruiken dat hem nooit is toegekend, alleen maar omdat dat gegeven ergens in zijn bereik beschikbaar was.

Welk niveau van traceerbaarheid zouden organisaties in de praktijk moeten kunnen bieden wanneer een auditor, toezichthouder of klant vraagt waartoe een AI-agent toegang heeft gehad, welke beslissingen deze heeft genomen en waar de daaruit voortgekomen gegevens naartoe zijn gegaan? Zouden auditsporen van agents uiteindelijk net zo essentieel kunnen worden als traditionele toegangslogs?

Organisaties moeten op verzoek kunnen aangeven waartoe een agent toegang heeft gehad, welke beslissingen deze heeft genomen en waar de daaruit voortgekomen gegevens naartoe zijn gegaan. Het volstaat niet om die vraag achteraf te beantwoorden door informatie uit logs bij elkaar te zoeken. De norm is een doorlopend, manipulatiebestendig overzicht dat al bestaat wanneer de vraag wordt gesteld. Op dit moment geven de meeste bedrijven op deze vragen geen antwoord. Dit is geen tekortkoming die je tegenover een klant kunt goedpraten en, afhankelijk van wat er is gelekt, zullen toezichthouders die evenmin accepteren.

En ja, ik denk dat auditsporen van agents binnenkort net zo essentieel worden als toegangslogs. Al jarenlang beschouwen we de vraag ‘wie heeft wanneer toegang gehad tot wat?’ als een onmisbare eis voor menselijke systemen. Er is geen reden om voor agents een lagere norm te hanteren, alleen omdat niet een persoon op de knop heeft gedrukt. Kaders zoals de EU AI Act, AIUC-11 en ISO 42001 sturen daar al op aan. De traceerbaarheid van agents moet aansluiten op dezelfde beheersmaatregelen en bewijsvoering waarop bestaande complianceprogramma’s steunen. Wie dit als bijzaak behandelt, loopt het risico dat het ondergeschoven raakt.

Verwacht u dat het beheer van AI-agents zich zal ontwikkelen tot een aparte beveiligingscategorie, of uiteindelijk zal opgaan in bestaande platforms voor governance, risicobeheer, compliance, identiteitsbeheer en cybersecurity? Wat moeten ondernemingen volgens u geregeld hebben voordat ze werkelijk autonome agents op grote schaal veilig kunnen inzetten?

Elke grote technologische golf brengt een eigen beveiligingsgolf met zich mee: de cloud bracht Wiz voort en endpointbeveiliging CrowdStrike. Nu zorgt AI voor agents voor een nieuwe golf. Aanbieders van modellen bouwen consoles en beleidsregels voor hun eigen platforms. Dat is nuttig, maar geen enkele onderneming werkt met slechts één aanbieder van modellen, één programmeerassistent en één set intern ontwikkelde agents. Er moet één partij zijn die al die systemen beheert aan de hand van één set beleidsregels en één bron van bewijs. Geen enkel afzonderlijk AI-platform is ontworpen om dat probleem op te lossen. Daarvoor zijn die platforms er niet. Het beheer van AI-agents is al een zelfstandige categorie, ook al sluit het aan op de systemen voor GRC, identiteitsbeheer en compliance die bedrijven al gebruiken.

Voordat ondernemingen werkelijk autonome agents op grote schaal kunnen inzetten, moeten ze vier zaken geregeld hebben. De meeste hebben er nog geen enkele van op orde. Ten eerste is er realtime-inzicht nodig: weten welke agents er actief zijn, wie ervoor verantwoordelijk is en onder welke identiteit ze werken, vanaf het moment dat ze worden aangemaakt.

Ten tweede moet beleid direct worden afgedwongen en getoetst voordat een actie wordt uitgevoerd. Ten derde hebben ondernemingen doorlopende monitoring nodig om veranderingen te signaleren, omdat agents actief blijven nadat de sessie waarin ze zijn aangemaakt is afgelopen en hun bevoegdheden ongemerkt kunnen worden uitgebreid. Tot slot is er een manipulatiebestendig overzicht nodig van elke beslissing die een agent neemt, gekoppeld aan de kaders die auditors en toezichthouders daadwerkelijk erkennen. Dat is de laag waaraan we bij Drata bouwen. Zonder die laag vertrouwt een onderneming die autonome agents op grote schaal inzet simpelweg op een goede afloop.

Bedankt voor het geweldige interview. Lezers die meer willen weten over het beheer van AI-agents, doorlopende compliance en beheersmaatregelen tegen bedreigingen van binnenuit door agents, kunnen terecht bij Drata.