Tool Misuse i Excessive Agency: gdy agenci AI mają zbyt wiele uprawnień

Excessive Agency oznacza zbyt szeroko zakrojoną autonomię, uprawnienia lub funkcjonalność agenta AI: może on zrobić więcej, niż wymaga jego zadanie. Tool Misuse to niewłaściwe użycie legalnych narzędzi: dostęp jest autoryzowany, sposób użycia już nie. Oba zjawiska prowadzą do niezamierzonych działań, wycieku danych i niekontrolowanych kosztów. W systematyce OWASP Excessive Agency stanowi ramę, w której Tool Misuse materializuje się jako konkretne ryzyko agentowe.

• Szybka odpowiedź 1: Excessive Agency to przyczyna (zbyt duża autonomia lub zbyt szerokie uprawnienia), Tool Misuse to skutek (legalne narzędzie zostaje użyte w niebezpieczny sposób lub niezgodnie z przeznaczeniem).
• Szybka odpowiedź 2: OWASP ujmuje ten temat w LLM Top 10 2025 jako LLM06:2025, a w Agentic Top 10 2026, opublikowanym 9 grudnia 2025, jako ASI02 (Tool Misuse & Exploitation).
• Szybka odpowiedź 3: Kluczowe środki zaradcze to zasada najmniejszych uprawnień, tokeny o ograniczonym zakresie i krótkim czasie życia, zatwierdzanie krytycznych działań przez człowieka oraz twarde limity zapytań lub kosztów.

Dlaczego „zbyt wiele uprawnień” to prawdziwy problem agentów

Klasyczne aplikacje LLM odpowiadają: wchodzi prompt, wychodzi odpowiedź modelu. Systemy agentowe planują, wybierają narzędzia, zapisują w pamięci i działają, przy minimalnym zatwierdzaniu kolejnych kroków przez człowieka. Właśnie ten skok od „odpowiadania” do „działania” sprawia, że kwestia uprawnień staje się centralną kwestią bezpieczeństwa.

OWASP ujmuje to w LLM Top 10 2025 jako LLM06:2025 Excessive Agency: przyznawanie modelom LLM niesprawdzonej autonomii działania przy niewystarczającym ograniczeniu uprawnień lub niewystarczającym nadzorze człowieka. Ten punkt w 2025 roku wyraźnie rozszerzono o architektury agentowe, dzięki czemu stanowi pomost między ryzykami LLM a ryzykami agentów. Excessive Agency bezpośrednio poprzedza kilka ryzyk agentowych z OWASP Top 10 dla aplikacji agentowych 2026, mianowicie ASI02 (Tool Misuse), ASI03 (Identity & Privilege Abuse) i ASI10 (Rogue Agents).

Excessive Agency powstaje zazwyczaj na trzech poziomach:

• Zbyt wiele uprawnień: agent dziedziczy zbyt szerokie prawa od użytkownika lub konta serwisowego, na którym działa.
• Zbyt wiele funkcji: agent ma do dyspozycji narzędzia, których jego zadanie w ogóle nie wymaga (np. narzędzie do usuwania lub płatności przy przypadku użycia ograniczonym do odczytu).
• Zbyt dużo autonomii: krytyczne działania są wykonywane bez potwierdzenia, np. przez włączone tryby automatycznego zatwierdzania lub „YOLO”.

Tool Misuse (ASI02): uprawniony dostęp, nieuprawnione użycie

Opis ASI02 w OWASP jest precyzyjny: agent działa w ramach swoich autoryzowanych uprawnień, ale stosuje legalne narzędzie w niebezpieczny lub niezamierzony sposób. Usuwa cenne dane, nadmiernie wywołuje drogie API, wykonuje destrukcyjne operacje lub wyprowadza informacje. Ważne jest odróżnienie od ASI03: dostęp jest uprawniony, użycie nie.

Typowe wektory ataków i błędów:

• Atak prompt injection, który wykorzystuje narzędzie niezgodnie z przeznaczeniem, np. send_email, nagle używane do phishingu wymierzonego w całą bazę klientów.
• Rozbieżność między tym, jak agent interpretuje zadanie, a intencją programisty.
• Niebezpieczna delegacja: agent przekazuje potężne narzędzie subagentowi bez kontekstowych zabezpieczeń.
• Tryby automatycznego zatwierdzania lub „YOLO”, które wyłączają prośby o potwierdzenie.

Ryzyka w praktyce: działania, dane, koszty

Trzy wymiary szkód można wyraźnie rozdzielić:

Wymiar kosztowy jest w świecie agentów szczególnie drażliwy: OWASP ujmuje go w LLM Top 10 jako LLM10:2025 Unbounded Consumption („denial-of-wallet”). Plany wieloetapowe mnożą zużycie tokenów, dlatego każdy plan potrzebuje twardo egzekwowanego budżetu.

Udokumentowane incydenty (stan na 2026 rok)

Publicznie udokumentowane są m.in. te przypadki:

