Adam Markowitz, director general și cofondator al Drata – Serie de interviuri

Adam Markowitz este director general și cofondator al Drata, unde extinde activitatea companiei în domeniul conformității continue și al încrederii, incluzând guvernanța agenților IA. Înainte de a cofondat Drata în 2020, a fondat Portfolium împreună cu Troy Markowitz și Daniel Marashlian. Experiența sa în gestionarea chestionarelor de securitate, a auditurilor și a evaluărilor de conformitate a contribuit la conturarea abordării Drata privind automatizarea modului în care organizațiile își demonstrează încrederea.

Drata oferă o platformă pentru guvernanță, risc și conformitate, care reunește colectarea automată a dovezilor, monitorizarea continuă a controalelor, gestionarea riscurilor asociate terților și fluxuri de lucru pentru chestionarele de securitate. Funcționalitățile sale de guvernanță a agenților IA se concentrează pe descoperirea agenților, aplicarea politicilor înainte de executarea acțiunilor și înregistrarea deciziilor pentru a putea fi auditate. În acest interviu, Markowitz discută despre amenințările interne reprezentate de agenți, identitatea mașinilor, limitele de securitate ale apelurilor către instrumente și controalele de care au nevoie companiile pentru a implementa agenți autonomi la scară largă.

Ați fondat anterior Portfolium, înainte de a cofondat Drata în 2020, după ce ați văzut direct cât de greoaie putea deveni conformitatea cu cerințele de securitate pe măsură ce o companie se dezvolta. Ce v-a convins că problema merita să construiți o companie complet nouă în jurul ei și cum a evoluat misiunea Drata pe măsură ce IA a schimbat peisajul securității?

În timp ce conduceam Portfolium împreună cu cofondatorii mei, Troy Markowitz și Daniel Marashlian, am învățat o lecție valoroasă: în afaceri, încrederea se câștigă în timp, nu printr-un discurs de vânzare. Având în vedere volumul mare și caracterul sensibil al informațiilor despre studenți, universitățile și companiile nu voiau să colaboreze cu noi până nu le demonstram că făceam ceea ce trebuia pentru a le proteja datele. Ne-am dat seama că efortul lent și anevoios de a parcurge manual fiecare chestionar de securitate, audit și evaluare de conformitate era o experiență comună. După ce Portfolium a fost achiziționată, ne-am reunit cu Troy și Daniel și am petrecut șase luni construind prima versiune a Drata. Am discutat cu zeci de companii și auditori pentru a valida problema înainte chiar să începem să scriem cod. La lansare, am ajuns la 100 de clienți în primele șase săptămâni și la 1.000 în decurs de un an — ceea ce ne-a arătat că trecuserăm de la a vinde ceva „util, dar nu indispensabil” la ceva fără de care oamenii nu puteau funcționa.

Odată cu IA, misiunea Drata de a oferi încredere continuă nu s-a schimbat, dar sfera acestei încrederi s-a extins. Am început prin a automatiza munca anevoioasă de asigurare a conformității, apoi am trecut la fluxuri de lucru bazate pe agenți, care puteau realiza cap-coadă evaluări ale riscurilor asociate terților și completarea chestionarelor de securitate. Însă adevărata schimbare a venit când agenții înșiși au devenit obiectul guvernanței. Acum, am extins platforma pentru a susține guvernanța agenților IA: să descopere agenții, să reglementeze ce au voie să facă și să producă dovezi care rezistă verificării atunci când cineva le solicită.

Ați introdus termenul „amenințare internă reprezentată de agenți” pentru a descrie riscurile generate nu de un atacator extern, ci de propriii agenți IA ai unei organizații. Ce deosebește o astfel de amenințare de amenințarea internă tradițională pentru care echipele de securitate se pregătesc de zeci de ani?

Amenințările interne tradiționale se referă la situațiile în care o persoană folosește în mod abuziv accesul pe care îl are deja, de exemplu un angajat nemulțumit, unul neglijent sau cineva care pur și simplu apasă pe butonul greșit. De zeci de ani, echipele de securitate au construit programe pentru a gestiona acest risc, concentrându-se pe verificări de antecedente, principiul privilegiului minim, liste de verificare pentru încetarea colaborării și altele asemenea.

