Adam Markowitz, administrerende direktør og medstifter af Drata – interviewserie

Adam Markowitz er administrerende direktør og medstifter af Drata, hvor han udvider virksomhedens arbejde med løbende compliance og tillid til også at omfatte styring af AI-agenter. Før han var med til at stifte Drata i 2020, grundlagde han Portfolium sammen med Troy Markowitz og Daniel Marashlian. Hans erfaring med sikkerhedsspørgeskemaer, revisioner og compliancegennemgange var med til at forme Dratas tilgang til at automatisere den måde, organisationer dokumenterer deres troværdighed på.

Drata tilbyder en platform til governance, risikostyring og compliance, der kombinerer automatiseret indsamling af dokumentation, løbende overvågning af kontroller, tredjepartsrisikostyring og arbejdsgange for sikkerhedsspørgeskemaer. Platformens funktioner til styring af AI-agenter fokuserer på at finde agenter, håndhæve politikker, før handlinger udføres, og registrere beslutninger, så de kan revideres. I dette interview taler Markowitz om insidertrusler fra agenter, maskinidentitet, sikkerhedsgrænser for værktøjskald og de kontroller, virksomheder har brug for for at kunne udrulle autonome agenter i stor skala.

Du grundlagde tidligere Portfolium, før du var med til at stifte Drata i 2020, efter på egen krop at have oplevet, hvor besværlig overholdelse af sikkerhedskrav kunne blive, efterhånden som en virksomhed voksede. Hvad fik dig til at tro, at dette var et problem, det var værd at bygge en helt ny virksomhed op omkring, og hvordan har Dratas mission udviklet sig, i takt med at AI har ændret sikkerhedslandskabet?

Mens jeg ledede Portfolium sammen med mine medstiftere Troy Markowitz og Daniel Marashlian, lærte vi en vigtig lektie: Det tager tid at opbygge tillid i erhvervslivet; det klares ikke med en salgstale. På grund af den store mængde følsomme oplysninger om studerende ville universiteter og virksomheder ikke indgå partnerskaber med os, før vi havde bevist, at vi gjorde det, vi burde, for at beskytte deres data. Vi indså, at den langsomme og opslidende opgave med manuelt at komme igennem hvert eneste sikkerhedsspørgeskema, hver revision og hver compliancegennemgang var noget, mange kendte til. Efter Portfolium blev opkøbt, fandt Troy, Daniel og jeg sammen igen, og vi brugte seks måneder på at bygge den første version af Drata. Vi talte med snesevis af virksomheder og revisorer for at bekræfte, at problemet fandtes, før vi overhovedet begyndte at skrive kode. Da vi lancerede, nåede vi op på 100 kunder i løbet af de første seks uger og 1.000 inden for det første år – hvilket fortalte os, at vi var gået fra at sælge noget, der var rart at have, til noget, folk ikke kunne drive deres virksomhed uden.

Dratas mission om at skabe løbende tillid har ikke ændret sig med AI, men omfanget af den tillid er blevet større. Vi begyndte med at automatisere det hårde arbejde med compliance og gik derefter videre til agentbaserede arbejdsgange, der kunne gennemføre risikovurderinger af tredjeparter og sikkerhedsspørgeskemaer fra start til slut. Men det egentlige skift kom, da agenterne selv blev noget, der skulle styres. Nu har vi udvidet platformen, så den også understøtter styring af AI-agenter: Find agenterne, styr, hvad de må gøre, og fremlæg dokumentation, der kan stå sin prøve, når nogen spørger.

Du har introduceret udtrykket »insidertrussel fra AI-agenter« om risici, der skyldes en organisations egne AI-agenter og ikke en ekstern angriber. Hvad adskiller en insidertrussel fra AI-agenter fra den traditionelle insidertrussel, som sikkerhedsteams har brugt årtier på at forberede sig på?

Traditionelle insidertrusler handler om, at en person misbruger den adgang, vedkommende allerede har – for eksempel en utilfreds medarbejder, en skødesløs medarbejder eller en person, der bare klikker på det forkerte. Sikkerhedsteams har brugt årtier på at opbygge programmer til at håndtere den risiko med fokus på baggrundstjek, mindst mulige adgangsrettigheder, tjeklister ved fratrædelse og lignende.

