Nadmierna sprawczość agentów AI (OWASP LLM06) - co agent może zrobić w Waszym imieniu

W skrócie: model językowy sam z siebie niczego nie usuwa ani nie wysyła. Robią to narzędzia, które mu podłączyliście. LLM06 Excessive Agency to kategoria OWASP opisująca sytuację, w której agent ma tych narzędzi, uprawnień albo swobody więcej, niż wymaga jego zadanie.

Wstrzyknięcie promptu decyduje o tym, czy atakujący przejmie ster. Sprawczość agenta decyduje o tym, jak duża będzie szkoda. Tę drugą część da się ograniczyć architekturą, bez czekania na lepszy model.

W ogólnym wpisie o testach aplikacji LLM uprawnienia agenta zajmują jeden akapit. W tekście o zatruwaniu danych kończyliśmy wnioskiem, że model trzeba traktować jak coś, co może zostać zmanipulowane. Ten wpis jest o tym, co z tego wynika w praktyce: jak zaprojektować i przetestować agenta tak, żeby zmanipulowany model nie miał czym zaszkodzić.

Skąd wziął się problem

Jeszcze niedawno typowy asystent AI tylko odpowiadał. Najgorsze, co mógł zrobić, to powiedzieć coś nieprawdziwego albo ujawnić fragment danych. Dziś coraz częściej działa: czyta skrzynkę, tworzy zgłoszenia, modyfikuje rekordy w CRM, uruchamia skrypty, wysyła wiadomości. Standardy w rodzaju MCP sprawiły, że podłączenie kolejnego narzędzia to kilka linii konfiguracji.

Łatwość podłączania ma koszt: narzędzia dokłada się dlatego, że są dostępne, a nie dlatego, że zadanie ich wymaga. A każde narzędzie jest zdolnością, którą przejmuje ten, kto przejmie model.

Trzy źródła nadmiernej sprawczości

OWASP w edycji 2025 wskazuje trzy przyczyny. Warto je rozróżniać, bo każda wymaga innej poprawki.

	Na czym polega	Typowy przykład
Nadmiar funkcji	Agent ma dostęp do narzędzi albo operacji, których jego zadanie nie wymaga.	Asystent do czytania dokumentów ma rozszerzenie, które potrafi też je edytować i usuwać. Albo wtyczka z etapu prototypu, o której wszyscy zapomnieli.
Nadmiar uprawnień	Narzędzie jest właściwe, ale działa na koncie z szerszymi prawami niż potrzeba.	Agent do raportów łączy się z bazą użytkownikiem z prawem `UPDATE` i `DELETE`, choć wystarczy mu `SELECT`. Albo używa jednego konta technicznego dla wszystkich użytkowników.
Nadmiar autonomii	Operacje o dużym skutku wykonują się bez potwierdzenia człowieka.	Usunięcie dokumentu, wysłanie wiadomości na zewnątrz albo przelew realizowane od razu, bo model tak zdecydował.

OWASP wymienia jeszcze jeden wzorzec, który w praktyce jest najgroźniejszy: narzędzia otwarte. Rozszerzenie „wykonaj polecenie powłoki" albo „pobierz dowolny adres URL" nie ma zakresu, więc nie da się go ograniczyć uprawnieniami. Jest ograniczone tylko tym, co model zechce do niego przekazać.

Zabójcze trio

Użyteczny test na to, czy agent jest niebezpieczny, zaproponował w 2025 roku Simon Willison pod nazwą lethal trifecta. Agent jest podatny na kradzież danych, jeśli jednocześnie:

ma dostęp do prywatnych danych - skrzynki, dokumentów, bazy klientów,
czyta treści, które może kontrolować ktoś obcy - przychodzące maile, strony WWW, zgłoszenia, załączniki,
potrafi komunikować się na zewnątrz - wysłać wiadomość, wywołać adres URL, wstawić obrazek z zewnętrznego serwera.

Każdy z tych elementów osobno jest normalną funkcją. Razem tworzą gotową drogę: obca treść wydaje polecenie, dane są pod ręką, kanał wyjścia istnieje. Nie potrzeba do tego żadnej luki w kodzie w klasycznym sensie.

Scenariusz z opisu OWASP

Asystent streszcza pocztę użytkownika i ma przy okazji możliwość wysyłania wiadomości. Atakujący wysyła maila, w którym ukryta instrukcja każe modelowi przeszukać skrzynkę pod kątem umów i przekazać je na wskazany adres. Użytkownik prosi o streszczenie poczty z dnia. Nie klika niczego podejrzanego - wystarczy, że asystent przeczyta tę wiadomość.

Wniosek praktyczny: jeśli nie da się usunąć żadnego z trzech elementów, trzeba przynajmniej postawić człowieka albo twardą regułę na styku drugiego z trzecim.

Dlaczego filtr na promptach tego nie załatwi

