Adam Markowitz, administrerende direktør og medgrunnlegger av Drata – intervjuserie

Adam Markowitz er administrerende direktør og medgrunnlegger av Drata, der han utvider selskapets arbeid med kontinuerlig etterlevelse og tillit til også å omfatte styring av AI-agenter. Før han var med på å grunnlegge Drata i 2020, grunnla han Portfolium sammen med Troy Markowitz og Daniel Marashlian. Erfaringen hans med sikkerhetsspørreskjemaer, revisjoner og etterlevelsesvurderinger bidro til å forme Dratas tilnærming til å automatisere hvordan organisasjoner viser at de er til å stole på.

Drata tilbyr en plattform for styring, risiko og etterlevelse som kombinerer automatisert innsamling av dokumentasjon, kontinuerlig overvåking av kontroller, risikostyring knyttet til tredjeparter og arbeidsflyter for sikkerhetsspørreskjemaer. Plattformens funksjoner for styring av AI-agenter fokuserer på å oppdage agenter, håndheve retningslinjer før handlinger utføres og registrere beslutninger slik at de kan etterprøves. I dette intervjuet snakker Markowitz om trusler fra interne agenter, maskinidentitet, sikkerhetsgrenser for verktøykall og hvilke kontroller virksomheter trenger for å ta i bruk autonome agenter i stor skala.

Du grunnla tidligere Portfolium før du var med på å grunnlegge Drata i 2020, etter selv å ha erfart hvor tungvint etterlevelse av sikkerhetskrav kunne bli etter hvert som et selskap vokste. Hva fikk deg til å mene at dette var et problem det var verdt å bygge et helt nytt selskap rundt, og hvordan har Dratas oppdrag utviklet seg etter hvert som AI har endret sikkerhetslandskapet?

Da jeg ledet Portfolium sammen med medgründerne mine, Troy Markowitz og Daniel Marashlian, lærte vi en viktig lekse: Tillit i næringslivet bygges over tid; den kan ikke skapes med en salgspitch. På grunn av den store mengden sensitive studentopplysninger ville ikke universiteter og virksomheter inngå samarbeid med oss før vi hadde vist at vi gjorde det vi skulle for å beskytte dataene deres. Vi innså at den langsomme og krevende jobben med å gå manuelt gjennom hvert eneste sikkerhetsspørreskjema, hver revisjon og hver etterlevelsesvurdering var en erfaring mange delte. Etter at Portfolium ble kjøpt opp, fant Troy, Daniel og jeg sammen igjen, og vi brukte seks måneder på å bygge den første versjonen av Drata. Vi snakket med dusinvis av selskaper og revisorer for å bekrefte at problemet var reelt, før vi i det hele tatt begynte å skrive kode. Da vi lanserte, nådde vi 100 kunder i løpet av de første seks ukene og 1 000 innen ett år – noe som viste oss at vi hadde gått fra å selge noe som var «kjekt å ha», til noe folk ikke kunne drive virksomheten sin uten.

Med AI har Dratas oppdrag om å levere kontinuerlig tillit ikke endret seg, men omfanget av denne tilliten har blitt større. Vi begynte med å automatisere det krevende etterlevelsesarbeidet, og utvidet deretter til agentbaserte arbeidsflyter som kunne gjennomføre risikovurderinger av tredjeparter og håndtere sikkerhetsspørreskjemaer fra start til slutt. Men den virkelige endringen kom da agentene selv ble noe som måtte styres. Nå har vi utvidet plattformen slik at den også kan brukes til styring av AI-agenter: oppdag agentene, styr hva de har lov til å gjøre, og legg fram dokumentasjon som tåler granskning når noen ber om den.

Du har introdusert begrepet «innsidetrussel fra agenter» for å beskrive risikoer som skyldes en organisasjons egne AI-agenter, ikke en ekstern angriper. Hva skiller en slik innsidetrussel fra den tradisjonelle innsidetrusselen som sikkerhetsteam har brukt flere tiår på å forberede seg på?

Tradisjonelle innsidetrusler handler om at en person misbruker tilgang vedkommende allerede har, for eksempel en misfornøyd eller uaktsom medarbeider, eller noen som rett og slett klikker på feil ting. Sikkerhetsteam har brukt flere tiår på å bygge programmer for å håndtere denne risikoen, med vekt på bakgrunnssjekker, minste privilegium, sjekklister for avslutning av arbeidsforhold og lignende.

