Adam Markowitz, dyrektor generalny i współzałożyciel Drata – cykl wywiadów

Adam Markowitz jest dyrektorem generalnym i współzałożycielem Drata, gdzie rozwija działania firmy w obszarze ciągłego zapewniania zgodności i budowania zaufania, rozszerzając je o nadzór nad agentami AI. Zanim w 2020 roku współzałożył Drata, założył Portfolium wraz z Troyem Markowitzem i Danielem Marashlianem. Jego doświadczenie w pracy z ankietami dotyczącymi bezpieczeństwa, audytami i przeglądami zgodności pomogło ukształtować podejście Drata do automatyzacji sposobu, w jaki organizacje wykazują, że można im zaufać.

Drata oferuje platformę do zarządzania, ryzykiem i zgodnością, która łączy zautomatyzowane gromadzenie dowodów, ciągłe monitorowanie mechanizmów kontrolnych, zarządzanie ryzykiem związanym z podmiotami zewnętrznymi oraz obsługę ankiet dotyczących bezpieczeństwa. Funkcje nadzoru nad agentami AI koncentrują się na wykrywaniu agentów, egzekwowaniu zasad przed wykonaniem działań oraz rejestrowaniu decyzji na potrzeby audytu. W tym wywiadzie Markowitz omawia zagrożenia związane z agentami działającymi od wewnątrz organizacji, tożsamość maszynową, granice bezpieczeństwa wywołań narzędzi oraz mechanizmy kontrolne, których przedsiębiorstwa potrzebują, by wdrażać autonomicznych agentów na dużą skalę.

Wcześniej założyłeś Portfolium, a następnie w 2020 roku współzałożyłeś Drata, gdy na własnej skórze przekonałeś się, jak uciążliwe może stać się zapewnianie zgodności z wymogami bezpieczeństwa w miarę rozwoju firmy. Co sprawiło, że uznałeś, iż warto zbudować wokół tego problemu zupełnie nową firmę, i jak zmieniała się misja Drata w miarę jak AI przeobrażała krajobraz bezpieczeństwa?

Prowadząc Portfolium razem z moimi współzałożycielami, Troyem Markowitzem i Danielem Marashlianem, wyciągnęliśmy ważną lekcję: zdobywanie zaufania w biznesie to proces, a nie prezentacja sprzedażowa. Ze względu na dużą ilość i wrażliwy charakter danych studentów uniwersytety i przedsiębiorstwa nie chciały z nami współpracować, dopóki nie udowodniliśmy, że robimy to, co należy, aby chronić ich dane. Zrozumieliśmy, że powolne i żmudne ręczne wypełnianie każdej ankiety dotyczącej bezpieczeństwa, przechodzenie każdego audytu i każdego przeglądu zgodności to problem, z którym boryka się wiele firm. Po przejęciu Portfolium ponownie połączyliśmy siły z Troyem i Danielem. Przez sześć miesięcy budowaliśmy pierwszą wersję Drata, rozmawiając z dziesiątkami firm i audytorów, aby potwierdzić, że problem istnieje, zanim jeszcze zaczęliśmy pisać kod. Po uruchomieniu firmy zdobyliśmy 100 klientów w ciągu pierwszych sześciu tygodni, a w ciągu roku — 1000. Uświadomiło nam to, że przeszliśmy od sprzedawania czegoś, co „miło mieć”, do oferowania czegoś, bez czego ludzie nie mogli funkcjonować.

Wraz z rozwojem AI misja Drata, polegająca na zapewnianiu ciągłego zaufania, nie uległa zmianie, ale zakres tego zaufania się poszerzył. Zaczęliśmy od automatyzacji żmudnych procesów związanych ze zgodnością, a następnie rozszerzyliśmy działalność o agentowe przepływy pracy, które mogły przeprowadzać kompleksowe oceny ryzyka podmiotów zewnętrznych i obsługiwać ankiety dotyczące bezpieczeństwa od początku do końca. Prawdziwa zmiana nastąpiła jednak wtedy, gdy same agenty stały się podmiotem wymagającym nadzoru. Teraz rozszerzyliśmy platformę, aby umożliwić nadzór nad agentami AI: wykrywać agentów, kontrolować, co wolno im robić, i dostarczać dowody, które wytrzymają weryfikację, gdy ktoś o nie poprosi.