• Amazon Q Code Assistant (CVE-2025-8217, lipiec 2025): Atakujący przejęli token GitHub i wprowadzili złośliwe instrukcje do rozszerzenia VS Code v1.84.0. Destrukcyjne prompty w połączeniu z flagami --trust-all-tools i --no-interactive usunęłyby systemy plików i zasoby chmurowe bez potwierdzenia (The Register). Rozszerzenie było zainstalowane u około 1 miliona programistów; poprawka pojawiła się w wersji v1.85.0.
• OpenAI Operator (Embrace The Red, Johann Rehberger, luty 2025): Atak prompt injection w zgłoszeniu na GitHubie skłonił agenta do otwarcia stron zalogowanych kont i ujawnienia prywatnych danych, np. adresu e-mail w Hacker News oraz adresu i numeru telefonu w Booking.com (Embrace The Red).
• Langflow (CVE-2025-3248): Ten popularny framework agentowy w wersjach starszych niż 1.3.0 pozwalał na wykonanie kodu bez uwierzytelnienia (CSA Singapur). Według CrowdStrike od kwietnia 2025 kilku aktorów zagrożeń wykorzystało krytyczną lukę w Langflow, aby zdobyć przyczółek, wykraść dane uwierzytelniające i wprowadzić złośliwe oprogramowanie. To podatność samego frameworka, a nie Tool Misuse w ścisłym sensie: tutaj celem staje się platforma agentowa.

Eksperyment myślowy: limit, który da się wyperswadować

W blogach o bezpieczeństwie krąży kaskada zakupowa z branży produkcyjnej, np. u Stellar Cyber. Nie znaleźliśmy dla niej weryfikowalnego źródła pierwotnego. Dlatego ten przypadek nadaje się tylko jako eksperyment myślowy: agent zakupowy przez trzy tygodnie jest stopniowo „przekonywany”, że jego limit autoryzacji wynosi 500 000 dolarów amerykańskich. Następnie atakujący składa w 10 transakcjach fałszywe zamówienia na 5 milionów dolarów amerykańskich. Wniosek: limit, który istnieje tylko w kontekście agenta, można mu wyperswadować. Musi on być twardą granicą w narzędziu lub w warstwie gateway.

Środki zaradcze: obrona warstwowa

Środki odpowiadają cyklowi życia agenta. Ważne: żadne pojedyncze zabezpieczenie nie wystarcza. Warstwy się uzupełniają.

Do tego dochodzą dwie zasady architektoniczne. Po pierwsze, wzorzec gateway/proxy przed każdym agentem jako centralny punkt egzekwowania list dozwolonych, walidacji schematu, limitów kosztów, limitów zapytań i logowania audytowego. Po drugie, kwestia tożsamości: każdy agent jest odrębną tożsamością nieludzką (NHI) z własnym cyklem życia poświadczeń, krótkotrwałymi tokenami i przydzielaniem just-in-time. Częstym błędem wdrożeniowym jest uruchamianie agenta „żeby działało” na koncie serwisowym z uprawnieniami równoważnymi administratorskim. Bezpieczniejsza jest delegowana tożsamość użytkownika: agent działa jako dany człowiek i jest ograniczony do jego uprawnień.

Słowo o skuteczności zatwierdzania przez człowieka: w praktyce takie punkty kontrolne często z czasem słabną. OWASP ujmuje to jako osobne ryzyko ASI09 (Human-Agent Trust Exploitation). Błąd automatyzacji i autorytatywnie brzmiące odpowiedzi prowadzą do zatwierdzania bez sprawdzania. Dlatego skuteczne punkty kontrolne wymuszają niezależną weryfikację dowodów, a nie tylko przyklepanie rekomendacji agenta.

Przykład: uprawnienia agenta do newslettera

Agent marketingowy ma tworzyć i wysyłać szkice newslettera. Excessive Agency pojawia się, gdy dostaje pełny dostęp do systemu e-mailowego. Zasada najmniejszych uprawnień w pseudokodzie:

```
agent_role: "newsletter-draft"
tools:

• read_segment: scope=audience.read rate_limit=20/min
• create_draft: scope=campaign.write rate_limit=10/min
• send_campaign: scope=campaign.send rate_limit=2/h
  require_human_approval=true # Gate: sprawdź odbiorców + treść
  deny:
• delete_contact, export_audience, billing.*
  budget:
  token_cap=500000/day usd_cap=20/day circuit_breaker=on
  token:
  type=short_lived ttl=15min
  ```

Efekt: nawet po udanym ataku prompt injection agent nie może eksportować ani usuwać kontaktów, przeciążyć płatnego masowego API ani wysłać kampanii bez zatwierdzenia przez człowieka. Krótkotrwały token o ograniczonym zakresie sprawia, że przechwycone dane uwierzytelniające tracą wartość po 15 minutach.

Dla agencji i firm B2B

Jeśli obsługujesz agentów AI dla klientów w marketingu, sprzedaży lub obsłudze klienta, odpowiadasz za projekt ich uprawnień. Praktyczny początek: zinwentaryzuj dla każdego agenta każde narzędzie i każdy zakres, wyłącz automatyczne zatwierdzanie dla wszystkiego, co usuwa dane, przesuwa pieniądze lub wysyła wiadomości, i ustal twarde limity kosztów i zapytań, zanim agent trafi na produkcję. Blck Alpaca z Wiednia wspiera organizacje B2B w całej Europie w budowie architektur agentowych zgodnych z zasadą najmniejszych uprawnień w oparciu o OWASP Agentic Top 10. Uwaga: ten artykuł ma charakter wyłącznie informacyjny i nie stanowi porady prawnej; konkretne kwestie zgodności i odpowiedzialności najlepiej wyjaśnij z wykwalifikowanymi doradcami.