Innsidetrusselen fra agenter er annerledes fordi agenten aldri fikk tilgang i utgangspunktet. Risikoen går fra misbruk til at agenten skaffer seg tilgang. Hvis en agent får et mål, men den åpenbare veien til å nå det er blokkert, oppretter den ikke bare en sak og venter, slik et menneske ville gjort. Den prøver å finne en annen vei, for eksempel en tjenestekonto med et svakt passord eller et endepunkt ingen husket å stenge. Den skaffer seg adgang uten å være klar over at den handler ondsinnet eller bryter retningslinjer. Den gjør akkurat det du ba den om, og det er derfor den er så vanskelig å oppdage. Hvert enkelt steg virker rimelig isolert sett, og til slutt melder agenten at den har lykkes.

Vi vet allerede hvordan vi skal styre ansatte og tredjeparter som har tilgang til sensitive systemer, men agenter utgjør en tredje gruppe, og verktøyene vi har utviklet for de to første, når ikke fram til dem.

AI-agenter kan målrettet forfølge mål over tid, arbeide i maskinhastighet og samhandle med flere systemer uten å utvise den dømmekraften en menneskelig medarbeider kanskje ville brukt. Hvor grunnleggende endrer dette virksomhetens trusselmodell?

Først og fremst endrer det tidslinjen. Et menneske som leter etter en vei inn i et system, blir til slutt lei, blir tatt eller gir opp. En agent gjør ikke det. En åpen dør som ingen hadde oppdaget før, blir nå funnet fordi agenten ikke blir sliten og ikke slutter å lete.

Og det dreier seg ikke bare om én dør. En agent som er laget for å utføre én oppgave, er mer enn villig til å berøre et dusin systemer på veien mot å fullføre den – hente kontohistorikk ett sted, sjekke en database et annet – selv om det meste av dette ikke har noe med det den faktisk ble bedt om å gjøre. På vei mot å lage én presentasjon kan den komme innom en annen kundes data, økonomiske opplysninger, medarbeiderinformasjon – hva enn som ligger i veien. Ingenting av dette blir registrert som en hendelse.

Trusselmodellen har altså endret seg. Spørsmålet sikkerhetsteam bør stille seg i dag, er hvor langt deres egne agenter vil gå for å fullføre en oppgave hvis ingen har fortalt dem hvor de skal stoppe.

Mange organisasjoner har allerede identitets- og tilgangsstyring, privilegert tilgangsstyring og nulltillitsarkitekturer på plass. Hvorfor er ikke disse kontrollene alene tilstrekkelige for å styre autonome KI-agenter?

Disse rammeverkene ble utviklet for mennesker og leverandører – grupper som begge har dømmekraft, og som begge stanser når de møter en hindring. Agentidentitet krever den samme grundigheten som er etablert for mennesker og tredjepartsrisiko: kartlegging, eierskap og dokumentasjon en revisor kan gå god for. Problemet er at det ennå ikke finnes noen felles standard for hva «styrt» faktisk betyr når det er en agent som har tilgangsopplysningene.

En agent som for eksempel er opprettet av en av ingeniørene dine, kan handle med ingeniørens tilgang – også på systemer ingeniøren aldri selv bruker. IAM og PAM forutsetter at den som har tilgangsopplysningene, vet når den skal stanse, men agenter er ikke utviklet med en slik forutsetning.

Bør virksomheter begynne å behandle hver KI-agent som sin egen maskinidentitet, med en tydelig definert eier, tillatelser, virkeområde og livssyklus? Hvordan ville et modent identitetsrammeverk for agenter se ut?

Ja, men de fleste virksomheter har ikke kommet dit ennå. Flere enn man skulle tro, kan ikke engang si hvor mange agenter som kjører i organisasjonen, langt mindre hvem som eier hver enkelt. Et modent rammeverk begynner med kartlegging – en reell, løpende oversikt over alle agenter. Deretter trenger hver agent en eier, et definert virkeområde for hva den har lov til å få tilgang til, og retningslinjer som faktisk håndheves innenfor dette virkeområdet. Fra vår egen forskning ser vi det samme problemet hos leverandørene: Tre av fire organisasjoner vurderer tredjepartene sine på nytt bare én gang i året eller sjeldnere. Dermed baserer de styringen på data som allerede er utdaterte når noe endrer seg. Punktmålinger fungerer ikke for agenter, verken interne eller eksterne.