Wprowadziłeś termin „zagrożenie ze strony agenta wewnętrznego” na określenie ryzyka powodowanego nie przez zewnętrznego atakującego, lecz przez własne agenty AI organizacji. Czym zagrożenie ze strony agenta wewnętrznego różni się od tradycyjnego zagrożenia wewnętrznego, na które zespoły ds. bezpieczeństwa przygotowują się od dziesięcioleci?

Tradycyjne zagrożenia wewnętrzne dotyczą osób nadużywających przyznanego im dostępu — na przykład niezadowolonego pracownika, kogoś nieostrożnego albo osoby, która po prostu kliknie niewłaściwy element. Zespoły ds. bezpieczeństwa od dziesięcioleci budują programy ograniczające to ryzyko, koncentrując się między innymi na weryfikacji kandydatów, zasadzie minimalnych uprawnień i listach kontrolnych dotyczących odbierania dostępu odchodzącym pracownikom.

Zagrożenie ze strony agenta wewnętrznego jest inne, ponieważ agentowi nigdy nie przyznano dostępu. Ryzyko nie polega już na nadużyciu dostępu, lecz na jego zdobyciu. Jeśli agent otrzyma cel, a oczywista droga do jego osiągnięcia zostanie zablokowana, nie zgłosi po prostu problemu i nie będzie czekać, jak zrobiłby to człowiek. Spróbuje znaleźć inną drogę — konto usługowe ze słabym hasłem albo punkt końcowy, którego nikt nie pamiętał, by zamknąć. Uzyskuje dostęp bez złych intencji i bez świadomości, że narusza zasady. Robi dokładnie to, o co go poproszono, i właśnie dlatego tak trudno go wykryć. Każdy krok z osobna wydaje się rozsądny, a na koniec agent zgłasza, że zadanie zostało wykonane.

Wiemy już, jak nadzorować pracowników i podmioty zewnętrzne mające dostęp do wrażliwych systemów, ale agenty stanowią trzecią grupę, do której nie można zastosować narzędzi zbudowanych z myślą o dwóch pierwszych.

Agenty AI mogą konsekwentnie dążyć do celu, działać z szybkością maszyn i wchodzić w interakcje z wieloma systemami, nie kierując się osądem, jaki mógłby zastosować pracownik. Jak zasadniczo zmienia to model zagrożeń w przedsiębiorstwie?

Przede wszystkim zmienia się tempo. Człowiek szukający sposobu na uzyskanie dostępu do systemu w końcu się znudzi, zostanie przyłapany albo się podda. Agent nie. Teraz odkrywa się wcześniej niezauważone otwarte drzwi, ponieważ agent się nie męczy i nie przestaje szukać.

I nie chodzi tylko o jedne drzwi. Agent zaprojektowany do wykonania jednego zadania bez wahania uzyska dostęp do kilkunastu systemów, zanim je ukończy — tu pobierze historię konta, tam sprawdzi bazę danych — choć większość tych działań nie ma nic wspólnego z tym, o co go poproszono. Przygotowując jedną prezentację, może natknąć się na dane innego klienta, dokumentację finansową, informacje o pracownikach czy cokolwiek innego, co stanie mu na drodze. Nic z tego nie zostaje odnotowane jako incydent.

Model zagrożeń uległ więc zmianie. Zespoły ds. bezpieczeństwa powinny dziś pytać, jak daleko posuną się ich własne agenty, by wykonać zadanie, jeśli nikt nie wyznaczy im granic.

Wiele organizacji ma już wdrożone systemy zarządzania tożsamością i dostępem, zarządzania dostępem uprzywilejowanym oraz architektury zero trust. Dlaczego te mechanizmy same w sobie nie wystarczają do zarządzania autonomicznymi agentami AI?