Amenințarea internă reprezentată de agenți este diferită, deoarece agentului nu i s-a acordat acces de la bun început. Riscul se mută de la utilizarea abuzivă la obținerea accesului. Dacă unui agent i se dă un obiectiv, dar i se blochează calea directă și clară pentru a-l atinge, nu depune pur și simplu o solicitare și nu așteaptă, așa cum ar face o persoană. Încearcă să găsească o altă cale: un cont de serviciu cu o parolă slabă sau un punct de acces pe care nimeni nu și-a amintit să-l închidă. Își face singur loc, fără intenții malițioase și fără să știe că încalcă vreo politică. Face exact ce i-ai cerut, iar asta îl face atât de greu de detectat. Privit separat, fiecare pas pare rezonabil, iar la final agentul raportează că a reușit.

Știm deja cum să gestionăm angajații și terții care au acces la sisteme sensibile, dar agenții formează o a treia categorie, iar instrumentele create pentru primele două nu îi pot acoperi.

Agenții IA pot urmări obiective cu perseverență, pot acționa cu viteza mașinilor și pot interacționa cu mai multe sisteme fără discernământul pe care l-ar putea exercita un angajat. În ce măsură schimbă fundamental acest lucru modelul de amenințări al unei companii?

Mai presus de orice, schimbă intervalul de timp. O persoană care caută o cale de a pătrunde într-un sistem, la un moment dat se plictisește, este prinsă sau renunță. Un agent nu face asta. Acum, agentul găsește o portiță deschisă care înainte nu fusese descoperită, pentru că nu obosește și nu încetează să caute.

Și nu e vorba doar de o singură portiță. Un agent creat pentru o anumită sarcină va accesa cu plăcere o duzină de sisteme pe drumul spre îndeplinirea ei — consultând istoricul unui cont aici, verificând o bază de date acolo — deși mare parte din acestea nu au nicio legătură cu ceea ce i s-a cerut de fapt. În timp ce pregătește o prezentare, poate ajunge la datele altui client, la evidențe financiare, la informații despre angajați, la orice îi iese în cale. Nimic din toate acestea nu apare ca incident.

Așadar, modelul de amenințări s-a schimbat. Întrebarea pe care ar trebui să și-o pună astăzi o echipă de securitate este până unde vor merge propriii agenți pentru a îndeplini o sarcină, dacă nimeni nu le-a spus unde să se oprească.

Multe organizații dispun deja de soluții de gestionare a identității și accesului, de gestionare a accesului privilegiat și de arhitecturi de încredere zero. De ce nu sunt suficiente, de unele singure, aceste măsuri de control pentru a guverna agenții IA autonomi?

Aceste cadre au fost concepute pentru oameni și furnizori — două categorii care au discernământ și se opresc când întâmpină un obstacol. Identitatea agenților are nevoie de aceeași rigoare aplicată în cazul oamenilor și al riscurilor asociate terților: identificarea, asumarea responsabilității și dovezi pe care un auditor să se poată baza. Problema este că încă nu există un standard comun pentru ceea ce înseamnă, de fapt, „guvernat” atunci când cel care deține acreditarea este un agent.

De exemplu, un agent creat de unul dintre inginerii dvs. poate acționa cu drepturile de acces ale acelui inginer — inclusiv în sisteme pe care inginerul nu le accesează niciodată personal. IAM și PAM presupun că entitatea care deține acreditarea știe când să se oprească, dar agenții nu sunt concepuți pornind de la această premisă.

Ar trebui întreprinderile să înceapă să trateze fiecare agent IA ca pe o identitate proprie de mașină, cu un responsabil, permisiuni, un domeniu de acces și un ciclu de viață clar definite? Cum ar arăta un cadru matur de gestionare a identității agenților?

Da, însă majoritatea întreprinderilor nu au ajuns încă în acest punct. Mai multe decât v-ați aștepta nu vă pot spune nici măcar câți agenți funcționează în organizațiile lor, darămite cine răspunde de fiecare dintre ei. Un cadru matur începe cu identificarea — un inventar real și actualizat continuu al fiecărui agent. Apoi, fiecare agent are nevoie de un responsabil, de un domeniu de acces clar definit și de politici care să impună efectiv respectarea acestuia. Din cercetările noastre, observăm aceeași problemă și în relația cu furnizorii — trei din patru organizații își reevaluează terții doar o dată pe an sau mai rar, astfel că iau decizii de guvernanță pe baza unor date deja depășite în momentul în care se schimbă ceva. Evaluările punctuale nu sunt suficiente pentru agenți, fie ei interni sau externi

