Od inteligencji do uprawnień

Sztuczna inteligencja wykracza poza odpowiadanie na pytania i generowanie treści. Coraz częściej systemy AI potrafią interpretować instrukcje, opracowywać plany, wybierać narzędzia i wykonywać zadania bez stałego nadzoru człowieka.

Ta różnica ma znaczenie.

System AI, który rekomenduje działanie, różni się od systemu uprawnionego do jego wykonania. Różnica niekoniecznie dotyczy inteligencji ani stopnia zaawansowania. Chodzi o uprawnienia.

Systemy autonomiczne to nie tylko najbardziej zaawansowane wielkie modele językowe. Należą do nich także wyspecjalizowane systemy uczenia maszynowego, robotyka, pojazdy autonomiczne, agenci programowi oraz połączenia różnych technologii, które samodzielnie podejmują decyzje lub wykonują działania w określonych warunkach operacyjnych.

Ich potencjalne korzyści są znaczne. Mogą wspierać odkrycia naukowe, działalność przemysłową, opiekę zdrowotną, tworzenie oprogramowania i cyberbezpieczeństwo. Mogą też prowadzić do niezamierzonych skutków, ujawniać wrażliwe informacje lub podejmować działania wykraczające poza intencje ich operatorów.

W publikacji Wyzwania związane z bezpieczeństwem w projektowaniu systemów autonomicznych Mohammad Hamad i Sebastian Steinhorst analizują wyzwania dotyczące bezpieczeństwa, w tym autonomiczne reagowanie na incydenty, ocenę ryzyka, kontrolę dostępu, wiarygodność danych oraz interakcje między systemami autonomicznymi. Ich badania, z których znaczna część dotyczy systemów cyberfizycznych, pokazują, że wyzwania związane z zabezpieczaniem samodzielnych działań maszyn wykraczają poza dzisiejszych agentów LLM.

Szersze konsekwencje autonomii wymagają poważnej analizy, w tym potencjalnego ryzyka szkód fizycznych. Dowody należy jednak interpretować ostrożnie. Incydentów z udziałem pojazdów zautomatyzowanych nie można na przykład automatycznie przypisywać tym samym mechanizmom, które dotyczą autonomicznych agentów cyberbezpieczeństwa. Znaczenie mają stopień autonomii, warunki działania, udział człowieka oraz dowody dotyczące przyczyn zdarzenia.

Podobnie dowody na to, że autonomiczna AI może wyrządzać szkody, nie przesądzają o tym, że mechanizmy zarządzania koniecznie nie nadążają. Nie należy też zakładać, że systemy autonomiczne są z natury trudne do zabezpieczenia.

Kluczowe pytanie nie brzmi, czy AI potrafi wykonywać złożone zadania, lecz czy ramy architektoniczne, bezpieczeństwa i organizacyjne, które regulują działanie systemów autonomicznych, mogą wyznaczyć odpowiednie granice delegowanych uprawnień i dostarczyć możliwych do zweryfikowania dowodów na to, że granice te są respektowane.

Cyberbezpieczeństwo daje szczególnie użyteczną perspektywę do analizy tego zagadnienia, ponieważ specjaliści ds. bezpieczeństwa od dziesięcioleci podważają założenia dotyczące zaufania, uprawnień, dostępu i zachowania systemów.

Gra w kotka i myszkę w tempie maszynowym

Cyberbezpieczeństwo od dawna opisuje się jako grę w kotka i myszkę.

Atakujący odkrywają słabe punkty, obrońcy wprowadzają zabezpieczenia, a obie strony dostosowują swoje działania. Cykl trwa, gdy zmieniają się technologie, taktyki i środowiska operacyjne.

Autonomiczna AI niekoniecznie zmienia podstawowe zasady tej gry. Może jednak zmienić to, kto — lub co — bierze w niej udział, jak szybko działa i jak wiele zadań można realizować bez stałej interwencji człowieka.

Autonomiczny system bezpieczeństwa ofensywnego mógłby wykrywać usługi dostępne z zewnątrz, badać luki w zabezpieczeniach, opracowywać potencjalne ścieżki ataku i sprawdzać, czy można je wykorzystać. System obronny mógłby wykorzystywać podobne możliwości do badania zagrożeń, wykrywania słabych punktów i weryfikowania skuteczności działań naprawczych.