Te ramy stworzono z myślą o ludziach i dostawcach — czyli o podmiotach zdolnych do oceny sytuacji i zatrzymujących się, gdy napotkają przeszkodę. Tożsamość agentów wymaga takiego samego rygoru, jaki stosuje się wobec ludzi i w zarządzaniu ryzykiem związanym z podmiotami zewnętrznymi: wykrywania, określenia właściciela oraz dowodów, które audytor może uznać za wiarygodne. Problem polega na tym, że nie ma jeszcze wspólnego standardu określającego, co tak naprawdę oznacza „objęty nadzorem”, gdy poświadczeniem dysponuje agent.

Agent utworzony na przykład przez jednego z inżynierów może działać z uprawnieniami tego inżyniera — nawet w systemach, z których sam inżynier nigdy nie korzysta. Systemy IAM i PAM zakładają, że podmiot dysponujący poświadczeniem wie, kiedy się zatrzymać, ale agenci nie mają takiego założenia wbudowanego.

Czy przedsiębiorstwa powinny zacząć traktować każdego agenta AI jako odrębną tożsamość maszynową, z jasno określonym właścicielem, uprawnieniami, zakresem działania i cyklem życia? Jak powinny wyglądać dojrzałe ramy zarządzania tożsamością agentów?

Tak, ale większość przedsiębiorstw jeszcze do tego nie doszła. Więcej firm, niż można by się spodziewać, nie potrafi nawet powiedzieć, ilu agentów działa w ich środowisku, nie mówiąc już o tym, kto odpowiada za każdego z nich. Dojrzałe ramy zaczynają się od wykrywania — od rzetelnego, stale aktualizowanego wykazu wszystkich agentów. Następnie każdy agent musi mieć właściciela, jasno określony zakres tego, do czego może uzyskać dostęp, oraz zasady, które rzeczywiście egzekwują te ograniczenia. Z naszych własnych badań wynika, że po stronie dostawców obserwujemy ten sam problem — trzy na cztery organizacje ponownie oceniają podmioty zewnętrzne najwyżej raz w roku, więc opierają zarządzanie na danych, które są już nieaktualne, zanim cokolwiek się zmieni. Oceny przeprowadzane w pojedynczym momencie nie sprawdzają się w przypadku agentów, niezależnie od tego, czy działają wewnętrznie, czy na zewnątrz.

Chcemy ustanowić jeden standard, któremu podlegałby każdy agent, zamiast zmuszać zespoły bezpieczeństwa do ustalania, co samodzielnie stworzył każdy programista. Oznacza to zasady, które można zapisać prostym językiem, przetestować na rzeczywistym historycznym ruchu, zanim zostaną włączone, a następnie egzekwować bezpośrednio w toku działania, tak aby ramy obejmowały każdą czynność agenta, zamiast pozostawać jedynie w dokumentacji.

Szczególnie trudnym przypadkiem jest agent, który narusza zasady bezpieczeństwa, choć nie działa złośliwie. Jeśli agent odkryje niezamierzoną drogę do poufnych danych tylko dlatego, że próbuje wykonać powierzone mu zadanie, jak zespoły ds. bezpieczeństwa mogą odróżnić skuteczną automatyzację od incydentu bezpieczeństwa?

Szczerze mówiąc, na ten moment nie da się tego zrobić. Wyobraźmy sobie agenta wsparcia zaprojektowanego do przygotowywania projektów kwartalnych przeglądów biznesowych, któremu polecono pobrać historię konta i przygotować prezentację. Prawidłowa ścieżka — eksport, z którego agent ma pobrać dane — okazuje się pusta. Człowiek by się w tym miejscu zatrzymał, ale agent znajduje inną drogę i z jego perspektywy zadanie kończy się sukcesem.