Insidertruslen fra agenter er anderledes, fordi agenten aldrig fik adgang til at begynde med. Risikoen går fra misbrug til at skaffe sig adgang. Hvis en agent får et mål, og den oplagte vej til at nå det er blokeret, opretter den ikke bare en supportsag og venter, sådan som et menneske ville gøre. Den prøver at finde en anden vej, en tjenestekonto med en svag adgangskode eller et slutpunkt, som ingen huskede at lukke. Den skaffer sig adgang uden ond hensigt eller nogen bevidst overtrædelse af reglerne. Den gør præcis, hvad du bad den om, og det er dét, der gør den så svær at opdage. Hvert skridt virker fornuftigt, når man ser på det isoleret, og til sidst melder agenten, at opgaven er løst.

Vi ved allerede, hvordan vi styrer medarbejdere og tredjeparter med adgang til følsomme systemer, men agenter er en tredje gruppe, og de værktøjer, der er udviklet til de to første grupper, når ikke ud til dem.

AI-agenter kan forfølge mål vedholdende, arbejde med maskinhastighed og interagere med flere systemer uden den dømmekraft, en menneskelig medarbejder måske ville udvise. Hvor grundlæggende ændrer det virksomhedens trusselsmodel?

Det ændrer først og fremmest tidsforløbet. Et menneske, der leder efter en vej ind i et system, bliver før eller siden træt, bliver opdaget eller giver op. Det gør en agent ikke. En åben dør, som ingen hidtil har opdaget, bliver nu fundet, fordi agenten ikke bliver træt og ikke holder op med at lede.

Og det drejer sig ikke kun om én dør. En agent, der er bygget til at udføre én opgave, går gerne ind i et dusin systemer på vejen mod at løse den – henter kontohistorik ét sted og undersøger en database et andet – selv om det meste ikke har noget at gøre med det, den faktisk blev bedt om. På vej mod at lave én præsentation kan den komme igennem en anden kundes data, regnskabsoplysninger, medarbejderoplysninger eller hvad der ellers ligger på dens vej. Intet af det bliver registreret som en hændelse.

Trusselsmodellen har altså ændret sig. Det spørgsmål, et sikkerhedsteam bør stille sig i dag, er, hvor langt dets egne agenter vil gå for at løse en opgave, hvis ingen har fortalt dem, hvor de skal stoppe.

Mange organisationer har allerede identitets- og adgangsstyring, privilegeret adgangsstyring og nul tillidsarkitekturer på plads. Hvorfor er disse kontroller ikke i sig selv tilstrækkelige til at styre autonome AI-agenter?

Disse rammer blev udviklet til mennesker og leverandører – grupper, der begge kan udvise dømmekraft, og som begge stopper, når de møder en grænse. Agenters identitet kræver samme grundighed som den, der er udviklet til mennesker og tredjepartsrisiko: kortlægning, ejerskab og dokumentation, som en revisor kan stå inde for. Problemet er, at der endnu ikke findes en fælles standard for, hvad det egentlig vil sige, at en agent, som har adgangsoplysningerne, er »underlagt styring«.

En agent, som en af jeres ingeniører har oprettet, kan for eksempel handle med den pågældende ingeniørs adgangsrettigheder – selv på systemer, som ingeniøren aldrig selv bruger. IAM og PAM bygger på en antagelse om, at den, der har adgangsoplysningerne, ved, hvornår vedkommende skal stoppe, men agenter har ikke denne antagelse indbygget.

Bør virksomheder begynde at behandle hver AI-agent som sin egen maskinidentitet med en tydeligt defineret ejer, tilladelser, et afgrænset anvendelsesområde og en livscyklus? Hvordan ville en moden identitetsramme for agenter se ud?

Ja, men de fleste virksomheder er ikke nået dertil endnu. Flere, end man skulle tro, kan ikke engang fortælle, hvor mange agenter der kører i deres organisation, endsige hvem der er ansvarlig for hver enkelt. Et modent rammeværk begynder med kortlægning – en reel, løbende fortegnelse over alle agenter. Derefter skal hver agent have en ansvarlig, et klart defineret omfang for, hvad den må tilgå, og politikker, der håndhæver disse begrænsninger i praksis. På baggrund af vores egen undersøgelse ser vi den samme fejl på leverandørsiden – tre ud af fire organisationer revurderer kun deres tredjeparter én gang om året eller sjældnere, så de træffer beslutninger ud fra data, der allerede er forældede, når noget ændrer sig. Øjebliksbilleder er ikke tilstrækkelige for agenter, hverken interne eller eksterne