Ne dorim un singur standard aplicat în același mod tuturor agenților, în loc ca echipele de securitate să fie nevoite să investigheze ce a construit fiecare dezvoltator pe cont propriu. Asta înseamnă politici care pot fi redactate într-un limbaj simplu, testate pe baza traficului istoric real înainte de a fi activate și apoi aplicate direct în fluxul de execuție, astfel încât cadrul să monitorizeze fiecare acțiune a agentului și să nu rămână doar în documentație.

Un scenariu deosebit de dificil este cel în care un agent încalcă politica de securitate fără să se comporte cu intenții răuvoitoare. Dacă un agent descoperă o cale neprevăzută către date sensibile doar pentru că încearcă să ducă la bun sfârșit sarcina care i-a fost atribuită, cum pot echipele de securitate să distingă între automatizarea reușită și un incident de securitate?

În momentul de față, răspunsul sincer este că nu puteți. Imaginați-vă un agent de asistență conceput să redacteze evaluări trimestriale ale activității și căruia i se cere să extragă istoricul contului și să pregătească prezentarea. Calea obișnuită — exportul din care ar trebui să preia datele — nu returnează nimic. Un om s-ar opri aici, dar agentul găsește o altă cale și, din perspectiva lui, a obținut rezultatul dorit.

Deși sarcina a fost îndeplinită, agentul a făcut-o ocolind protocoalele de securitate și accesând sisteme pe care nu trebuia să le deschidă. Întrebarea care face diferența este dacă agentul a rămas în limitele domeniului de acces pe care i l-am stabilit. Nu îndeplinirea sarcinii a fost vreodată problema. Este o chestiune de politică. Asta înseamnă să definești limite suficient de stricte, astfel încât, după faptă, „automatizarea reușită” și „incidentul de securitate” să nu pară identice.

Monitorizarea tradițională a securității identifică adesea activitatea suspectă după ce aceasta a avut loc, însă un agent autonom poate efectua sute de acțiuni înainte ca un om să poată interveni. Este nevoie ca IA agentică să aibă controale de securitate care acționează direct în fluxul de execuție, în loc să se bazeze în principal pe alerte și monitorizare retrospectivă?

Da, fără îndoială. Dacă detectați problema în timpul execuției, este deja prea târziu. Până când un instrument de monitorizare semnalează acțiunea, aceasta a fost deja executată. Veți avea o evidență perfectă a modului exact în care ați fost expuși, dar nu veți mai putea opri ceea ce s-a întâmplat.

Singura formă de guvernanță eficientă pentru ceva care se mișcă cu viteza unei mașini este cea care evaluează acțiunea înainte de executare și blochează încălcarea direct în fluxul de execuție. Nu i-am încredința niciodată unui angajat nou cele mai sensibile date ale noastre, bazându-ne doar pe speranța că monitorizarea va detecta orice problemă. Agenții merită aceeași rigoare, chiar în momentul în care acțiunea urmează să aibă loc. Nu după aceea.

Model Context Protocol (MCP) și alte interfețe dintre agenți și instrumente oferă sistemelor IA acces la capabilități externe din ce în ce mai puternice. Ce noi limite de securitate trebuie stabilite în jurul apelurilor către instrumente, API-urilor, acreditărilor și conturilor de serviciu, pe măsură ce întreprinderile extind gama de acțiuni permise agenților?

Apelarea unui instrument este noul perimetru de securitate. De fiecare dată când un agent solicită o acreditare, apelează un API sau invocă un instrument, se ia o decizie, iar în prezent, în majoritatea companiilor, nu există nicio barieră care să evalueze în acel moment precis dacă acțiunea ar trebui să aibă loc. Aceasta este piesa care a lipsit. Vedem același punct nevralgic și din exterior: doar 37% dintre liderii din domeniul securității sunt siguri că pot identifica măcar unde funcționează AI în cadrul furnizorilor cu care colaborează deja. Dacă nu poți vedea acest lucru în produsul unui furnizor, nu vei putea vedea nici următoarea acțiune a propriului agent. Acreditările și conturile de serviciu care stau la baza tuturor acestor procese au nevoie de același nivel de rigoare pe care îl aplicăm accesului uman: proprietar cunoscut, domeniu de aplicare definit și revizuire periodică. Un agent nu ar trebui să poată accesa o acreditare care nu i-a fost niciodată acordată doar pentru că aceasta exista undeva pe traseul său.