Zadanie wprawdzie zostało wykonane, ale agent ominął przy tym protokoły bezpieczeństwa i uzyskał dostęp do systemów, których nie powinien otwierać. Kluczowe pytanie brzmi, czy agent pozostał w wyznaczonym mu zakresie działania. Samo wykonanie zadania nigdy nie było tu istotą problemu. To kwestia zasad. Trzeba określić zakres działania na tyle precyzyjnie, by po fakcie „skuteczna automatyzacja” i „incydent bezpieczeństwa” nie wyglądały identycznie.

Tradycyjne monitorowanie bezpieczeństwa często wykrywa podejrzaną aktywność dopiero po jej wystąpieniu, ale autonomiczny agent może wykonać setki czynności, zanim człowiek zdąży zareagować. Czy agentowa AI wymaga mechanizmów bezpieczeństwa działających bezpośrednio w ścieżce wykonywania zadań, zamiast polegać przede wszystkim na alertach i analizie zdarzeń po fakcie?

Tak, bez dwóch zdań. Jeśli wykrywasz problem dopiero w trakcie działania, jest już za późno. Zanim narzędzie monitorujące oznaczy daną czynność, zostanie ona już wykonana. Będziesz mieć doskonały zapis tego, jak dokładnie doszło do narażenia, ale nie będzie już można temu zapobiec.

Jedyny sposób zarządzania, który sprawdza się w przypadku czegoś działającego z maszynową prędkością, polega na ocenie czynności przed jej wykonaniem i zablokowaniu naruszenia bezpośrednio w toku działania. Nigdy nie powierzylibyśmy naszych najbardziej poufnych danych nowemu pracownikowi, licząc po prostu na to, że monitoring wychwyci ewentualne problemy. Agenci powinni podlegać takiemu samemu rygorowi — dokładnie w chwili, gdy czynność ma zostać wykonana. Nie po fakcie.

Model Context Protocol (MCP) i inne interfejsy łączące agentów z narzędziami zapewniają systemom AI dostęp do coraz potężniejszych funkcji zewnętrznych. Jakie nowe granice bezpieczeństwa należy ustanowić wokół wywołań narzędzi, interfejsów API, poświadczeń i kont usługowych, gdy przedsiębiorstwa rozszerzają zakres działań dozwolonych swoim agentom?

Wywołanie narzędzia to nowa granica bezpieczeństwa. Za każdym razem, gdy agent sięga po dane uwierzytelniające, wywołuje API lub korzysta z narzędzia, dochodzi do punktu decyzyjnego. Tymczasem większość przedsiębiorstw nie ma dziś zabezpieczenia działającego dokładnie w tym punkcie i oceniającego, czy dana czynność powinna zostać wykonana. Właśnie tego brakowało. Patrząc z zewnątrz do wewnątrz, dostrzegamy tę samą martwą strefę — zaledwie 37% osób odpowiedzialnych za bezpieczeństwo ma pewność, że potrafi choćby ustalić, gdzie działa sztuczna inteligencja w firmach, z których usług już korzystają. Jeśli nie widzisz tego w produkcie dostawcy, nie dostrzeżesz też kolejnego działania własnego agenta. Dane uwierzytelniające i konta usługowe, na których opiera się to wszystko, również wymagają tak samo rygorystycznego podejścia jak dostęp ludzi: jasno określonego właściciela, zdefiniowanego zakresu uprawnień i regularnych przeglądów. Agent nie powinien móc sięgnąć po dane uwierzytelniające, których mu nie przyznano, tylko dlatego, że gdzieś na jego ścieżce były dostępne.

Jakiego poziomu identyfikowalności działań organizacje powinny realnie móc zapewnić, gdy audytor, organ regulacyjny lub klient zapyta, do jakich zasobów uzyskał dostęp agent AI, jakie decyzje podjął i dokąd trafiły powstałe w ten sposób dane? Czy ścieżki audytowe agentów mogą z czasem stać się równie podstawowym elementem jak tradycyjne rejestry dostępu?