Naturalny odruch to dołożenie warstwy, która wykrywa złośliwe instrukcje w treści. Warto ją mieć, ale nie może być jedyną kontrolą. Wstrzyknięcie promptu nie ma pełnej listy wariantów: może być w innym języku, zakodowane, rozbite między kilka dokumentów albo ukryte w obrazie. Filtr, który zatrzymuje 99% prób, przy agencie z uprawnieniem do wysyłki danych oznacza, że setna próba się uda.

Dlatego OWASP stawia na pełną mediację: decyzję o tym, czy operacja jest dozwolona, podejmuje system docelowy, a nie model. Model może zaproponować usunięcie rekordu. Czy ten użytkownik ma prawo go usunąć, sprawdza API, tak samo jak sprawdziłoby to przy żądaniu z przeglądarki.

Jak to sprawdzamy w teście

Inwentarz narzędzi. Pełna lista funkcji dostępnych dla agenta, łącznie z tymi, których nie widać w interfejsie. Porównujemy ją z tym, co agent faktycznie ma robić. Wtyczki testowe i zapomniane integracje wychodzą tu najczęściej.
Tożsamość wywołań. Czyimi uprawnieniami agent działa w systemach docelowych: użytkownika, który z nim rozmawia, czy wspólnego konta technicznego. W drugim przypadku sprawdzamy, czy użytkownik A może przez agenta dostać się do danych użytkownika B.
Autoryzacja po stronie serwera. Wywołujemy narzędzia z parametrami, których twórcy się nie spodziewali, i sprawdzamy, czy API odrzuca je samo, czy ufa, że model „nie poprosi o coś złego".
Wstrzyknięcie pośrednie przez każde źródło. Umieszczamy instrukcje w mailu, dokumencie, zgłoszeniu i na stronie, którą agent odwiedza, i obserwujemy, które narzędzia da się w ten sposób uruchomić.
Kanały wyjścia. Szukamy wszystkich dróg, którymi dane mogą opuścić system: wysyłka, żądania HTTP, linki i obrazki renderowane w odpowiedzi, zapis do miejsc widocznych z zewnątrz.
Potwierdzenia. Czy operacje nieodwracalne wymagają zgody człowieka, czy zgoda pokazuje faktyczne parametry operacji, a nie streszczenie napisane przez model, i czy da się ją obejść, dzieląc operację na kilka mniejszych.

Pytanie, które porządkuje cały test, jest to samo co w ogólnym wpisie: jeśli atakujący kontroluje to, co model wygeneruje, jaki jest najgorszy możliwy skutek? Odpowiedź to lista narzędzi i uprawnień, nie jakość modelu.

Co robić

Minimum narzędzi. Każde narzędzie podłączone do agenta powinno mieć uzasadnienie w jego zadaniu. Te z etapu prototypu usuńcie przed produkcją.
Wąskie funkcje zamiast otwartych. Zamiast „wykonaj polecenie powłoki" - „wygeneruj raport X". Zamiast „pobierz dowolny URL" - pobieranie z listy dozwolonych domen.
Uprawnienia użytkownika, nie konta technicznego. Agent powinien działać w kontekście osoby, która z nim rozmawia, z zakresem uprawnień ograniczonym do potrzeb, np. przez OAuth z zakresem tylko do odczytu.
Człowiek przy operacjach o dużym skutku. Usuwanie, wysyłka na zewnątrz, płatności, zmiany uprawnień. Potwierdzenie ma pokazywać, co dokładnie się stanie.
Autoryzacja w systemie docelowym. API sprawdza uprawnienia przy każdym wywołaniu, niezależnie od tego, czy wywołuje je człowiek, czy agent.
Log i limity. Rejestrujcie każde wywołanie narzędzia z parametrami i ograniczcie ich liczbę w czasie. Bez tego po incydencie nie ustalicie, co agent zrobił.

Czego to nie załatwi

Ograniczenie sprawczości nie sprawia, że agent przestaje być podatny na wstrzyknięcie promptu. Model nadal może zostać zmanipulowany i nadal może wprowadzić w błąd użytkownika treścią odpowiedzi. Zmienia się tylko skala: zamiast wysłać bazę klientów na obcy adres, zmanipulowany agent napisze nieprawdziwe streszczenie.

To jest świadomy kompromis. Każde ograniczenie zmniejsza użyteczność agenta, a każde potwierdzenie to jedno kliknięcie więcej. Test pokazuje, gdzie ten kompromis jest dziś ustawiony i ile realnie kosztuje przesunięcie go w bezpieczniejszą stronę. Po stronie aplikacji obowiązują przy tym te same zasady co zawsze: kontrola dostępu po stronie serwera to pierwsza pozycja również w klasycznym OWASP Top 10.

Jeśli wdrażacie agenta z dostępem do poczty, dokumentów albo systemów firmowych, zobaczcie zakres testów penetracyjnych aplikacji LLM i to, jak przygotować firmę do testu.