Când un auditor, un organism de reglementare sau un client întreabă la ce a avut acces un agent AI, ce decizii a luat și unde au ajuns datele rezultate, ce nivel de trasabilitate ar trebui să poată oferi organizațiile în mod realist? Ar putea pistele de audit ale agenților să devină, în cele din urmă, la fel de fundamentale ca jurnalele tradiționale de acces?

La cerere, organizațiile ar trebui să poată răspunde la întrebările despre ce a accesat un agent, ce decizii a luat și unde au ajuns datele rezultate. Nu este suficient să reconstituie răspunsul ulterior, reunind informații din jurnale. Standardul este o evidență continuă, care permite detectarea modificărilor neautorizate și care există deja în momentul în care este pusă întrebarea. În prezent, majoritatea companiilor nu au niciun răspuns la aceste întrebări. Nu poți justifica în fața unui client o astfel de lacună, iar, în funcție de ce s-a divulgat, nici autoritățile de reglementare nu o vor accepta.

Și da, cred că pistele de audit ale agenților vor deveni în curând la fel de fundamentale ca jurnalele de acces. De ani buni, am considerat nenegociabilă înregistrarea informațiilor despre „cine a accesat ce și când” în cazul sistemelor utilizate de oameni. Nu există niciun motiv pentru care agenții să fie supuși unor standarde mai puțin stricte doar pentru că nu o persoană a făcut clic. Cadre precum EU AI Act, AIUC-11 și ISO 42001 impulsionează deja această direcție. Trasabilitatea agenților trebuie să corespundă acelorași controale și aceleiași logici de colectare a dovezilor care susțin deja programele de conformitate. Dacă este tratată ca o chestiune secundară, va fi marginalizată.

Privind spre viitor, credeți că guvernanța agenților AI va deveni o categorie distinctă de securitate sau va fi, în cele din urmă, integrată în platformele existente de guvernanță, risc, conformitate, identitate și securitate cibernetică? Ce credeți că vor trebui să aibă companiile la dispoziție înainte de a putea implementa în siguranță agenți cu adevărat autonomi, la scară largă?

Fiecare val major de tehnologii generează propriul val de soluții de securitate: cloudul a dat naștere companiei Wiz, iar securitatea punctelor terminale, companiei CrowdStrike. Acum, agenții AI generează un astfel de val. Furnizorii de modele construiesc console și politici pentru propriile platforme, ceea ce este util, dar nicio companie nu se bazează pe un singur furnizor de modele, un singur asistent de programare și un singur set de agenți dezvoltați intern. Cineva trebuie să guverneze toate acestea printr-un set unic de politici și cu o singură sursă de dovezi, iar nicio platformă AI nu este concepută să rezolve această problemă. Nu acesta este scopul existenței lor. Guvernanța agenților AI este deja o categorie distinctă, chiar dacă se conectează la sistemele de GRC, identitate și conformitate pe care companiile le folosesc deja.

Înainte de a putea implementa agenți cu adevărat autonomi la scară largă, companiile trebuie să aibă la dispoziție patru lucruri, iar majoritatea nu are încă niciunul. Primul este descoperirea în timp real: să știe, chiar din momentul creării, fiecare agent care rulează, cine îi este responsabil și cu ce identitate operează.

Al doilea este aplicarea politicilor în linie, cu evaluarea lor înainte de executarea unei acțiuni. În al treilea rând, companiile au nevoie de monitorizare continuă pentru a detecta abaterile, deoarece agenții continuă să funcționeze și după încheierea sesiunii în care au fost creați, iar domeniul lor de aplicare se poate extinde pe nesimțite. În sfârșit, este nevoie de o evidență a fiecărei decizii luate de un agent, care să permită detectarea modificărilor neautorizate și să fie corelată cu cadrele recunoscute efectiv de auditori și autoritățile de reglementare. Acesta este nivelul pe care îl construim la Drata. Fără el, o companie care implementează agenți autonomi la scară largă nu face decât să se bazeze pe speranță.

Vă mulțumim pentru interviul excelent. Cititorii care doresc să afle mai multe despre guvernanța agenților AI, conformitatea continuă și controalele împotriva amenințărilor interne generate de agenți ar trebui să viziteze Drata.