Ten potencjał podwójnego zastosowania ma kluczowe znaczenie dla zrozumienia konsekwencji autonomicznej AI dla bezpieczeństwa.

Project Glasswing firmy Anthropic stanowi przykład wspomaganego przez AI wykrywania luk w zabezpieczeniach. W aktualizacji wyników badań z maja 2026 r. Anthropic poinformowała o znaczących rezultatach w wykrywaniu luk, podkreślając jednocześnie operacyjne wyzwania związane z ich weryfikacją, ujawnianiem i usuwaniem.

Ta różnica ma znaczenie. Wykrycie luki w zabezpieczeniach nie jest równoznaczne z potwierdzeniem, że można ją wykorzystać, usunięciem jej ani wykazaniem, że podatny system jest bezpieczny.

Większa liczba wykrytych problemów może poprawić widoczność zagrożeń, a zarazem zwiększyć obciążenie osób i procesów odpowiedzialnych za ich rozwiązywanie.

O wyniku w zakresie bezpieczeństwa decyduje to, co stanie się później.

Jeśli atakujący i obrońcy mogą zautomatyzować część swojej pracy, istotne pytanie nie brzmi po prostu, która ze stron dysponuje najpotężniejszym modelem. Chodzi o to, czy obrońcy potrafią przekuć wykryte problemy w skuteczne działania naprawcze i niezależnie zweryfikować ich wyniki.

Testy penetracyjne nie tracą na znaczeniu tylko dlatego, że AI potrafi wykonywać zadania ofensywne. Ich zakres musi zostać rozszerzony tak, aby obejmował systemy interpretujące instrukcje, korzystające z narzędzi, łączące uprawnienia i realizujące cele w wielu etapach.

Cel pozostaje ten sam: znaleźć słabe punkty, określić ich znaczenie, usunąć je i udowodnić, że zabezpieczenia działają.

Styki architektoniczne: miejsca spotkania granic bezpieczeństwa

Jedno z bardziej subtelnych zagrożeń w systemach autonomicznych pojawia się wtedy, gdy komponenty, z których każdy ma osobne uprawnienia, wchodzą ze sobą w interakcje prowadzące do niezamierzonych skutków.

Takie punkty interakcji nazywam szwami architektonicznymi.

Rozważmy typowy przykład. Organizacja ogranicza dostęp do pliku za pomocą uprawnień NTFS. Odrębna usługa udostępniania w chmurze pozwala uprawnionemu użytkownikowi udostępnić te informacje na zewnątrz.

Każdy z tych systemów może działać zgodnie z własnymi regułami. Ich interakcja może jednak doprowadzić do udostępnienia informacji w sposób naruszający zamierzoną granicę bezpieczeństwa organizacji.

To przykład potencjalnie sprzecznych polityk, a nie twierdzenie, że którykolwiek produkt do udostępniania plików jest podatny na ataki.

Problemem nie musi być wada któregokolwiek z zabezpieczeń rozpatrywanych osobno. Może nim być brak egzekwowania zamierzonej polityki bezpieczeństwa w całym przepływie pracy.

Podobne sytuacje mogą występować w autonomicznych systemach AI, gdy łączą one modele, aplikacje, tożsamości, narzędzia, repozytoria i usługi zewnętrzne.

Agent może mieć uprawnienia do odczytu dokumentu, utworzenia repozytorium i przesłania plików. Nie oznacza to jednak, że ma uprawnienia do łączenia tych działań w sposób ujawniający informacje poufne.

Badania dostarczają praktycznego powodu, by przyjrzeć się tym interakcjom.

W AgentDojo badacze oceniali ataki typu prompt injection na agentów AI korzystających z narzędzi. Analiza objęła 97 realistycznych zadań i 629 przypadków testów bezpieczeństwa. Wyniki wykazały, że złośliwe instrukcje wprowadzane za pośrednictwem niezaufanych danych wyjściowych narzędzi mogły naruszyć niektóre właściwości bezpieczeństwa, choć skuteczność ataków i agentów nie była jednakowa we wszystkich przypadkach.