Vi ønsker én standard som gjelder likt for alle agenter, i stedet for at sikkerhetsteamet må undersøke hva hver enkelt utvikler har laget på egen hånd. Det innebærer retningslinjer som kan formuleres i klart språk, testes mot reelle historiske trafikkdata før de aktiveres og deretter håndheves direkte, slik at rammeverket ligger i handlingsforløpet for hver handling agenten utfører, og ikke bare står i dokumentasjonen.

Et særlig vanskelig scenario er en agent som bryter sikkerhetsreglene uten å opptre ondsinnet. Hvis en agent finner en utilsiktet vei til sensitive data bare fordi den prøver å fullføre oppgaven den er tildelt, hvordan kan sikkerhetsteam skille mellom vellykket automatisering og en sikkerhetshendelse?

Akkurat nå er det ærlige svaret at det kan man ikke. Se for deg en kundestøtteagent som er laget for å utarbeide kvartalsvise virksomhetsgjennomganger, og som får beskjed om å hente kontohistorikk og lage presentasjonen. Den tiltenkte veien – eksporten den skal hente data fra – er tom. Et menneske ville ha stoppet der, men agenten finner en annen vei, og sett fra agentens perspektiv var resultatet vellykket.

Oppgaven ble riktignok fullført, men agenten kom i mål ved å omgå sikkerhetsprotokollene dine og gå inn i systemer den ikke skulle ha åpnet. Det avgjørende spørsmålet må være om agenten holdt seg innenfor virkeområdet vi ga den. Det har aldri vært et spørsmål om å fullføre jobben. Det er et spørsmål om retningslinjer. Det betyr at virkeområdet må defineres så presist at «vellykket automatisering» og «sikkerhetshendelse» ikke ser identiske ut i ettertid.

Tradisjonell sikkerhetsovervåking avdekker ofte mistenkelig aktivitet etter at den har funnet sted, men en autonom agent kan utføre hundrevis av handlinger før et menneske rekker å reagere. Krever agentbasert KI sikkerhetskontroller som fungerer direkte i handlingsforløpet, i stedet for at man hovedsakelig baserer seg på varsler og overvåking i etterkant?

Ja, helt klart. Hvis du oppdager dette mens handlingen utføres, er det allerede for sent. Når et overvåkingsverktøy varsler om handlingen, har den allerede funnet sted. Du vil ha en fullstendig oversikt over nøyaktig hvordan du ble eksponert, men ingen mulighet til å stanse det.

Den eneste formen for styring som fungerer når noe beveger seg i maskinhastighet, er å vurdere handlingen før den utføres og stanse brudd direkte i handlingsforløpet. Vi ville aldri gitt en nyansatt tilgang til de mest sensitive dataene våre og bare håpet at overvåkingen skulle fange opp det som gikk galt. Agenter fortjener den samme disiplinen, idet handlingen er i ferd med å skje. Ikke etterpå.

Model Context Protocol (MCP) og andre grensesnitt mellom agenter og verktøy gir KI-systemer tilgang til stadig kraftigere eksterne funksjoner. Hvilke nye sikkerhetsgrenser må etableres rundt verktøykall, API-er, tilgangsopplysninger og tjenestekontoer etter hvert som virksomheter utvider hva agentene deres får lov til å gjøre?

Verktøykallet er den nye sikkerhetsgrensen. Hver gang en agent henter tilgangsopplysninger, kaller et API eller bruker et verktøy, oppstår det et beslutningspunkt. I dag har de fleste virksomheter ingen grense på akkurat dette punktet som vurderer om handlingen bør utføres. Det er dette som har manglet. Vi ser det samme blindfeltet utenfra og inn – bare 37 % av sikkerhetslederne er sikre på at de i det hele tatt kan identifisere hvor AI kjører hos leverandørene de allerede samarbeider med. Hvis du ikke kan se det i et produkt fra en leverandør, kommer du heller ikke til å se det neste agenten din foretar seg. Tilgangsopplysningene og tjenestekontoene som ligger til grunn for alt dette, må også håndteres med samme grundighet som vi bruker for menneskelig tilgang: kjent eierskap, tydelig avgrenset omfang og regelmessig gjennomgang. En agent skal ikke kunne hente tilgangsopplysninger den aldri har fått tildelt, bare fordi de finnes et sted i systemet den beveger seg gjennom.

