Bezpieczeństwo agentów AI: kontrola dostępu dla oprogramowania, które działa samodzielnie

dlaczego agenci to przede wszystkim problem dostępu

Adopcja jest już szeroka i w większości niekontrolowana. 79% organizacji wdrożyło albo testuje agentów AI produkcyjnie (PwC, 2025), a mimo to mniej niż połowa wdrożonych agentów jest aktywnie monitorowana albo zabezpieczona (Gravitee, 2026), a 47% liderów bezpieczeństwa widziało już, jak agent AI wykazuje niezamierzone albo nieautoryzowane zachowanie (2026 CISO AI Risk Report, Saviynt / Cybersecurity Insiders). Punktem wyjścia jest traktowanie agenta jako tożsamości, którą widzisz i którą zarządzasz, a nie jako oprogramowania działającego po cichu z delegowanym zasięgiem.

ryzyka specyficzne dla agentów

Zbyt szeroki delegowany dostęp: agent skonfigurowany z pełnymi danymi uwierzytelniającymi użytkownika dziedziczy wszystko, do czego ten użytkownik ma dostęp, znacznie szerzej niż wymaga tego zadanie, do którego został zbudowany, a zakres jest nadawany raz i rzadko zawężany. Stały, bezobsługowy dostęp: w odróżnieniu od człowieka agent może działać nieprzerwanie z prędkością maszyny, więc dostęp, który byłby do opanowania dla człowieka klikającego w interfejsie, jest większym ryzykiem dla oprogramowania działającego tysiące razy na godzinę. Prompt injection obracający agenta przeciwko tobie: agent czytający zewnętrzną treść, e-mail, stronę internetową, dokument, zgłoszenie, może natrafić na ukryte w niej instrukcje, a jeśli zacznie działać zgodnie z nimi, atakujący, który potrafi podrzucić tekst przed agenta, może potencjalnie przekierować jego działania. To ryzyko bez czystego odpowiednika w tradycyjnym oprogramowaniu, i OWASP stawia je na pierwszym miejscu wśród ryzyk dla dużych modeli językowych (LLM01). Brak audit trail: wiele konfiguracji agentów nie zapisuje, co agent zrobił, z czyjego upoważnienia i w jakich systemach, więc rekonstrukcja zdarzeń to zgadywanie. Rozrost agentów: zespoły uruchamiają agentów tak samo, jak wcześniej wdrażały shadow SaaS, szybko i poza jakąkolwiek inwentaryzacją, zostawiając agentów z dostępem, którego nikt nie skatalogował.

kontrole dostępu, które się liczą

To trwałe kontrole, które działają niezależnie od tego, jakiej platformy czy modelu używasz. Daj agentowi własną tożsamość zamiast uruchamiać go na pełnych danych uwierzytelniających człowieka, żeby jego dostęp odzwierciedlał zadanie i dało się go niezależnie wydzielać, monitorować i odwoływać. Egzekwuj least privilege bezwzględnie: nadawaj najwęższy dostęp, jakiego zadanie faktycznie wymaga, read-only tam, gdzie praca na to pozwala, i konkretny zestaw systemów zamiast wszystkiego, bo blast radius agenta z nadmiernymi uprawnieniami jest większy. Wprowadź human-in-the-loop dla działań o wysokim wpływie: czytanie i tworzenie szkiców może działać autonomicznie, ale działania, które przenoszą pieniądze, usuwają dane, zmieniają dostęp albo wysyłają komunikację na zewnątrz, powinny wymagać zgody człowieka, a to, które działania przekraczają tę granicę, ustalasz przed wdrożeniem, nie po incydencie. Ogranicz, na czym agent może działać, zawężając go do zdefiniowanych narzędzi i systemów zamiast otwartych możliwości. Traktuj zewnętrzną treść jako niezaufaną, zakładając, że każda treść, którą agent pobiera, może nieść instrukcje, i trzymaj potężne działania za bramkami opisanych wyżej kontroli. Loguj wszystko, co agent robi: działania, systemy, których dotknął, i upoważnienie, z jakiego korzystał, żebyś miał audit trail i mógł wychwycić anomalne zachowanie. I inwentaryzuj swoich agentów oraz ich offboarduj: prowadź listę działających agentów, każdy z właścicielem i celem, i wycofuj ich z eksploatacji, odwołując tożsamość i dostęp, kiedy praca się kończy. Agenci potrzebują kroku leaver tak samo jak każda inna tożsamość.

standardy, z którymi warto się zestroić

Ten obszar ma już realne punkty odniesienia. OWASP Top 10 for LLM Applications (2025) to standardowa taksonomia ryzyka na poziomie modelu, z prompt injection na pierwszym miejscu (LLM01) i excessive agency (LLM06) jako pozycją specyficzną dla agentów: agent, który dostał więcej możliwości, niż wymaga tego jego zadanie. OWASP Top 10 for Agentic Applications (2026) skupia się na agentach, które planują, używają narzędzi i utrzymują pamięć, z czołowymi ryzykami agent goal hijack (ASI01) i memory poisoning (ASI06). Wspólne wytyczne Five Eyes, „Careful Adoption of Agentic AI" (2026), od CISA, NSA i partnerów z Wielkiej Brytanii, Kanady, Australii i Nowej Zelandii, są zorganizowane wokół ryzyk uprawnień, konfiguracji, zachowania, struktury i rozliczalności, i stanowią praktyczny punkt wyjścia. CSA Agentic Trust Framework (2026) to model zarządzania zero trust dla podmiotów maszynowych, z drogą dojrzałości, która awansuje agenta z roli read-only do autonomicznego działania dopiero po przejściu zdefiniowanych bramek. NIST zaczął standaryzować tożsamość i autoryzację agentów przez swoją inicjatywę CAISI i koncepcyjny dokument NCCoE. Nie musisz wdrażać wszystkich naraz: zbiegają się w tych samych kontrolach dostępu, które opisuje ten przewodnik: wydzielona tożsamość, least privilege, human-in-the-loop i monitoring.

gdzie to się styka z compliance

Jeśli wdrażasz AI, unijny AI Act oczekuje, że będziesz wiedzieć, jakie systemy AI działają u ciebie, i że będziesz prowadzić określone logi, a agenci są w tym zakresie wprost objęci. Dyscyplina dostępu opisana tutaj, znana inwentaryzacja, wydzielony dostęp, logowanie, to ten sam szkielet, jakiego wymagają NIS2, DORA i RODO, zastosowany do nowego rodzaju tożsamości. Poprawne ustawienie kontroli dostępu to w praktyce większość tego, czym operacyjnie jest zarządzanie twoją AI.