Vi ønsker én standard, som alle agenter skal leve op til på samme måde, i stedet for at sikkerhedsteams skal opspore, hvad hver enkelt udvikler har bygget på egen hånd. Det kræver politikker, der kan formuleres i et klart og enkelt sprog, afprøves mod faktisk historisk trafik, før de aktiveres, og derefter håndhæves direkte i arbejdsgangen, så rammen gælder for enhver handling, agenten foretager, i stedet for blot at stå i dokumentationen.

Et særligt vanskeligt scenarie opstår, når en agent overtræder sikkerhedspolitikken uden at handle ondsindet. Hvis en agent finder en utilsigtet vej til følsomme data, blot fordi den forsøger at løse sin tildelte opgave, hvordan kan sikkerhedsteams så skelne mellem vellykket automatisering og en sikkerhedshændelse?

Lige nu er det ærlige svar, at det kan man ikke. Forestil jer en supportagent, der er udviklet til at udarbejde kvartalsvise forretningsgennemgange, og som får besked på at hente kontohistorik og lave præsentationen. Den direkte vej – eksporten, den skal hente oplysningerne fra – er tom. Et menneske ville stoppe dér, men agenten finder en anden vej, og set fra dens perspektiv lykkedes opgaven.

Opgaven blev ganske vist løst, men agenten gjorde det ved at omgå jeres sikkerhedsprotokoller og tilgå systemer, den ikke skulle have adgang til. Det afgørende spørgsmål må være, om agenten holdt sig inden for det anvendelsesområde, vi havde fastlagt for den. Det har aldrig været spørgsmålet, om den fik opgaven løst. Det er et spørgsmål om politik. Det kræver, at anvendelsesområdet afgrænses så præcist, at »vellykket automatisering« og »sikkerhedshændelse« ikke fremstår som det samme bagefter.

Traditionel sikkerhedsovervågning opdager ofte mistænkelig aktivitet, efter at den har fundet sted, men en autonom agent kan nå at udføre hundredvis af handlinger, før et menneske kan reagere. Kræver agentisk AI sikkerhedskontroller, der fungerer direkte i udførelsesforløbet, i stedet for primært at basere sig på alarmer og efterfølgende overvågning?

Ja, uden tvivl. Hvis I først opdager det under kørsel, er det allerede for sent. Når et overvågningsværktøj markerer handlingen, er den allerede udført. I vil have en fuldstændig oversigt over præcis, hvordan jeres systemer blev udsat, men der er ingen vej tilbage, så I kan ikke nå at standse det.

Den eneste form for styring, der virker ved maskinhastighed, er en, der vurderer handlingen, før den udføres, og stopper overtrædelser direkte i arbejdsgangen. Vi ville aldrig give en nyansat adgang til vores mest følsomme data og blot håbe, at overvågningen ville opdage alt, hvad der gik galt. Agenter fortjener samme grad af omhu, netop når handlingen er ved at blive udført. Ikke bagefter.

Model Context Protocol (MCP) og andre grænseflader mellem agenter og værktøjer giver AI-systemer adgang til stadig mere avancerede eksterne funktioner. Hvilke nye sikkerhedsgrænser skal der være omkring værktøjskald, API’er, adgangsoplysninger og tjenestekonti, efterhånden som virksomheder udvider, hvad deres agenter må gøre?

Værktøjskaldet er den nye sikkerhedsgrænse. Hver gang en agent forsøger at bruge en adgangsoplysning, kalder et API eller anvender et værktøj, opstår der et beslutningspunkt. I dag har de fleste store virksomheder ingen grænse ved netop dette punkt, som vurderer, om handlingen bør udføres. Det er den brik, der har manglet. Vi ser den samme blinde vinkel udefra og ind: Kun 37 % af sikkerhedslederne er sikre på, at de overhovedet kan identificere, hvor AI anvendes hos de leverandører, de allerede samarbejder med. Hvis man ikke kan se det i en leverandørs produkt, opdager man heller ikke det næste, ens egen agent foretager sig. Adgangsoplysningerne og servicekontiene bag alt dette kræver også samme stringens, som vi anvender på menneskers adgang: kendt ejerskab, klart defineret omfang og regelmæssig gennemgang. En agent bør ikke kunne bruge en adgangsoplysning, den aldrig har fået tildelt, blot fordi oplysningen fandtes et sted på dens vej.

