Agent AI ma dostęp do Twoich systemów. Czy wiesz, w czyim imieniu naprawdę działa?

Coraz więcej firm, także tych bez dedykowanego zespołu security, wdraża agentów AI do obsługi zgłoszeń HR, pisania i uruchamiania kodu czy kontaktu z klientami. Rzadko kto zadaje sobie przy tym pytanie, które okazuje się kluczowe: kim właściwie jest ten agent w systemie i w czyim imieniu w danej chwili działa. Standardy, na których dziś opiera się większość kontroli dostępu, po prostu nie mają na to dobrej odpowiedzi.

W małej i średniej firmie agent AI zwykle trafia do infrastruktury bocznym wejściem. Jako dodatek do systemu HR, integracja w helpdesku, asystent kodujący podłączony do repozytorium. Nikt nie traktuje go jak nowego pracownika, więc nikt nie zadaje sobie pytania, jakie uprawnienia faktycznie ma i czy da się je kontrolować równie precyzyjnie jak dostęp człowieka.

Tymczasem z punktu widzenia systemów autoryzacji agent AI jest bliżej pracownika niż zwykłej integracji API. Może działać w imieniu wielu użytkowników naraz, być uruchamiany i zamykany dynamicznie, wywoływać inne agenty do wykonania podzadań. I robić to wszystko bez człowieka w pętli decyzyjnej. To rodzi pytanie, na które klasyczne mechanizmy uwierzytelniania po prostu nie były projektowane.

Dostęp agentów AI do systemów opiera się dziś najczęściej na tokenach OAuth, czyli tym samym mechanizmie, który od lat autoryzuje aplikacje i użytkowników. Problem w tym, że standardowy format tokenu JWT, opisany w dokumencie RFC 9068, powstał z myślą o jednym podmiocie na raz: albo użytkowniku, albo aplikacji. Nie przewiduje pola na tożsamość konkretnej instancji agenta ani na opis relacji między agentem a osobą, w imieniu której ten agent działa.

W praktyce oznacza to, że system otrzymujący żądanie, czyli baza danych, API czy plik, często nie wie, kto naprawdę stoi za tym żądaniem. Bez tej informacji trudno wymusić precyzyjną kontrolę dostępu, zbudować sensowny ślad audytowy czy wykryć moment, w którym agent wychodzi poza swój zakres działania. W środowiskach, w których jeden agent obsługuje wielu różnych użytkowników, na przykład agent HR pracujący na wielu sprawach kadrowych naraz, brak tego rozróżnienia może prowadzić do tzw. problemu skonfundowanego zastępcy (confused deputy problem). Agent z ogólnymi uprawnieniami do danych płacowych powinien mieć dostęp wyłącznie do sprawy, którą aktualnie obsługuje, a nie do całej bazy.

Skalę problemu dobrze pokazują cztery sposoby, w jakie agent może działać. Agent interaktywny, przy którym człowiek jest obecny i może wyrazić zgodę na działanie. Agent działający offline, gdy człowiek zleca zadanie i znika z pętli aż do jego zakończenia. Agent w pełni zautomatyzowany, uruchamiany przez workflow albo działający ciągle na podstawie kolejki zadań. I agent tranzytywny, który deleguje pracę do kolejnego agenta. Im mniej człowieka w decyzji o działaniu, tym bardziej liczy się to, kim jest sam agent i jakie ma uprawnienia w danym momencie.

CrowdStrike odpowiada na ten problem koncepcją Continuous Identity, dostarczaną w ramach Falcon Next-Gen Identity Security. Zamiast modelu „zaloguj się raz, ufaj do wylogowania”, każda akcja agenta jest autoryzowana osobno i w czasie rzeczywistym, na podstawie tego, czym jest agent, kim jest stojący za nim człowiek oraz jaki jest aktualny kontekst bezpieczeństwa i biznesowy.

W praktyce mechanizm opiera się na kilku zasadach. Każdy agent powinien mieć weryfikowalną tożsamość opartą na standardzie SPIFFE. Każda akcja jest oceniana względem uprawnień zarówno człowieka, jak i samego agenta: ten sam agent z uprawnieniem do zapisu, działający w imieniu użytkownika z dostępem tylko do odczytu, może wyłącznie odczytywać dane. Nie ma stałych, „zawsze aktywnych” uprawnień, bo autoryzacja odbywa się w momencie działania, na podstawie aktualnych sygnałów ryzyka. Jeśli agent deleguje zadanie do innego agenta, tożsamość i uprawnienia człowieka są zachowywane w tym łańcuchu. A jeśli kontekst się zmieni, na przykład pojawi się nowa podatność albo zmieni się status zatrudnienia osoby, w imieniu której agent działa, dostęp jest natychmiast cofany.