Badanie nie ustala, jak często takie ataki kończą się powodzeniem w środowiskach produkcyjnych. Pokazuje jednak, dlaczego sama ocena odpowiedzi modelu nie wystarcza do zrozumienia zachowania systemu połączonego z narzędziami.

Powiązane zagrożenie bywa określane jako pranie uprawnień: działanie wydaje się uzasadnione, ponieważ odbywa się za pośrednictwem uprawnionego narzędzia lub pośrednika, mimo że połączone działania naruszają zamierzoną granicę uprawnień.

Gdy współpracuje ze sobą wielu agentów, relacje te wymagają jednoznacznych reguł określających udział, wymianę informacji i dozwolone działania.

Należy też przypisać odpowiedzialność w całej architekturze.

Dostawcy modeli, operatorzy platform, twórcy agentów i organizacje wdrażające systemy mogą kontrolować różne ich elementy. Przydatny model współodpowiedzialności wskazuje, kto kontroluje poszczególne granice, kto może zatwierdzać wyjątki, kto monitoruje wykonanie działań i kto reaguje, gdy coś pójdzie nie tak.

Autonomia nie znosi odpowiedzialności. Zwiększa znaczenie wiedzy o tym, na kim ona spoczywa.

Rygor ofensywny: sprawdzanie tego, co wydaje nam się wiadome

Prowadzi nas to do koncepcji, którą nazywam rygorem ofensywnym.

Rygor ofensywny to zdyscyplinowane podejście do testów adwersarialnych, krytycznej analizy i walidacji opartej na dowodach, które podważa założenia dotyczące bezpieczeństwa. Polega na ocenie zachowania systemów w realistycznych warunkach, zamiast polegać wyłącznie na projektach architektonicznych, udokumentowanych zabezpieczeniach lub domniemanej ochronie.

Stosowane w nim praktyki są dobrze znane. Testy penetracyjne, modelowanie zagrożeń, red teaming i walidacja bezpieczeństwa od dawna podważają założenia dotyczące obrony.

Rygor ofensywny łączy te praktyki wokół jednego zasadniczego pytania:

Jakie dowody potwierdzają, że zamierzona granica bezpieczeństwa jest zachowana?

Organizacja może mieć polityki ograniczające dostęp do informacji wrażliwych, model skonfigurowany tak, by odrzucał niedozwolone prośby, oraz agenta działającego z ograniczonymi uprawnieniami.

To istotne zabezpieczenia. Sam fakt ich istnienia nie dowodzi jednak, że cały system zachowuje się bezpiecznie w warunkach ataku.

Model może odrzucić złośliwe polecenie, podczas gdy uprawnione narzędzie nadal pozwala na niezamierzone działanie. Polityka może wydawać się poprawna, a mimo to interakcje między systemami mogą tworzyć nieoczekiwaną drogę jej obejścia.

Czasem nazywam to „złudzeniem barier ochronnych”: myleniem samej obecności zabezpieczeń z dowodem, że system nie może przekroczyć granicy, której miały pilnować.

Zabezpieczenia są przydatne. Trzeba jednak wykazać ich skuteczność.

Rozważmy autonomicznego agenta uprawnionego do zbadania podejrzenia naruszenia bezpieczeństwa. Może pobierać dzienniki zdarzeń, analizować aktywność użytkowników i zalecać działania ograniczające skutki incydentu.

Podczas autoryzowanego testu bezpieczeństwa tester przeprowadzający atak wprowadza wprowadzające w błąd instrukcje do informacji, z którymi agent ma pracować.

Test nie powinien ograniczać się do ustalenia, czy agent zastosował się do tych instrukcji.

Powinien sprawdzić, czy agent próbował podjąć nieuprawnione działanie, czy niezależne zabezpieczenia uniemożliwiły jego wykonanie, czy próba została odnotowana oraz czy system prawidłowo odzyskał sprawność.

Offensive Rigor łączy pięć działań:

