Kto pilnuje agentów? Tożsamość i bezpieczeństwo autonomicznych agentów AI w firmie

Przez ostatnie dwa lata w firmach wydarzyło się coś, czego mało kto zdążył przemyśleć do końca. Nauczyliśmy się budować agentów AI, ale nie nauczyliśmy się ich kontrolować. Powstały imponujące demonstracje, agent czyta skrzynkę, umawia spotkania, aktualizuje CRM, składa zamówienie, a na koniec sam raportuje, co zrobił. Zachwyt jest uzasadniony. Problem w tym, że pytanie „jak to zbudować" wyprzedziło pytanie „kto tego pilnuje" o dobre kilkanaście miesięcy.

W większości wdrożeń, które oglądamy, ryzykiem nie jest sam model. Model można wymienić, dostroić, ograniczyć promptem. Prawdziwe ryzyko siedzi gdzie indziej, w dostępie, jaki temu modelowi daliśmy. Agent, żeby był użyteczny, musi coś móc. A „coś móc" oznacza w praktyce token do poczty, klucz do bazy, grant do CRM, uprawnienie do repozytorium albo do bramki płatności. Wdrożyliśmy inteligencję i przy okazji, trochę mimochodem, rozdaliśmy klucze.

To nie jest tekst o tym, że agenty są niebezpieczne i lepiej ich nie tykać. Wręcz przeciwnie. To tekst o tym, że traktowaliśmy je jak skrypty, a one od dawna nie są skryptami. Skrypt robi dokładnie to, co napisano. Agent podejmuje decyzje, interpretuje polecenia i sięga po narzędzia w kolejności, której nikt wcześniej nie przewidział. Różnica jest ta sama, co między makrem w arkuszu a nowym pracownikiem, któremu daliśmy login do systemu i powiedzieliśmy „ogarnij temat".

Z perspektywy działu bezpieczeństwa agent AI nie jest ani „sztuczną inteligencją", ani „aplikacją". Jest tożsamością. Konkretnie tożsamością nieludzką, po angielsku non-human identity, w skrócie NHI. To zbiorcza nazwa na wszystko, co uwierzytelnia się w systemach firmy, a nie jest człowiekiem: konta serwisowe, tokeny, klucze API, granty OAuth, certyfikaty. Każdy wdrożony agent tworzy przynajmniej jedną taką tożsamość, a zwykle kilka, bo osobne poświadczenia potrzebuje sam agent i osobne każde narzędzie, po które sięga.

Ta zmiana perspektywy jest kluczowa, bo od razu ustawia właściwe pytania. Nie pytamy już „czy model halucynuje", tylko „do czego ta tożsamość ma dostęp, kto go nadał i kiedy wygasa". To dokładnie te same pytania, które zadajemy przy nowym pracowniku. Różnica jest taka, że pracownika zatrudniamy przez dział HR, z umową, zakresem obowiązków i procesem odejścia, a agenta bardzo często wdraża jeden zespół projektowy, po cichu, z kontem serwisowym stworzonym „na szybko, żeby działało".

I tu robi się niewygodnie. Bo to konto „na szybko" zwykle dostaje więcej uprawnień, niż faktycznie potrzebuje, jego klucz nie wygasa, a nazwa nie mówi nic o tym, czyj to agent i za co odpowiada. Gdyby to był człowiek, mielibyśmy jego akta. Agent takich akt najczęściej nie ma. Istnieje, ma dostęp, działa i nikt nie prowadzi jego historii zatrudnienia.

Jeszcze zanim agenty AI weszły do gry, w typowej firmie tożsamości maszynowych było wyraźnie więcej niż ludzkich. Raportowane proporcje bywają dramatyczne, mówi się o kilkudziesięciu tożsamościach nieludzkich na jedną ludzką. Składają się na to mikroserwisy, integracje, boty CI/CD, konta serwisowe, klucze do API partnerów. Każda z tych tożsamości to potencjalne drzwi, tyle że przez większość z nich nikt nie chodzi, więc łatwo o nich zapomnieć.

Agenty AI wywracają tę i tak już przechyloną proporcję jeszcze bardziej. Bo jeden agent to nie jedna tożsamość. To agent plus zestaw narzędzi, z których każde ma własne poświadczenia, a często jeszcze pomocnicze agenty wywoływane do podzadań. Wdrażamy „jednego asystenta", a w warstwie tożsamości powstaje ich pięć albo dziesięć. Pomnóżmy to przez liczbę działów, które w tym samym kwartale odkryły, że też chcą swojego agenta.

