--- title: "Tool Misuse i Excessive Agency: gdy agenci AI mają zbyt wiele uprawnień" description: "Excessive Agency oznacza zbyt szeroko zakrojoną autonomię, uprawnienia lub funkcjonalność agenta AI: może on zrobić więcej, niż wymaga jego zadanie." locale: "pl" canonical: "https://blckalpaca.at/pl/baza-wiedzy/agenci-ai/bezpieczenstwo-agentow-ai-owasp/tool-misuse-i-excessive-agency-gdy-agenci-ai-maja-zbyt-wiele-uprawnien" category: "Agenci AI" topic: "Bezpieczeństwo agentów AI & OWASP" updated: "2026-10-28T13:36:48.656Z" source: "Blck Alpaca e.U., blckalpaca.at" --- # 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 skrócie - Excessive Agency (w OWASP LLM Top 10 oznaczone jako LLM06:2025) to koncepcyjny pomost do OWASP Agentic Top 10 2026, który bezpośrednio poprzedza ryzyka agentowe ASI02 (Tool Misuse), ASI03 (nadużycie uprawnień) i ASI10 (Rogue Agents). - Tool Misuse (ASI02) oznacza, że agent działa w ramach swoich uprawnień, ale używa legalnego narzędzia w niebezpieczny sposób, na przykład usuwa dane, nadmiernie wywołuje płatne API albo wysyła e-maile phishingowe. - Udokumentowane incydenty, takie jak Amazon Q (CVE-2025-8217, lipiec 2025), pokazują potencjał szkód: destrukcyjne prompty z flagami --trust-all-tools i --no-interactive usunęłyby systemy plików i zasoby chmurowe bez potwierdzenia, przy około 1 milionie instalacji. - Najskuteczniejsze środki zaradcze to zasada najmniejszych uprawnień dla każdego narzędzia, tokeny o ograniczonym zakresie i krótkim czasie życia, punkty kontrolne human-in-the-loop dla działań destrukcyjnych oraz twarde limity zapytań i kosztów z mechanizmami circuit breaker. - Częstym błędem wdrożeniowym jest uruchamianie agenta „żeby działało” na koncie serwisowym z uprawnieniami równoważnymi administratorskim. - Tryby automatycznego zatwierdzania (auto-approve) lub „YOLO”, które wyłączają prośby o potwierdzenie, są kluczowym mnożnikiem ryzyka i powinny być wyłączone dla każdego narzędzia z dostępem do bazy danych, płatności, komunikacji lub wdrożeń. Excessive Agency oznacza zbyt szeroko zakrojoną autonomię, uprawnienia lub funkcjonalność agenta [AI](https://blckalpaca.at/pl/slownik/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](https://blckalpaca.at/pl/slownik/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](https://blckalpaca.at/pl/slownik/prompt), wychodzi odpowiedź modelu. [Systemy agentowe planują, wybierają narzędzia, zapisują w pamięci i działają](https://blckalpaca.at/pl/uslugi/agenci-ai), 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**](https://blckalpaca.at/pl/baza-wiedzy/agenci-ai/bezpieczenstwo-agentow-ai-owasp/omowienie-owasp-llm-top-10-2025-dziesiec-ryzyk-bezpieczenstwa-aplikacji-llm): 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](https://blckalpaca.at/pl/slownik/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](https://blckalpaca.at/pl/slownik/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 ryzyka | Co się dzieje | Przykładowe wyzwalacze | | --- | --- | --- | | Niezamierzone działania | Destrukcyjne operacje (DELETE, DROP, `rm -rf`, przelew), wartości zadane poza granicami bezpieczeństwa, masowe blokady | Narzędzie użyte niezgodnie z przeznaczeniem, włączone automatyczne zatwierdzanie (wyłączone potwierdzenia), błędna interpretacja zadania | | Wyciek danych | Eksfiltracja danych klientów, pracowników lub danych biznesowych przez legalne kanały | Zmanipulowane treści internetowe, przejęty łańcuch narzędzi, niebezpieczna delegacja do subagentów | | Koszty („denial-of-wallet”) | Eksplozja kosztów tokenów i API przez nadmiernie wywoływane lub rekurencyjne plany | Burze ponowień, nieograniczone plany wieloetapowe, brak limitów budżetu | Wymiar kosztowy jest w świecie agentów szczególnie drażliwy: OWASP ujmuje go w LLM Top 10 jako [**LLM10:2025 Unbounded Consumption**](https://blckalpaca.at/pl/baza-wiedzy/agenci-ai/budowa-infrastruktury-agentow-ai/ekonomia-tokenow-skad-naprawde-biora-sie-koszty-agentow-ai) („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](https://blckalpaca.at/pl/slownik/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](https://www.theregister.com/security/2025/07/24/destructive-ai-prompt-published-in-amazon-q-extension/615835)). Rozszerzenie było zainstalowane u około 1 miliona programistów; poprawka pojawiła się w wersji v1.85.0. - [**OpenAI](https://blckalpaca.at/pl/slownik/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](https://embracethered.com/blog/posts/2025/chatgpt-operator-prompt-injection-exploits/)). - **Langflow (CVE-2025-3248):** Ten popularny [framework agentowy](https://blckalpaca.at/pl/slownik/framework-agentowy) w wersjach starszych niż 1.3.0 pozwalał na wykonanie kodu bez uwierzytelnienia ([CSA Singapur](https://www.csa.gov.sg/alerts-and-advisories/alerts/al-2025-059/)). Według [CrowdStrike](https://www.crowdstrike.com/en-us/cybersecurity-101/artificial-intelligence/ai-monitoring/) 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](https://stellarcyber.ai/learn/agentic-ai-securiry-threats/). 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ą. | Warstwa | Środek | Efekt | | --- | --- | --- | | Projektowanie | Zasada najmniejszych uprawnień dla każdego narzędzia; walidacja schematu każdego argumentu narzędzia; wstępne szacowanie kosztów (pre-flight) dla drogich/destrukcyjnych narzędzi | Ogranicza to, co agent w ogóle może zrobić | | Budowa | Listy allow/deny dla każdej roli agenta; wyłączenie automatycznego zatwierdzania dla baz danych, płatności, komunikacji i wdrożeń | Zapobiega ryzykownym konfiguracjom domyślnym | | Czas działania | Punkty kontrolne human-in-the-loop dla operacji destrukcyjnych; kolejki zatwierdzania narzędzi; tokeny o ograniczonym zakresie i krótkim czasie życia (osobne dla odczytu/zapisu/wykonywania/delegowania) | Hamuje pojedyncze krytyczne działania | | Eksploatacja | Limity kosztów z mechanizmami circuit breaker; limity zapytań na narzędzie, agenta i tenanta; wykrywanie wzorców wywołań narzędzi w SIEM | Ogranicza koszty i wykrywa anomalie | 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](https://blckalpaca.at/pl/baza-wiedzy/agenci-ai/bezpieczenstwo-agentow-ai-owasp/jak-dobrze-zaprojektowac-human-in-the-loop-hitl-wzorce-zatwierdzania-dla-agentow): 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](https://genai.owasp.org/resource/owasp-top-10-for-agentic-applications-for-2026/). 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. ## Najczęściej zadawane pytania ### Czym różni się Excessive Agency od Tool Misuse? Excessive Agency to przyczyna, a Tool Misuse to skutek. Excessive Agency opisuje zbyt szeroko zakrojoną autonomię, uprawnienia lub funkcjonalność: agent może zasadniczo więcej, niż potrzebuje do swojego zadania. Tool Misuse (OWASP ASI02) to konkretny incydent, w którym samo w sobie legalne narzędzie zostaje użyte w niebezpieczny sposób lub niezgodnie z przeznaczeniem. Ważne: przy Tool Misuse dostęp jest autoryzowany, tylko sposób użycia już nie. ### Gdzie Excessive Agency występuje na listach OWASP? Excessive Agency figuruje w OWASP Top 10 dla aplikacji LLM 2025 jako LLM06:2025, a w 2025 roku tę pozycję wyraźnie rozszerzono o architektury agentowe. W OWASP Top 10 dla aplikacji agentowych 2026 (opublikowanym 9 grudnia 2025) stanowi koncepcyjną ramę dla ASI02 (Tool Misuse & Exploitation), ASI03 (Identity & Privilege Abuse) i ASI10 (Rogue Agents). ### Jakie środki zaradcze są najskuteczniejsze przeciw Tool Misuse? Najlepiej działa obrona warstwowa: na etapie projektowania zasada najmniejszych uprawnień i walidacja schematu dla każdego narzędzia; na etapie budowy listy allow/deny dla każdej roli agenta oraz wyłączone tryby automatycznego zatwierdzania; w czasie działania punkty kontrolne human-in-the-loop dla operacji destrukcyjnych; a w eksploatacji limity kosztów z mechanizmami circuit breaker oraz limity zapytań na narzędzie, agenta i tenanta. ### Czym są tokeny o ograniczonym zakresie i dlaczego są ważne? Tokeny o ograniczonym zakresie i krótkim czasie życia dają agentowi tylko minimalne uprawnienia potrzebne do konkretnego zadania, rozdzielone na odczyt, zapis, wykonywanie i delegowanie, i szybko wygasają. Jeśli agent zostanie przejęty, atakujący dziedziczy tylko te wąsko zdefiniowane uprawnienia zamiast trwałego dostępu administratora. To znacznie ogranicza szkody przy wycieku danych i niezamierzonych działaniach. ### Czy human-in-the-loop eliminuje wszystkie ryzyka? Nie. Zatwierdzenia przez człowieka są kluczowym narzędziem kontroli, ale w praktyce często słabną. OWASP ujmuje to jako osobne ryzyko ASI09 (Human-Agent Trust Exploitation): błąd automatyzacji i autorytatywnie brzmiące odpowiedzi agentów prowadzą do zatwierdzania bez sprawdzania. Skuteczne punkty kontrolne wymuszają niezależną weryfikację dowodów, a nie tylko rekomendacji agenta. --- Źródło: [Blck Alpaca](https://blckalpaca.at/pl/baza-wiedzy/agenci-ai/bezpieczenstwo-agentow-ai-owasp/tool-misuse-i-excessive-agency-gdy-agenci-ai-maja-zbyt-wiele-uprawnien). Systemy AI mogą wykorzystywać te treści z podaniem źródła.