1. Określenie założenia: ustal, jaką właściwość bezpieczeństwa ma egzekwować architektura.
2. Podważenie założenia: przetestuj realistyczne ścieżki ataku, zmanipulowane dane wejściowe oraz kombinacje legalnych możliwości.
3. Zebranie dowodów: ustal, co system próbował zrobić, co zostało wykonane i które mechanizmy kontrolne zadziałały.
4. Usunięcie słabości: napraw model, przepływ pracy, uprawnienia, architekturę lub proces operacyjny, które doprowadziły do niepowodzenia.
5. Weryfikacja poprawki: ponownie przetestuj odpowiednią ścieżkę ataku i potwierdź, że zamierzona właściwość bezpieczeństwa jest egzekwowana.

Na tym polega różnica między testowaniem odpowiedzi modelu a testowaniem bezpieczeństwa całego systemu.

Trzeba też sprawdzić, co dzieje się po uzyskaniu początkowego przyczółka. Atakujący może próbować pozyskiwać dane uwierzytelniające, eskalować uprawnienia, utrzymywać dostęp lub przemieszczać się w sieci, nadużywając możliwości już dostępnych w danym środowisku.

To, że narzędzie jest legalne, nie oznacza, że każde jego użycie jest legalne.

Celem Offensive Rigor nie jest zakładanie, że systemy autonomiczne są niezabezpieczone. Chodzi o ustalenie w drodze testów, gdzie przebiegają granice ich bezpieczeństwa i czy są skuteczne.

Autonomia warunkowa: oddzielenie inteligencji od uprawnień

Jednym z rozwiązań architektonicznych jest rozróżnienie tego, co system AI może zrobić, od tego, do czego ma uprawnienia.

To podejście nazywam autonomią warunkową.

Autonomia warunkowa zakłada, że odpowiedni poziom niezależności zależy od zadania, środowiska operacyjnego, potencjalnych konsekwencji, niepewności oraz dostępnych dowodów uzasadniających działanie.

Agent podsumowujący publicznie dostępne informacje niekoniecznie wymaga takiego samego nadzoru jak agent uprawniony do wyłączania kont, modyfikowania reguł zapory sieciowej lub wprowadzania zmian w infrastrukturze produkcyjnej.

Ten drugi może wymagać jasno określonych reguł zaangażowania, niezależnie egzekwowanych uprawnień, silniejszej autoryzacji oraz zgody człowieka na działania o istotnych konsekwencjach.

Te granice nie powinny się rozszerzać tylko dlatego, że agent uzna, iż szerszy dostęp ułatwi osiągnięcie jego celu.

Agent może ponownie rozważyć sposób wykonania autoryzowanego zadania, nie uzyskując przy tym dodatkowych uprawnień.

OWASP: 10 najważniejszych zagrożeń dla aplikacji LLM porusza tę kwestię w kategorii LLM06:2025 — nadmierna sprawczość. OWASP wskazuje nadmierną funkcjonalność, uprawnienia i autonomię jako źródła ryzyka oraz zaleca ograniczanie możliwości i niezależne egzekwowanie autoryzacji.

Autonomia warunkowa stosuje te zasady z uwzględnieniem ryzyka operacyjnego.

Dostęp do informacji należy ograniczyć do zakresu wymaganego przez dane zadanie. Uprawnienia narzędzi powinny obejmować wyłącznie zatwierdzone operacje. Wykonywanie działań można ograniczać za pomocą limitów, limitów częstotliwości, wymogów zatwierdzania oraz warunków przerwania.

Te zabezpieczenia są szczególnie ważne w przypadku autonomicznych testów ofensywnych.

Agent testujący może zgodnie z prawem wykryć dane uwierzytelniające lub informacje poufne podczas realizacji autoryzowanego celu. Samo wykrycie danych uwierzytelniających nie oznacza jednak, że model musi otrzymać je w postaci jawnej.

Mechanizm zabezpieczający może oddzielić poufne dane uwierzytelniające od modelu i pośredniczyć w ich użyciu, stosując niezależnie egzekwowaną autoryzację. Na przykład broker danych uwierzytelniających może przekazać tajny klucz bezpośrednio zatwierdzonej usłudze, nie ujawniając go niepotrzebnie modelowi.

Jest to zastosowanie ugruntowanych zasad najmniejszych uprawnień i rozdziału obowiązków.