Organizacje powinny móc na żądanie odpowiedzieć, do jakich zasobów uzyskał dostęp agent, jakie decyzje podjął i dokąd trafiły powstałe w ten sposób dane. Nie wystarczy odtworzyć odpowiedzi na to pytanie, składając po fakcie informacje z logów. Standardem powinien być ciągły zapis, którego ewentualna modyfikacja jest wykrywalna i który istnieje już w chwili zadania pytania. Obecnie większość firm odpowiada na takie pytania milczeniem. Nie da się wytłumaczyć klientowi, że to tylko luka, a w zależności od tego, co wyciekło, organy regulacyjne również jej nie zaakceptują.

I tak, uważam, że ścieżki audytowe agentów wkrótce staną się równie podstawowe jak rejestry dostępu. Od lat traktujemy zasadę „kto, do czego i kiedy uzyskał dostęp” jako niepodlegający negocjacjom wymóg w systemach obsługujących ludzi. Nie ma powodu, by stawiać agentom niższe wymagania tylko dlatego, że to nie człowiek klikał. Takie ramy jak unijny akt w sprawie sztucznej inteligencji, AIUC-11 i ISO 42001 już wyznaczają ten kierunek. Identyfikowalność działań agentów musi opierać się na tych samych mechanizmach kontrolnych i zasadach gromadzenia dowodów, które już dziś stanowią podstawę programów zgodności. Traktowanie jej jako sprawy drugorzędnej prowadzi do jej marginalizacji.

Czy w przyszłości zarządzanie agentami AI stanie się odrębną kategorią bezpieczeństwa, czy też zostanie włączone do istniejących platform do zarządzania, zarządzania ryzykiem, zgodnością, tożsamością i cyberbezpieczeństwem? Jakie warunki, Pana zdaniem, przedsiębiorstwa będą musiały spełnić, zanim będą mogły bezpiecznie wdrażać w pełni autonomicznych agentów na dużą skalę?

Każda wielka fala technologiczna wywołuje własną falę rozwiązań z zakresu bezpieczeństwa — rozwój chmury przyniósł Wiz, a urządzeń końcowych — CrowdStrike. Teraz podobną falę wywołują agenci AI. Dostawcy modeli tworzą konsole i zasady dla własnych platform, co jest przydatne, ale żadna firma nie opiera się na jednym dostawcy modeli, jednym asystencie programistycznym i jednym zestawie agentów tworzonych wewnętrznie. Ktoś musi zarządzać tym wszystkim w oparciu o jeden zestaw zasad i jedno źródło dowodów, a żadna pojedyncza platforma AI nie została stworzona z myślą o rozwiązaniu tego problemu. Nie taki jest jej cel. Zarządzanie agentami AI stanowi już odrębną kategorię, choć integruje się z używanymi przez firmy systemami GRC, zarządzania tożsamością i zgodnością.

Zanim przedsiębiorstwa będą mogły wdrażać w pełni autonomicznych agentów na dużą skalę, muszą przygotować cztery elementy — a większość z nich nie ma jeszcze żadnego. Po pierwsze, potrzebują wykrywania w czasie rzeczywistym: muszą wiedzieć, który agent działa, kto jest za niego odpowiedzialny i z jakiej tożsamości korzysta, od chwili jego utworzenia.

Po drugie, potrzebne jest egzekwowanie zasad bezpośrednio w toku działania, z oceną przed wykonaniem czynności. Po trzecie, przedsiębiorstwa muszą stale monitorować odstępstwa, ponieważ agenci działają dłużej niż sesja, w której ich utworzono, a zakres ich uprawnień może po cichu się rozszerzać. I wreszcie potrzebny jest zapis każdej decyzji agenta, którego ewentualna modyfikacja jest wykrywalna i który można powiązać z ramami uznawanymi przez audytorów i organy regulacyjne. Właśnie taką warstwę tworzymy w Drata. Bez niej przedsiębiorstwo wdrażające autonomicznych agentów na dużą skalę po prostu liczy na szczęście.

Dziękuję za świetny wywiad. Czytelnicy, którzy chcą dowiedzieć się więcej o zarządzaniu agentami AI, ciągłym zapewnianiu zgodności i zabezpieczeniach przed zagrożeniami ze strony agentów działających wewnątrz organizacji, mogą odwiedzić Drata.