Problem nie jest arytmetyczny, tylko poznawczy. Człowiek zauważa, gdy do zespołu dołącza nowa osoba. Nikt nie zauważa, gdy w systemie przybywa dwunasta tożsamość serwisowa tego tygodnia. A skoro nie widzimy, że przybywają, to tym bardziej nie widzimy, gdy jedna z nich zaczyna zachowywać się nietypowo. Rośnie coś, czego nikt nie liczy, i to jest dokładnie ten rodzaj wzrostu, który lubią atakujący.

Zagrożenia wokół agentów rzadko są egzotyczne. To znane od lat błędy w nowej, groźniejszej odsłonie. Pierwszy i najczęstszy to nadmiar uprawnień. Agent do obsługi jednej skrzynki dostaje dostęp do całej poczty firmowej, bo tak było prościej skonfigurować. Dopóki działa poprawnie, nikt tego nie kwestionuje. Kłopot w tym, że jeśli ktoś przejmie nad nim kontrolę, przejmuje razem z nim cały ten nadmiarowy zasięg.

Drugi problem to poświadczenia, które nie wygasają. Statyczny klucz API czy token wpisany w konfigurację żyje miesiącami, a bywa, że latami. Wystarczy, że wycieknie raz, do logu, do repozytorium, do zrzutu pamięci, i atakujący ma trwały bilet wstępu. Do tego dochodzi współdzielenie jednej tożsamości przez wiele agentów. Jeśli pięć agentów loguje się na to samo konto serwisowe, to po incydencie nie da się odpowiedzieć na najprostsze pytanie audytu, który z nich wykonał daną akcję.

Najciekawsze, i najbardziej niepokojące, są zagrożenia typowe dla samej natury agentów. Prompt injection polega na tym, że atakujący umieszcza złośliwe polecenie tam, gdzie agent i tak zajrzy, w treści maila, na stronie, w dokumencie, a agent traktuje to jako instrukcję do wykonania. Powiązany z tym jest confused deputy, czyli „zdezorientowany zastępca". Agent z dużymi uprawnieniami wykonuje polecenie pochodzące z niezaufanego źródła, w dobrej wierze, bo nie odróżnia poleceń właściciela od tekstu, który akurat czyta. Sam nie ma złych intencji. Po prostu ma za dużo mocy i za mało nieufności.

Na to wszystko nakłada się brak logów decyzji. Kiedy agent zrobi coś nieoczekiwanego, zwykle nie potrafimy odtworzyć, dlaczego to zrobił. Nie wiadomo, jakie wejście dostał, jak je zinterpretował i które narzędzie odpalił w reakcji. Bez tej historii incydent zamienia się w zgadywankę, a wiosenne ostrzeżenie służb z kręgu Five Eyes o „ostrożnym wdrażaniu agentowego AI" to sygnał, że temat przestał być wyłącznie inżynierskim ćwiczeniem i trafił na biurka zarządów.

Najzdrowsza metafora, jaką znamy, jest prosta. Nadawajmy agentowi uprawnienia tak, jak nadalibyśmy je nowemu pracownikowi, który od pierwszego dnia ma dostęp do firmowej kasy. Nie jak skryptowi, któremu wpisujemy klucz i o nim zapominamy. Nikt rozsądny nie daje nowej osobie kluczy do wszystkich pomieszczeń, dostępu do wszystkich kont i pełnomocnictwa do przelewów „na wszelki wypadek". Dajemy dokładnie tyle, ile trzeba do zadania, i patrzymy, jak sobie radzi.

W praktyce oznacza to trzy rzeczy. Po pierwsze, zasada najmniejszego przywileju. Agent dostaje dostęp tylko do tych zasobów i akcji, których faktycznie wymaga jego zadanie, i nic ponadto. Agent czytający jedną skrzynkę nie potrzebuje uprawnień do kasowania kont ani do całej poczty firmy. To brzmi banalnie, a jest najczęściej łamaną zasadą we wdrożeniach, które oglądamy.