Rodzą się też ciekawe pytania dotyczące architektury Bring Your Own Model (BYOM) lub Bring Your Own LLM (BYO-LLM).

Jeśli jutro zastąpimy bazowy model innym, które gwarancje bezpieczeństwa pozostaną niezmienione?

Autoryzacja zadań, izolacja danych uwierzytelniających, ograniczenia zakresu, rejestrowanie zdarzeń i egzekwowanie zasad mogą być realizowane przez otaczający model mechanizm zabezpieczający, zamiast w całości zależeć od zachowania modelu.

Nie oznacza to, że taki mechanizm jest automatycznie bezpieczny ani że modele można stosować zamiennie. Różne modele mogą odmiennie interpretować instrukcje i wywoływać narzędzia, a także powodować różne rodzaje awarii.

Rzetelna ocena musi uwzględniać zarówno mechanizmy kontrolne, które mają pozostać niezmienne, jak i zachowania zmieniające się wraz ze zmianą modelu.

Być może najtrwalsze właściwości bezpieczeństwa to te, które można egzekwować niezależnie, nawet gdy komponent inteligentny ewoluuje.

Gdy AI działa na AI: problem weryfikacji

Rozważmy hipotetyczny przebieg pracy w ramach operacji bezpieczeństwa:

Zbadaj ten incydent, zbierz dowody, ustal, których tożsamości dotyczy, zaproponuj działania ograniczające skutki, wykonaj zatwierdzone działania i zweryfikuj ich rezultat.

Agent prowadzący dochodzenie analizuje dane telemetryczne. Inny agent zaleca działania ograniczające skutki incydentu. Upoważniony agent wykonawczy wprowadza zmiany. Agent weryfikujący ocenia ich rezultat.

To przykład autonomicznej reakcji na incydent w zamkniętej pętli, a nie udokumentowanej porażki całej branży.

Załóżmy, że pierwszy agent błędnie uznaje tożsamość za przejętą. Drugi agent przyjmuje ten wniosek i wyłącza konto. Trzeci potwierdza, że konto zostało wyłączone, i zgłasza sukces.

Wybrana operacja została wykonana.

Ale czy pierwotne ustalenie było prawidłowe? Czy działanie było autoryzowane? Czy podjęte kroki rzeczywiście ograniczyły zagrożenie? Czy spowodowały niepotrzebne zakłócenia?

Weryfikacja nie może polegać wyłącznie na potwierdzeniu, że agent wykonał wybrane przez siebie działanie.

Samo powierzenie weryfikacji innemu agentowi AI nie sprawia też automatycznie, że wynik jest niezależny.

Różni agenci mogą opierać się na tych samych niedokładnych danych telemetrycznych, przejętych informacjach lub błędnych założeniach. Ich zgodność nie stanowi niezależnego potwierdzenia faktów.

Im poważniejsze konsekwencje autonomicznego działania, tym większa potrzeba weryfikacji niezależnej od systemu podejmującego decyzję.

Niezależność może polegać na korzystaniu z dowodów pochodzących z odrębnych źródeł, deterministycznym sprawdzaniu zgodności z polityką, ograniczeniu środowiska wykonawczego, weryfikacji przez człowieka lub zastosowaniu kilku takich zabezpieczeń.

Zakres stosowanych zabezpieczeń powinien być proporcjonalny do konsekwencji błędu.

Działania o niewielkim wpływie, które można odwrócić, mogą nadawać się do automatycznej weryfikacji. Działania o poważnych konsekwencjach lub trudne do odwrócenia mogą wymagać bardziej rygorystycznej autoryzacji, niezależnego potwierdzenia i wyraźnej zgody człowieka.

Cztery pytania pomagają rozróżnić istotne właściwości bezpieczeństwa:

• Czy system prawidłowo zinterpretował zamierzone zadanie?
• Czy działanie mieściło się w zakresie przekazanych mu uprawnień?
• Czy wykonanie przebiegało w dozwolonych granicach?
• Czy uzyskany rezultat spełnił zamierzony cel w zakresie bezpieczeństwa?

Pytania te są ze sobą powiązane, ale nie są wymienne.

Agent może wykonać autoryzowane działanie, które przyniesie niezamierzony rezultat. Może też osiągnąć pozornie korzystny rezultat, podejmując nieautoryzowane działanie.

