Adam Markowitz, vd och medgrundare av Drata – intervjuserie

Adam Markowitz är vd och medgrundare av Drata, där han utvidgar företagets arbete med kontinuerlig regelefterlevnad och tillit till att även omfatta styrning av AI-agenter. Innan han var med och grundade Drata 2020 grundade han Portfolium tillsammans med Troy Markowitz och Daniel Marashlian. Hans erfarenhet av att hantera säkerhetsfrågeformulär, revisioner och granskningar av regelefterlevnad bidrog till att forma Dratas sätt att automatisera hur organisationer visar att de inger förtroende.

Drata erbjuder en plattform för styrning, risk och regelefterlevnad som kombinerar automatiserad insamling av underlag, kontinuerlig övervakning av kontroller, hantering av tredjepartsrisker och arbetsflöden för säkerhetsfrågeformulär. Plattformens funktioner för styrning av AI-agenter fokuserar på att upptäcka agenter, tillämpa policyer innan åtgärder utförs och dokumentera beslut så att de kan granskas. I den här intervjun diskuterar Markowitz hot från agenter på insidan, maskinidentitet, säkerhetsgränser för verktygsanrop och vilka kontroller företag behöver för att kunna införa autonoma agenter i stor skala.

Du grundade tidigare Portfolium innan du var med och grundade Drata 2020, efter att på nära håll ha upplevt hur betungande det kunde bli att hantera säkerhetskrav när ett företag växte. Vad fick dig att tro att detta var ett problem värt att bygga ett helt nytt företag kring, och hur har Dratas uppdrag utvecklats i takt med att AI har förändrat säkerhetslandskapet?

När jag ledde Portfolium tillsammans med mina medgrundare Troy Markowitz och Daniel Marashlian lärde vi oss en viktig sak: Att vinna förtroende i affärslivet är en process, inte en säljpitch. Eftersom vi hanterade stora mängder känslig studentinformation ville universitet och företag inte samarbeta med oss förrän vi hade visat att vi gjorde det vi skulle för att skydda deras data. Vi insåg att det var en gemensam erfarenhet att manuellt ta sig igenom varje säkerhetsfrågeformulär, revision och granskning av regelefterlevnad – en långsam och smärtsam process. Efter att Portfolium hade förvärvats återförenades Troy, Daniel och jag, och vi ägnade sex månader åt att bygga den första versionen av Drata. Vi pratade med dussintals företag och revisorer för att bekräfta att problemet fanns innan vi ens började skriva kod. När vi lanserade fick vi 100 kunder under de första sex veckorna och 1 000 inom ett år – vilket visade oss att vi hade gått från att sälja något som var ”bra att ha” till något som människor inte kunde driva sin verksamhet utan.

Med AI har Dratas uppdrag att skapa kontinuerlig tillit inte förändrats, men omfattningen av den tilliten har vuxit. Vi började med att automatisera det mödosamma arbetet med regelefterlevnad och gick sedan vidare till agentbaserade arbetsflöden som kunde genomföra riskbedömningar av tredje part och hantera säkerhetsfrågeformulär från början till slut. Den verkliga förändringen kom dock när agenterna själva blev föremål för styrning. Nu har vi utökat plattformen så att den även stöder styrning av AI-agenter: upptäck agenterna, styr vad de får göra och ta fram underlag som håller för granskning när någon efterfrågar det.

Du har lanserat begreppet ”insiderhot från AI-agenter” för att beskriva risker som inte orsakas av en extern angripare, utan av en organisations egna AI-agenter. Vad skiljer ett insiderhot från en agent från det traditionella insiderhot som säkerhetsteam har förberett sig på i årtionden?

Traditionella insiderhot handlar om att en person missbrukar behörigheter som hen redan har, till exempel en missnöjd eller vårdslös medarbetare eller någon som helt enkelt klickar på fel sak. Säkerhetsteam har ägnat årtionden åt att bygga program för att hantera den risken, med fokus på bakgrundskontroller, minsta möjliga behörighet, checklistor för avslut av anställningar och liknande.