Po drugie, dostęp przyznawany just-in-time, czyli na czas zadania, a nie na stałe. Zamiast trzymać agenta w stanie ciągłego pełnomocnictwa, nadajemy mu uprawnienie w momencie, gdy zaczyna konkretne zadanie, i odbieramy je, gdy skończy. Pracownik idący do banku dostaje pełnomocnictwo na tę jedną sprawę, nie dożywotni dostęp do wszystkich rachunków. Po trzecie, własna tożsamość każdego agenta. Jeden agent, jedno rozpoznawalne konto, żadnego współdzielenia. Dzięki temu w każdej chwili wiadomo, kto jest kim i kto co zrobił, a odcięcie jednego agenta nie oznacza wyłączenia pięciu innych przy okazji.

Uprawnienia to jedna strona medalu. Druga to widoczność i możliwość interwencji. Nawet najlepiej nadany dostęp nic nie da, jeśli po incydencie nie potrafimy odtworzyć, co się stało, i nie umiemy szybko zamknąć agentowi drzwi. Dlatego audyt nie jest dodatkiem dla zgodności, tylko warunkiem, żeby w ogóle rozumieć, co dzieje się w naszym systemie.

Konkretnie potrzebujemy zapisu istotnych decyzji i akcji agenta. Nie chodzi o to, żeby logować każdy token, lecz o odtwarzalny ślad, jakie wejście agent dostał, jak je zinterpretował i którą akcję w reakcji wykonał. Gdy pojawia się pytanie „dlaczego agent wysłał ten mail" albo „dlaczego dopisał tę pozycję do zamówienia", ten ślad jest różnicą między spokojną analizą a bezradnym rozkładaniem rąk.

Do tego dochodzą krótkożyciowe poświadczenia. Zamiast statycznego klucza, który żyje w nieskończoność, agent dostaje token ważny minuty albo godziny, odnawiany na bieżąco. Wyciek takiego tokenu jest problemem na chwilę, a nie na rok. Między agentem a narzędziami warto postawić bramkę z regułami, taki punkt kontroli, który dla akcji wysokiego ryzyka, przelewu, usunięcia danych, wysyłki na zewnątrz, wymaga zatwierdzenia przez człowieka. To klasyczny human-in-the-loop, i nie jest oznaką braku zaufania do agenta, tylko normalnym progiem akceptacji, jaki i tak stosujemy wobec ludzi przy większych kwotach.

I rzecz, o której najłatwiej zapomnieć w euforii wdrożenia. Musimy umieć agenta natychmiast odciąć. Jeden przełącznik, który unieważnia jego tożsamość i poświadczenia, bez przekopywania się przez pięć systemów i szukania, gdzie właściwie wpisano ten klucz. Do tego prosta higiena myślenia, każdy prompt i każde wejście z zewnątrz traktujemy jak niezaufane. Agent nie powinien ufać treści maila bardziej niż my ufamy nieznajomemu, który podchodzi na ulicy i mówi, że jest z serwisu.

Większość firm jest dziś w tym samym miejscu, mają jednego, dwóch agentów w pilotażu i poczucie, że „na razie to nic groźnego". To akurat najlepszy moment, żeby ustawić zasady, bo przy jednym agencie są one tanie, a przy trzydziestu stają się kosztownym porządkowaniem chaosu. Pytanie nie brzmi, czy agentów będzie więcej, tylko jak szybko, i czy zdążymy przed nimi z regułami gry.

Praktyczny start jest mniej dramatyczny, niż się wydaje. Warto zacząć od spisu, ilu agentów faktycznie działa i jakie tożsamości oraz uprawnienia już im nadaliśmy, bo zwykle jest ich więcej, niż ktokolwiek pamięta. Potem przejść przez te uprawnienia i przyciąć je do faktycznych potrzeb, rozdzielić współdzielone konta, tak by każdy agent miał swoje, i pozamieniać wieczne klucze na poświadczenia, które wygasają. Na końcu włączyć audyt istotnych akcji i sprawdzić najprostszą rzecz, czy naprawdę potrafimy odciąć dowolnego agenta w minutę.

To nie jest praca na jeden sprint i nie trzeba jej robić całej naraz. Chodzi o kierunek, w którym agent przestaje być tajemniczym skryptem z pełnią władzy, a staje się rozliczalnym uczestnikiem systemu, z własną tożsamością, ograniczonym dostępem i historią działań. W aveneo patrzymy na wdrożenia agentów właśnie z tej strony, projektując je od początku z myślą o tożsamości, uprawnieniach i audycie, bo najtrudniej dokłada się kontrolę do czegoś, co już od pół roku działa bez niej. Jeden wdrożony bez tego agent to jeden nowy wektor włamania. Ten sam agent, wdrożony z głową, to po prostu dobrze zatrudniony pracownik.