Nadmierna sprawczość agenta (Excessive agency)

Definicja

Nadmierna sprawczość to sytuacja, w której system z modelem AI może wykonać szkodliwą akcję, bo dostał więcej możliwości, niż potrzebuje. OWASP opisuje ją w zestawieniu Top 10 dla aplikacji LLM (2025) jako ryzyko LLM06.

Szkoda może wyniknąć z:

halucynacji,
błędnej interpretacji polecenia,
prompt injection.

Przyczyna błędu jest drugorzędna: liczy się to, co agent był w stanie zrobić.

Trzy przyczyny według OWASP

Za dużo funkcji

Agent ma narzędzia, których zadanie nie wymaga. Przykład: agent do czytania maili ma też narzędzie do ich usuwania i wysyłania.

Za dużo uprawnień

Narzędzia agenta mają szerszy dostęp do systemów, niż trzeba. Przykład: agent łączy się z bazą jako administrator, choć potrzebuje tylko odczytu jednej tabeli.

Za dużo samodzielności

Agent wykonuje ważne akcje bez zatwierdzenia przez człowieka. Przykład: sam wysyła maile do klientów albo zmienia dane w systemie.

Co to w zasadzie jest?

To zasada najmniejszych uprawnień przeniesiona na agentów AI.
Pytanie kontrolne brzmi: co najgorszego może zrobić ten agent, jeśli się pomyli albo ktoś go oszuka?
Im mniej funkcji, uprawnień i samodzielności, tym mniejsza szkoda przy błędzie.

Praktyczne zastosowania (konkretne scenariusze)

Scenariusz 1: Asystent kalendarza

Cel: proponowanie terminów spotkań.
Wejście: kalendarz zespołu.
Kroki: daj odczyt kalendarza i prawo tworzenia propozycji, bez usuwania wydarzeń i bez wysyłki zaproszeń.
Rezultat: agent pomaga, ale nie może skasować cudzych spotkań.
Zabezpieczenie: zaproszenia wysyła człowiek.

Scenariusz 2: Agent do raportów z CRM

Cel: cotygodniowe zestawienie sprzedaży.
Wejście: dane z CRM.
Kroki: osobne konto techniczne tylko z odczytem wybranych pól → raport zapisany jako plik.
Rezultat: agent nie zmieni danych klientów, nawet jeśli się pomyli.
Zabezpieczenie: logi wywołań, przegląd uprawnień co kwartał.

Scenariusz 3: Agent w obsłudze spraw w urzędzie

Cel: wstępna klasyfikacja wniosków.
Wejście: wnioski obywateli.
Kroki: agent proponuje kategorię i termin → pracownik zatwierdza → dopiero wtedy zmienia się status sprawy.
Rezultat: decyzja pozostaje po stronie urzędnika.
Zabezpieczenie: zatwierdzenie człowieka przy każdej zmianie statusu.

Typowe błędy i pułapki

Podłączanie pełnego konektora (np. całej skrzynki z prawem wysyłki), bo tak jest szybciej.
Narzędzia otwarte: „uruchom dowolne polecenie”, „wyślij dowolne zapytanie HTTP”.
Jedno konto z szerokimi uprawnieniami dla wszystkich agentów.
Zaznaczanie „zawsze zezwalaj” przy akcjach agenta.
Brak kontroli uprawnień po stronie systemu docelowego: cała ochrona opiera się na prompcie.

Ryzyka i jak je ograniczać

Ryzyko 1: Nieodwracalna akcja

Ryzyko: usunięcie danych, wysłanie maila, przelew.
Jak ograniczać: zatwierdzenie człowieka przy akcjach o dużym wpływie (human-in-the-loop).

Ryzyko 2: Przejęcie agenta

Ryzyko: prompt injection wykorzystuje szerokie uprawnienia.
Jak ograniczać: minimum funkcji i uprawnień, ocena przez zabójczą trójkę.

Ryzyko 3: Brak śladu

Ryzyko: nie wiadomo, co agent zrobił i dlaczego.
Jak ograniczać: logowanie, ślad audytowy, limity liczby akcji.

Checklista “zanim użyjesz”

Jakich narzędzi agent naprawdę potrzebuje do tego zadania?
Czy każde narzędzie ma najwęższy możliwy zakres?
Na jakim koncie i z jakimi uprawnieniami agent działa?
Które akcje wymagają zatwierdzenia człowieka?
Czy system docelowy sam sprawdza uprawnienia, niezależnie od agenta?
Czy akcje agenta są logowane?

Diagram

flowchart LR
    A[Agent]
    B[Funkcje: tylko potrzebne]
    C[Uprawnienia: tylko potrzebne]
    D[Samodzielność: zatwierdzenie przy dużym wpływie]
    E[Bezpieczna akcja]
    A --> B --> C --> D --> E

Diagram pokazuje trzy filtry, przez które powinna przejść każda akcja agenta: ograniczone funkcje, ograniczone uprawnienia i zatwierdzenie człowieka przy akcjach o dużym wpływie.