Insiderhotet från en agent är annorlunda eftersom agenten aldrig fick behörighet från början. Risken handlar inte längre om missbruk, utan om att skaffa sig åtkomst. Om en agent får ett mål men den uppenbara vägen till att nå det är blockerad, skapar den inte bara ett ärende och väntar, som en människa skulle göra. Den försöker hitta en annan väg: ett tjänstekonto med ett svagt lösenord eller en slutpunkt som ingen kom ihåg att stänga. Den tar sig in utan att vara illvillig eller medveten om att den bryter mot någon policy. Den gör precis det du bad den om, och det är det som gör den så svår att upptäcka. Varje steg verkar rimligt för sig, och till slut rapporterar agenten att den har lyckats.

Vi vet redan hur vi ska styra anställda och tredje parter som har åtkomst till känsliga system, men agenter utgör en tredje grupp, och verktygen som byggts för de två första räcker inte till för dem.

AI-agenter kan envist sträva mot sina mål, arbeta i maskinhastighet och interagera med flera system utan det omdöme som en mänsklig medarbetare kanske skulle använda. Hur förändrar detta i grunden företagens hotbild?

Framför allt förändrar det tidsförloppet. En människa som letar efter en väg in i ett system tröttnar till slut, blir upptäckt eller ger upp. Det gör inte en agent. En öppen dörr som tidigare inte hade upptäckts hittas nu, eftersom agenten inte blir trött och inte slutar leta.

Och det handlar inte bara om en dörr. En agent som byggts för att utföra en uppgift går gärna igenom ett dussin system på vägen mot att slutföra den – hämtar kontohistorik här, kontrollerar en databas där – och det mesta har ingenting att göra med vad den faktiskt ombads göra. På vägen mot att skapa en enda presentation kan den passera en annan kunds data, ekonomiska uppgifter, medarbetarinformation och allt annat som råkar finnas i dess väg. Inget av detta registreras som en incident.

Hotbilden har alltså förändrats. Frågan som säkerhetsteam bör ställa sig i dag är hur långt deras egna agenter kommer att gå för att slutföra en uppgift om ingen har talat om för dem var de ska stanna.

Många organisationer har redan identitets- och åtkomsthantering, privilegierad åtkomsthantering och nolltillitsarkitekturer på plats. Varför räcker inte de kontrollerna i sig för att styra autonoma AI-agenter?

De ramverken utformades för människor och leverantörer – två grupper som båda har omdöme och slutar när de stöter på en gräns. Agenters identitet behöver hanteras med samma noggrannhet som människors identitet och risker med tredje part: genom inventering, ansvarsfördelning och bevis som en revisor kan ställa sig bakom. Problemet är att det ännu inte finns någon gemensam måttstock för vad ”styrd” faktiskt innebär när det är en agent som har autentiseringsuppgiften.

En agent som en av era ingenjörer har skapat kan till exempel agera med den ingenjörens behörigheter – även i system som ingenjören själv aldrig använder. IAM och PAM utgår från att den som har autentiseringsuppgiften vet när den ska sluta, men agenter har inte den förutsättningen inbyggd.

Bör företag börja behandla varje AI-agent som en egen maskinidentitet med en tydligt utsedd ägare, behörigheter, avgränsning och livscykel? Hur skulle ett moget identitetsramverk för agenter se ut?

Ja, men de flesta företag har inte kommit dit än. Fler än man kan tro kan inte ens säga hur många agenter som körs inom organisationen, än mindre vem som ansvarar för var och en. Ett moget ramverk börjar med inventering – en faktisk, kontinuerligt uppdaterad förteckning över alla agenter. Därefter behöver varje agent en ansvarig ägare, en tydlig avgränsning av vad den får komma åt och en policy som faktiskt upprätthåller den avgränsningen. I vår egen forskning ser vi samma problem hos leverantörer: tre av fyra organisationer omprövar sina tredjepartsrelationer högst en gång om året, vilket innebär att de styr utifrån data som redan är inaktuell när något väl förändras. Punktvisa kontroller räcker inte för agenter, vare sig interna eller externa.