To podejście CrowdStrike łączy z Falcon AI Detection and Response (AIDR), który analizuje treść promptów i intencje, wykrywając próby nadużycia uprawnień lub manipulacji modelem poza jego zamierzony zakres. W razie wykrycia takiej próby uruchamia mechanizm Continuous Identity, cofając dostęp, zanim dojdzie do szkody.

Warto przy tym zaznaczyć, że część opisanych tu zdolności CrowdStrike wprost określa jako będącą w toku wdrażania. To efekt trwającej integracji technologii SGNL, przejętej przez CrowdStrike w lutym 2026 roku, z platformą Falcon. Nie wszystko jest więc dziś dostępne w tej samej formie dla każdego klienta. To obszar aktywnie rozwijany, a nie zamknięty produkt.

Sygnały o ryzyku, czyli zmiana zachowania użytkownika, podejrzana aktywność na urządzeniu, wykryte zagrożenie, muszą trafiać między systemami różnych dostawców, żeby decyzja o dostępie mogła się realnie zmienić w czasie rzeczywistym. Dlatego CrowdStrike inwestuje w standardy branżowe: dołączył do OpenID Foundation jako Sustaining Corporate Member, czyli najwyższy poziom członkostwa, i wstąpił do IDPro, organizacji zrzeszającej praktyków identity security. Aktywnie uczestniczy też w grupach roboczych OpenID zajmujących się Shared Signals i AuthZen.

W praktyce oznacza to wsparcie dla standardów takich jak OpenID Shared Signals Framework (SSF) i Continuous Access Evaluation Profile (CAEP). To dzięki nim Falcon może przekazać sygnał o wykrytym zagrożeniu na urządzeniu bezpośrednio do dostawcy tożsamości lub systemu kontroli dostępu, bez czekania na kolejne logowanie użytkownika. CrowdStrike prowadzi też platformę caep.dev, gdzie deweloperzy mogą testować implementacje CAEP. Wśród firm wdrażających te same standardy CrowdStrike wymienia między innymi Apple, Google, IBM, Jamf, Okta i SailPoint.

Kierunek, w jakim to zmierza, dobrze pokazuje zapowiedziana integracja Falcon Next-Gen Identity Security z Zscaler Zero Trust Exchange. Mechanizm ma działać tak: wykrycie podejrzanej aktywności, na przykład próby brute-force, nietypowego wzorca logowania czy złośliwego wykonania kodu, uruchamia w Falcon regułę, która wysyła sygnał o podwyższonym ryzyku do silnika Adaptive Access Engine Zscalera. Ten automatycznie ogranicza dostęp użytkownika do wrażliwych zasobów albo wymusza dodatkowe uwierzytelnienie, bez udziału administratora. Gdy ryzyko maleje, dostęp jest przywracany w ten sam automatyczny sposób.

Tu ważne zastrzeżenie: CrowdStrike opisuje tę integrację jako zapowiedź funkcji, która dopiero się pojawi („coming soon”), a nie jako gotowy, ogólnie dostępny mechanizm. Decyzje zakupowe warto opierać na tym, co jest dostępne dziś, a nie na zapowiedziach.

Dla administratora bez rozbudowanego zespołu security najważniejszy wniosek jest taki: problem tożsamości agentów AI nie jest teoretyczny ani zarezerwowany dla korporacji z własnym SOC. Jeśli firma wdraża choćby jednego agenta AI z dostępem do danych klientów, kadr czy kodu, staje przed dokładnie tym samym pytaniem co duży bank. Kto naprawdę stoi za każdym żądaniem tego agenta.

Różnica polega na tym, że mniejsza firma zwykle nie ma zasobów, żeby budować własne rozszerzenia protokołu OAuth albo ręcznie korelować sygnały z różnych systemów. Podejście, w którym te mechanizmy (weryfikowalna tożsamość agenta, brak stałych uprawnień, autoryzacja w czasie rzeczywistym) są częścią samej platformy bezpieczeństwa, a nie projektem do zbudowania od zera, ma dla takiej firmy większe znaczenie niż dla organizacji, która i tak zatrudnia zespół identity engineerów.

Tożsamość agentów AI to dziś jeden z najszybciej zmieniających się obszarów bezpieczeństwa, także dlatego, że standardy branżowe, takie jak OAuth, wciąż go doganiają. Jeśli planujecie wdrożenie agentów AI w swojej organizacji i chcecie sprawdzić, jak to wygląda w praktyce na platformie Falcon, obejrzyjcie materiał z Akademii Cyberbezpieczeństwa Net Complex o ochronie tożsamości i wykrywaniu zagrożeń w Active Directory: zobacz film, albo porozmawiajcie z naszym specjalistą o wdrożeniu CrowdStrike dopasowanym do skali waszej firmy.