Bezpieczeństwo agentów AI: mają już klucze - pytanie, które drzwi mogą otworzyć
Bezpieczeństwo agentów AI stało się problemem, który większość organizacji odkrywa za późno. Nikt nie podjął decyzji o ich wdrożeniu - pewnego dnia po prostu podniesiono głowę i agenci już tam byli.
Deweloper zainstalował asystenta AI do kodowania trzy miesiące temu. Działa z jego credentials. Ma dostęp do każdego pliku, do którego ma dostęp on sam. Zespół operacyjny zautomatyzował raportowanie za pomocą narzędzia AI. Nikt nie ograniczył jego dostępu względem wartości domyślnych. Dostawca dołączył asystenta AI do platformy SaaS, którą odnowiłeś w zeszłym kwartale. Działa od dnia podpisania umowy.
To nie jest błąd w zabezpieczeniach. Tak działa adopcja. Pytanie nie brzmi, jak to cofnąć - ten okręt już odpłynął. Pytanie brzmi, do czego te agenty faktycznie mają dostęp i czy ktokolwiek to wie.
Dlaczego oczywiste rozwiązanie nie działa
Gdy zespoły bezpieczeństwa spotykają nową technologię, instynkt podpowiada: otocz ją kontrolami. Sprawdzaj, co wchodzi. Monitoruj, co wychodzi. Dla przewidywalnych systemów to działa.
Agenci AI nie są przewidywalnymi systemami.
Przestrzeń wejściowa dużego modelu językowego jest praktycznie nieograniczona - każda kombinacja słów, kontekstu i instrukcji. To samo dotyczy wyjścia. Nie istnieje żaden skończony zestaw reguł, który wychwytuje każde szkodliwe wejście lub każde szkodliwe wyjście. Badacze bezpieczeństwa wykazali, że ponad 80% ataków na zabezpieczenia na poziomie modelu kończy się sukcesem. Model nie jest w stanie sam się skutecznie chronić.
To nie jest błąd, który zostanie naprawiony łatką. To właściwość strukturalna sposobu, w jaki te systemy działają. Kontrolowanie wejść i wyjść to całkowicie błędne podejście.
Problem z tożsamością, którego nikt jeszcze nie rozwiązał
Od dekad zarządzanie tożsamością i dostępem (IAM) było budowane wokół dwóch typów podmiotów.
Pierwszy to człowiek - osoba z rolą, działem, przełożonym. Drugi to workload - skrypt lub usługa wykonująca jedną zdefiniowaną czynność w przewidywalny sposób.
Agenci AI nie pasują do żadnej z tych kategorii.
Działają z prędkością maszyny - pracują w nocy, uruchamiają pod-agentów, wykonują tysiące działań bez człowieka w pętli. Ale rozumują jak ludzie - interpretują niejednoznaczne instrukcje, podejmują decyzje w sytuacjach niestandardowych, adaptują się gdy coś idzie nie tak. Workload nigdy tego nie robi.
Efektem jest luka w zarządzaniu, której większość organizacji jeszcze nie zamknęła. Gdy deweloper konfiguruje agenta AI na swoim komputerze, agent typowo dziedziczy jego credentials. Ma dostęp do wszystkiego, do czego ma dostęp deweloper. blast radius problemu - czy to naruszenia, czy po prostu błędnej interpretacji zadania przez agenta - to pełna powierzchnia tożsamości tego dewelopera.
Przeskaluj to. Firma zatrudniająca 500 osób, która wdraża AI we wszystkich zespołach, może w ciągu kilku miesięcy obsługiwać 1500 agentów. Średnio trzy na pracownika. Wiele z tych agentów zostało skonfigurowanych z szerokim dostępem, bo tak było wygodniej. Nikt nie zapytał, czy agent przygotowujący oferty dla zespołu sprzedaży naprawdę potrzebuje możliwości usuwania rekordów z CRM. Nie potrzebuje. Ale nikt też nie ograniczył mu uprawnień.
Luka między tym, do czego agent służy, a tym, co może zrobić
Każdy agent ma cel - powód, dla którego został stworzony, zadanie, które mu powierzono. Agent obsługi klienta ma wąsko zdefiniowane przeznaczenie. Agent IT helpdesk ma inne. Agent audytu bezpieczeństwa - jeszcze inne.
Problem w tym, że cel i uprawnienia prawie nigdy nie są ze sobą zgodne.
Agenci otrzymują szeroki dostęp, bo tak jest łatwiej ich skonfigurować. Cel pozostaje wąski. Uprawnienia pozostają szerokie. Wszystko pomiędzy to ekspozycja, którą nikt nie zarządza.
Ido Shlomo, współzałożyciel i CTO Token Security - finalisty top-10 RSA Innovation Sandbox 2026 - ujmuje to bezpośrednio: organizacje zawodzą na etapie łączenia strategii AI z zarządzaniem tożsamością i dostępem. Narzędzia istnieją po obu stronach. Brakuje mostu między nimi.
Zamknięcie tej luki zaczyna się od zdolności do odpowiedzi na cztery pytania: który agent użył których credentials, w którym systemie, uzyskując dostęp do jakich danych i w czyim imieniu. Bez tej widoczności nie możesz zarządzać tym, czego nie widzisz.
Co faktycznie zrobić
Punktem wyjścia nie jest dokument polityki. To ćwiczenie inwentaryzacyjne.
Zanim zaczniesz zarządzać agentami, musisz wiedzieć, co działa. To oznacza centralny rejestr - nie tylko agentów zatwierdzonych przez organizację, ale też tych na maszynach deweloperów, tych uruchomionych po cichu przez zespoły operacyjne, tych dołączonych do narzędzi, z których już korzystasz.
Dalsze podejście naśladuje logikę zarządzania cyklem życia tożsamości ludzkiej:
Konfiguracja oparta na celu. Czego ten agent faktycznie potrzebuje, żeby wykonać swoje zadanie? Zacznij od tego. Nie od tego, co jest technicznie dostępne, nie od wartości domyślnych administratora. Ogranicz dostęp do zadania.
Bieżące monitorowanie. Agenci odchylają się od pierwotnego przeznaczenia. Dostęp przyznany przy konfiguracji rzadko zmniejsza się wraz z ewolucją zadania. Regularne sprawdzanie, co agenty faktycznie robią - w porównaniu z tym, do czego zostały zbudowane - wychwytuje problemy zanim staną się incydentami.
Identyfikacja działań poza zakresem. Część agentów zawsze będzie działać poza zamierzonym zakresem. Zdolność do szybkiego ich identyfikowania jest operacyjnym odpowiednikiem wykrywania anomalii dla tożsamości ludzkich.
Wycofywanie nieaktywnych agentów. Agent zbudowany dla projektu, który zakończył się sześć miesięcy temu, nadal działający z ważnymi credentials i bez właściciela, to otwarta powierzchnia ataku. Proces wycofania musi być tak przemyślany jak proces konfiguracji.
Podstawowa zasada jest dobrze znana specjalistom bezpieczeństwa z Zero Trust. Dostęp nie powinien być przyznawany dla wygody. Powinien być ograniczony do niezbędnego minimum, weryfikowany na bieżąco i odbierany gdy nie jest już potrzebny. Ta sama logika dotyczy agentów.
Organizacje, które poradzą sobie z tym dobrze, nie będą tymi, które najbardziej starały się spowolnić adopcję. Będą to te, które zaakceptowały agentów jako stały element swojego środowiska i zbudowały warstwę zarządzania wcześnie - zaczynając od widoczności, egzekwując least privilege oparte na celu i traktując tożsamość agentów z taką samą starannością jak tożsamość ludzką.
Klucze są już rozdane. Pytanie, czy wiesz, które drzwi każdy z nich otwiera.
Tożsamość agentów to jeden wymiar wyzwania. Widoczność środowiska AI, shadow tooling i zarządzanie na poziomie organizacji omawia AI governance w praktyce.
Najczęstsze pytania
Dlaczego kontrole wejść i wyjść nie zabezpieczają AI agents?
Przestrzeń wejściowa dużego modelu językowego jest praktycznie nieograniczona - dowolna kombinacja słów, kontekstu i instrukcji. To samo dotyczy wyjść. Nie istnieje skończony zbiór reguł obejmujący wszystkie szkodliwe dane wejściowe lub wyjściowe, a badacze bezpieczeństwa wykazali, że ponad 80% ataków na zabezpieczenia na poziomie modelu kończy się sukcesem. To nie jest podatność do załatania - to właściwość strukturalna tych systemów. Kontrolowanie wejść i wyjść to błędne podejście.
Dlaczego AI agents tworzą problem z zarządzaniem tożsamością i dostępem?
AI agents nie pasują do żadnej z dwóch kategorii, wokół których zbudowano tradycyjne IAM - człowieka z rolą i działem, oraz workloadu wykonującego jedno zdefiniowane zadanie w przewidywalny sposób. Agenci działają z prędkością maszyny, ale rozumują jak ludzie - interpretują niejednoznaczne instrukcje i adaptują się do nieoczekiwanych sytuacji. Provisioning z szerokim dostępem dla wygody sprawia, że jeden agent może odziedziczyć pełną powierzchnię credentials dewelopera lub zespołu. Firma z 500 pracownikami może znaleźć się z 1500 agentami w ciągu miesięcy, z których wiele ma dostęp znacznie przekraczający potrzeby zadania.
Od czego zacząć zarządzanie AI agents w organizacji?
Od wykrycia, a nie od polityki. Zanim można zarządzać agentami, trzeba wiedzieć, co działa - nie tylko agenci zatwierdzone przez organizację, ale także te na maszynach deweloperów, uruchomione po cichu przez zespoły operacyjne i wbudowane w narzędzia już używane. Dalej podejście przebiega jak lifecycle management tożsamości ludzkich: provisioning oparty na rzeczywistym zadaniu agenta, monitorowanie dryftu od pierwotnego przeznaczenia, identyfikacja agentów działających poza zamierzonym zakresem oraz wycofywanie nieaktywnych agentów z ważnymi credentials i bez aktywnego właściciela.