Vi vill ha en och samma standard som gäller för alla agenter, i stället för att säkerhetsteamen ska behöva jaga reda på vad varje enskild utvecklare har byggt på egen hand. Det innebär att kunna formulera policyer på klarspråk, testa dem mot verklig historisk trafik innan de aktiveras och sedan tillämpa dem direkt i flödet, så att ramverket är med i varje åtgärd agenten utför och inte bara finns dokumenterat.

Ett särskilt svårt scenario är när en agent bryter mot säkerhetspolicyn utan att agera illvilligt. Om en agent hittar en oavsiktlig väg till känsliga uppgifter bara för att den försöker slutföra sin tilldelade uppgift, hur kan säkerhetsteam skilja mellan lyckad automatisering och en säkerhetsincident?

Just nu är det ärliga svaret att det kan ni inte. Föreställ er en supportagent som har utformats för att ta fram kvartalsvisa affärsgenomgångar och fått i uppgift att hämta kontohistorik och skapa presentationen. Den avsedda vägen – exporten som den ska hämta uppgifterna från – är tom. En människa skulle stanna där, men agenten hittar en annan väg och uppfattar själv resultatet som lyckat.

Uppgiften blev visserligen utförd, men agenten tog sig dit genom att kringgå era säkerhetsprotokoll och gå in i system som den inte var avsedd att öppna. Den avgörande frågan måste vara om agenten höll sig inom de ramar vi hade satt upp. Frågan har aldrig varit om uppgiften blev slutförd. Det är en policyfråga. Det handlar om att definiera ramarna tillräckligt tydligt för att ”lyckad automatisering” och ”säkerhetsincident” inte ska se likadana ut i efterhand.

Traditionell säkerhetsövervakning upptäcker ofta misstänkt aktivitet först efter att den har ägt rum, men en autonom agent kan hinna utföra hundratals åtgärder innan en människa kan ingripa. Kräver agentisk AI säkerhetskontroller som verkar direkt i exekveringsflödet, i stället för att i första hand förlita sig på aviseringar och efterhandsövervakning?

Ja, utan tvekan. Om ni upptäcker det först när det körs är det redan för sent. När ett övervakningsverktyg flaggar åtgärden har den redan utförts. Ni får en fullständig redogörelse för exakt hur ni blev exponerade, men det går inte längre att stoppa det.

Den enda form av styrning som fungerar för något som rör sig i maskinhastighet är att utvärdera åtgärden innan den genomförs och stoppa överträdelser direkt i flödet. Vi skulle aldrig lämna över våra känsligaste uppgifter till en nyanställd och bara hoppas att övervakningen upptäcker om något går fel. Agenter förtjänar samma noggrannhet, precis när åtgärden är på väg att utföras. Inte efteråt.

Model Context Protocol (MCP) och andra gränssnitt mellan agenter och verktyg ger AI-system tillgång till allt kraftfullare externa funktioner. Vilka nya säkerhetsgränser behöver införas kring verktygsanrop, API:er, autentiseringsuppgifter och tjänstekonton när företag utökar vad deras agenter får göra?

Verktygsanropet är den nya säkerhetsgränsen. Varje gång en agent hämtar en inloggningsuppgift, anropar ett API eller använder ett verktyg uppstår en beslutspunkt. I dag saknar de flesta stora företag en gräns just där som bedömer om åtgärden ska utföras. Det är den pusselbiten som har saknats. Vi ser samma blinda fläck utifrån — bara 37 % av säkerhetscheferna är säkra på att de ens kan identifiera var AI används hos de leverantörer de redan samarbetar med. Om du inte kan se det i en leverantörs produkt kommer du inte heller att kunna se vad din egen agent gör härnäst. Inloggningsuppgifterna och tjänstekontona bakom allt detta måste också hanteras med samma noggrannhet som vi tillämpar på mänsklig åtkomst: tydligt ägarskap, avgränsad behörighet och regelbunden granskning. En agent ska inte kunna använda en inloggningsuppgift som den aldrig har tilldelats bara för att uppgiften finns någonstans i dess åtkomstkedja.