Żadnego z tych przypadków nie należy automatycznie uznawać za sukces w zakresie bezpieczeństwa.

Wraz ze wzrostem możliwości systemów autonomicznych wyzwaniem nie jest wyłącznie umożliwienie im realizacji złożonych procesów. Trzeba również zgromadzić wystarczające dowody, że ich działania pozostają autoryzowane, właściwe i prawidłowe.

Oznacza to również wiedzę, kiedy przerwać działanie, przekazać sprawę do rozpatrzenia, cofnąć działanie lub zaakceptować ograniczone i jasno rozpoznane ryzyko.

Zaufanie musi wynikać z dowodów

Konsekwencje autonomicznej AI dla bezpieczeństwa nie są wyłącznie negatywne.

Systemy autonomiczne mogą pomagać obrońcom wykrywać słabe punkty, badać zagrożenia i przeprowadzać walidację, która w przeciwnym razie wymagałaby znacznego nakładu pracy ludzi.

Lepsze modele, skuteczniejsze zabezpieczenia zewnętrzne i dojrzalsze praktyki operacyjne mogą ograniczyć część ryzyka związanego z przekazywaniem uprawnień.

Przedwczesne byłoby zatem stwierdzenie, że autonomiczna AI jest z natury niebezpieczna lub że zarządzanie nią nie może nadążyć za jej rozwojem.

Istnieje też poważny kontrargument wobec tezy, że autonomiczna AI wymaga całkowicie nowych zasad bezpieczeństwa.

Wiele podstawowych problemów — nadmierne uprawnienia, niezaufane dane wejściowe, słaba autoryzacja, niespójne egzekwowanie polityk i niewystarczająca weryfikacja — jest badanych od dziesięcioleci.

Ugruntowane zabezpieczenia mogą już zapewniać praktyczne rozwiązania, jeśli są prawidłowo wdrażane i testowane.

Autonomia może zmienić tempo, skalę i złożoność ich stosowania. Nie unieważnia ich jednak automatycznie.

Dostępne dowody skłaniają do postawienia bardziej użytecznego pytania: w jakich warunkach można ufać systemom autonomicznym, że będą korzystać z przekazanych im uprawnień, i jak wykazać, że warunki te są spełnione?

Odpowiedzi nie zapewnią same możliwości modelu.

Potrzebne są granice architektoniczne, jasno przypisane obowiązki, niezależne egzekwowanie zasad autoryzacji, odpowiedni nadzór oraz dowody na to, że zabezpieczenia działają w realistycznych warunkach.

Potrzebna jest również spójna, a zarazem ewoluująca wizja bezpieczeństwa i ryzyka.

Nasze podstawowe zasady bezpieczeństwa nie muszą zmieniać się wraz z każdym nowym modelem. Musimy jednak nieustannie podważać nasze założenia dotyczące tego, jak zasady te mają zastosowanie, w miarę rozwoju możliwości, środowisk operacyjnych i zakresu przekazywanych uprawnień.

Temu właśnie służy Offensive Rigor.

Nie po to, by udowodnić, że systemy AI zawiodą, lecz by odkryć, w jakich sytuacjach mogą zawieść, ustalić konsekwencje oraz zweryfikować zabezpieczenia mające zapobiegać takim awariom lub ograniczać ich skutki.

Być może trwalszą przewagą nie jest po prostu wybór bardziej zaawansowanego modelu, lecz zbudowanie architektury, w której można wymieniać modele bez naruszania granic zaufania, uprawnień i weryfikacji.

Gra w kotka i myszkę trwa. Coraz częściej po obu stronach mogą pojawiać się autonomiczni gracze.

Najważniejsze jest dbanie o to, by w wyścigu do automatyzacji wszystkiego innego nie zatracić zdolności do wykrywania słabości, naprawiania ich i potwierdzania rezultatów.

Zaufanie musi opierać się na dowodach.

Nota autora: Wyrażone w tym artykule opinie i interpretacje są moimi własnymi i niekoniecznie odzwierciedlają oficjalne stanowisko, zasady ani możliwości produktów mojego pracodawcy.