Hvilken grad av sporbarhet bør virksomheter realistisk sett kunne tilby når en revisor, tilsynsmyndighet eller kunde spør hva en AI-agent fikk tilgang til, hvilke beslutninger den tok, og hvor dataene havnet? Kan revisjonsspor for agenter etter hvert bli like grunnleggende som tradisjonelle tilgangslogger?

På forespørsel bør virksomheter kunne svare på hva en agent fikk tilgang til, hvilke beslutninger den tok, og hvor dataene havnet. Det er ikke nok å sette sammen svaret i ettertid ved å lete i logger. Kravet bør være en kontinuerlig, manipulasjonssikker logg som allerede finnes når spørsmålet stilles. Akkurat nå får de fleste selskaper ikke svar på disse spørsmålene. Dette er ikke et hull man kan bortforklare overfor en kunde, og avhengig av hva som har lekket, er det heller ikke noe tilsynsmyndighetene vil godta.

Og ja, jeg tror revisjonsspor for agenter snart blir like grunnleggende som tilgangslogger. I årevis har vi behandlet «hvem fikk tilgang til hva, og når» som et ufravikelig krav for menneskestyrte systemer. Det er ingen grunn til at agenter skal holdes til en lavere standard bare fordi det ikke var et menneske som klikket. Rammeverk som EU AI Act, AIUC-11 og ISO 42001 bidrar allerede til å drive utviklingen i den retningen. Sporbarhet for agenter må knyttes til de samme kontrollene og den samme dokumentasjonslogikken som allerede ligger til grunn for etterlevelsesprogrammer. Hvis man behandler dette som noe man kan ta seg av senere, blir det skjøvet til side.

Ser du framover for deg at styring av AI-agenter blir en egen sikkerhetskategori, eller vil det til slutt bli innlemmet i eksisterende plattformer for styring, risiko, etterlevelse, identitet og cybersikkerhet? Hva tror du virksomheter må ha på plass før de trygt kan ta i bruk virkelig autonome agenter i stor skala?

Hver store teknologibølge skaper sin egen sikkerhetsbølge – nettskyen skapte Wiz, endepunktene skapte CrowdStrike – og AI-agenter skaper en nå. Modelltilbydere bygger konsoller og retningslinjer for sine egne plattformer. Det er nyttig, men ingen virksomhet baserer seg på én modelltilbyder, én kodeassistent og ett sett med internt utviklede agenter. Noen må styre alt dette etter ett felles sett med retningslinjer og med ett felles dokumentasjonsgrunnlag, og det er ikke et problem en enkelt AI-plattform er laget for å løse. Det er ikke derfor de finnes. Styring av AI-agenter er allerede en egen kategori, samtidig som den kobles til GRC-, identitets- og etterlevelsessystemene virksomhetene allerede bruker.

Før virksomheter kan ta i bruk virkelig autonome agenter i stor skala, må de ha fire ting på plass, og de fleste har foreløpig ingen av dem. Det første er oppdagelse i sanntid – å vite hvilke agenter som kjører, hvem som eier dem, og hvilken identitet de opererer under, i det øyeblikket de opprettes.

Det neste er retningslinjer som håndheves direkte i handlingsflyten og vurderes før en handling utføres. For det tredje trenger virksomheter kontinuerlig overvåking av avvik, ettersom agenter lever lenger enn økten som opprettet dem, og virkeområdet deres i det stille kan utvides. Til slutt må de ha en manipulasjonssikker logg over hver beslutning en agent tar, knyttet til rammeverkene revisorer og tilsynsmyndigheter faktisk anerkjenner. Det er dette laget vi bygger hos Drata. Uten det setter virksomheter som tar i bruk autonome agenter i stor skala, bare sin lit til håpet.

Takk for et flott intervju. Lesere som ønsker å utforske styring av AI-agenter, kontinuerlig etterlevelse og kontroller mot trusler fra innsidere som bruker agenter, bør besøke Drata.