Hvilken grad af sporbarhed bør organisationer realistisk set kunne levere, når en revisor, en tilsynsmyndighed eller en kunde spørger, hvad en AI-agent har tilgået, hvilke beslutninger den har truffet, og hvor de data, der kom ud af det, endte? Kan revisionsspor for agenter med tiden blive lige så grundlæggende som traditionelle adgangslogfiler?

Organisationer bør på anmodning kunne svare på, hvad en agent har tilgået, hvilke beslutninger den har truffet, og hvor de data, der kom ud af det, endte. Det er ikke nok at besvare spørgsmålet ved efterfølgende at sammenstykke oplysninger fra logfiler. Kravet er et løbende, manipulationssikret spor, der allerede findes, når spørgsmålet bliver stillet. Lige nu er svaret på disse spørgsmål tavshed fra de fleste virksomheder. Det er ikke en mangel, man kan bortforklare over for en kunde, og afhængigt af, hvad der er lækket, er det heller ikke noget, tilsynsmyndighederne vil acceptere.

Og ja, jeg tror, at revisionsspor for agenter snart bliver lige så grundlæggende som adgangslogfiler. I årevis har vi betragtet spørgsmålet »hvem tilgik hvad og hvornår« som et ufravigeligt krav for menneskelige systemer. Der er ingen grund til, at agenter skal være underlagt en lavere standard, blot fordi det ikke var et menneske, der klikkede. Rammeværk som EU AI Act, AIUC-11 og ISO 42001 skubber allerede udviklingen i den retning. Sporbarhed for agenter skal følge de samme kontroller og den samme dokumentationslogik, som allerede driver compliance-programmer. Hvis man behandler det som en eftertanke, bliver det tilsidesat.

Ser du fremad, forventer du så, at styring af AI-agenter bliver en selvstændig sikkerhedskategori, eller vil den i sidste ende blive indarbejdet i eksisterende platforme til styring, risikohåndtering, compliance, identitetsstyring og cybersikkerhed? Hvad mener du, at virksomheder skal have på plads, før de kan udrulle fuldt autonome agenter sikkert i stor skala?

Hver større teknologibølge skaber sin egen sikkerhedsbølge – skyen skabte Wiz, og endpoint-sikkerhed skabte CrowdStrike – og AI-agenter skaber en sådan bølge nu. Modeludbydere bygger administrationskonsoller og politikker til deres egne platforme, hvilket er nyttigt, men ingen virksomhed er baseret på én modeludbyder, én kodeassistent og ét sæt internt udviklede agenter. Nogen skal styre det hele med ét sæt politikker og én dokumentationskilde, og det er ikke et problem, som en enkelt AI-platform er bygget til at løse. Det er ikke derfor, de findes. Styring af AI-agenter er allerede en selvstændig kategori, selv om den kobles sammen med de GRC-, identitets- og compliancesystemer, virksomhederne allerede bruger.

Før virksomheder kan udrulle fuldt autonome agenter i stor skala, skal de have fire ting på plads, og de fleste har endnu ikke nogen af dem. For det første skal de have opdagelse i realtid – de skal vide, hvilke agenter der kører, hvem der ejer dem, og hvilken identitet de opererer under, i det øjeblik de oprettes.

Dernæst skal politikker håndhæves direkte i handlingsforløbet og vurderes, før en handling udføres. For det tredje har virksomheder brug for løbende overvågning af afvigelser, fordi agenter lever længere end den session, der oprettede dem, og deres beføjelser kan gradvist blive udvidet uden varsel. Endelig skal der være et manipulationssikret spor af hver eneste beslutning, en agent træffer, knyttet til de rammeværk, som revisorer og tilsynsmyndigheder faktisk anerkender. Det er dette lag, vi bygger hos Drata. Uden det satser en virksomhed, der udruller autonome agenter i stor skala, blot på, at alt går godt.

Tak for det gode interview. Læsere, der gerne vil udforske styring af AI-agenter, løbende compliance og kontroller mod trusler fra interne agenter, bør besøge Drata.