När en revisor, tillsynsmyndighet eller kund frågar vad en AI-agent har fått åtkomst till, vilka beslut den har fattat och vart de resulterande uppgifterna har skickats, vilken grad av spårbarhet bör organisationer realistiskt sett kunna erbjuda? Kan granskningsspår för agenter så småningom bli lika grundläggande som traditionella åtkomstloggar?

Organisationer bör på begäran kunna redogöra för vad en agent har fått åtkomst till, vilka beslut den har fattat och vart de resulterande uppgifterna har skickats. Det räcker inte att i efterhand försöka pussla ihop svaret utifrån loggar. Kravet bör vara en kontinuerlig, manipulationssäker dokumentation som redan finns när frågan ställs. Just nu möts sådana frågor av tystnad från de flesta företag. Det här är inget man kan förklara bort för en kund, och beroende på vad som har läckt är det inte heller något tillsynsmyndigheter kommer att acceptera.

Och ja, jag tror att granskningsspår för agenter snart blir lika grundläggande som åtkomstloggar. I åratal har vi betraktat ”vem fick åtkomst till vad och när” som ett oeftergivligt krav för mänskliga system. Det finns ingen anledning att ställa lägre krav på agenter bara för att det inte var en människa som klickade. Ramverk som EU:s AI-förordning, AIUC-11 och ISO 42001 driver redan utvecklingen i den riktningen. Spårbarheten för agenter måste motsvara samma kontroller och bevislogik som redan ligger till grund för efterlevnadsprogram. Om man behandlar den som en eftertanke är det så den hamnar i skymundan.

Framöver, tror du att styrning av AI-agenter kommer att bli en egen säkerhetskategori, eller kommer den till slut att införlivas i befintliga plattformar för styrning, risk, regelefterlevnad, identitet och cybersäkerhet? Vad tror du att företag behöver ha på plats innan de säkert kan införa helt autonoma agenter i stor skala?

Varje stor teknikvåg ger upphov till en egen säkerhetsvåg – molnet gav upphov till Wiz och slutpunkter till CrowdStrike – och nu är det AI-agenternas tur. Modellleverantörer bygger konsoler och policyer för sina egna plattformar, vilket är användbart, men inget företag arbetar med bara en modellleverantör, en kodningsassistent och en uppsättning egenutvecklade agenter. Någon måste styra allt detta med en gemensam uppsättning policyer och en enda källa till dokumentation, och det är inget som någon enskild AI-plattform är byggd för att lösa. Det är inte därför de finns. Styrning av AI-agenter är redan en egen kategori, samtidigt som den kopplas till de system för styrning, risk och regelefterlevnad (GRC), identitet och regelefterlevnad som företagen redan använder.

Innan företag kan införa helt autonoma agenter i stor skala behöver de ha fyra saker på plats, och de flesta saknar fortfarande allihop. För det första krävs upptäckt i realtid – att veta vilka agenter som körs, vem som äger dem och vilken identitet de använder, så snart de skapas.

Därefter krävs policyer som tillämpas direkt i körflödet och utvärderas innan en åtgärd utförs. För det tredje behöver företag kontinuerlig övervakning av avvikelser, eftersom agenter finns kvar efter att sessionen där de skapades har avslutats och deras behörighetsomfång i det tysta kan utökas. Slutligen behövs en manipulationssäker dokumentation av varje beslut en agent fattar, kopplad till de ramverk som revisorer och tillsynsmyndigheter faktiskt känner igen. Det är det lager vi bygger på Drata. Utan det förlitar sig ett företag som inför autonoma agenter i stor skala helt enkelt på att allt ska gå bra.

Tack för en givande intervju. Läsare som vill utforska styrning av AI-agenter, kontinuerlig regelefterlevnad och kontroller mot insiderhot från agenter bör besöka Drata.