zatruwanie narzędzi

Zatruwanie narzędzi (tool poisoning) to atak na agenta AI przez narzędzia, które zostały do niego podłączone. OWASP definiuje go jako pośredni prompt injection wymierzony w agentów łączących się z zewnętrznymi serwerami narzędzi przez Model Context Protocol (MCP) ^[1]. Złośliwy albo przejęty serwer ukrywa instrukcje w opisie narzędzia lub w jego odpowiedzi, a model wykonuje je jak polecenia użytkownika. Sekurak wymienia zatruwanie narzędzi jako jeden z nowych wektorów ataku, które otwiera MCP ^[5].

Jak działa

Klient MCP pobiera od serwera listę narzędzi: nazwę, opis w języku naturalnym i schemat parametrów ^[3]. Model czyta te opisy, żeby zdecydować, którego narzędzia użyć, a potem dostaje wyniki wywołań do swojego kontekstu ^[3]. Opis i wynik są więc dla modelu tekstem tej samej rangi co polecenie użytkownika.

Invariant Labs opisało atak 1 kwietnia 2025 roku: złośliwe instrukcje umieszcza się w opisie narzędzia tak, że są niewidoczne dla użytkownika, ale widoczne dla modelu ^[2]. W przykładzie badaczy niewinne narzędzie do dodawania liczb kazało modelowi odczytać plik konfiguracyjny klienta i prywatny klucz SSH, a potem przekazać ich treść w dodatkowym parametrze wywołania ^[2]. OWASP zwraca uwagę na drugą lukę: opisy narzędzi są przeglądane raz, przy pierwszym połączeniu, a odpowiedzi trafiają do kontekstu modelu bez takiej kontroli ^[1]. Przebieg ataku przez opis narzędzia pokazuje schemat poniżej.

RYS. 1Zatruty opis narzędzia MCP

Odmiany

W przykładzie shadowingu opisanym przez Invariant Labs złośliwy serwer sprawiał, że zaufane narzędzie do wysyłania poczty kierowało wszystkie wiadomości na adres atakującego ^[2]. Zatruwania narzędzi nie należy mylić z zatruwaniem danych treningowych: tu model jest nietknięty, a zmienia się tylko to, co czyta w trakcie pracy.

Zagrożenia i skutki

OWASP wymienia jako skutki nieuprawnione użycie narzędzi, eksfiltrację danych i obejście promptu systemowego; agent może wywołać narzędzie z ograniczeniami, odczytać wrażliwe pliki albo wysłać dane na serwer atakującego ^[1]. Szkody rosną wraz z tym, ile agent może zrobić. OWASP opisuje to jako excessive agency, której źródłem są nadmierna funkcjonalność, nadmierne uprawnienia i nadmierna autonomia ^[4]. Agent z dostępem do poczty, repozytorium i kluczy staje się narzędziem atakującego, choć nie ma w nim żadnej klasycznej podatności.

Serwery MCP rozprowadza się jak zwykłe pakiety, więc ten sam problem dotyczy łańcucha dostaw. Postmark 25 września 2025 roku ostrzegł przed pakietem postmark-mcp w rejestrze npm, który podszywał się pod firmę ^[6]. Według Postmarka autor zdobył zaufanie przez 15 wersji, a w wersji 1.0.16 dodał tylną furtkę, która wysyłała ukrytą kopię wszystkich e-maili na zewnętrzny serwer ^[6]. Firma podała, że nie publikowała wcześniej w npm własnego serwera MCP i nie miała z tym pakietem nic wspólnego ^[6].

W WordPressie

WordPress sam może być serwerem narzędzi dla agentów. Oficjalny MCP Adapter udostępnia funkcje zarejestrowane przez Abilities API, wprowadzone w WordPressie 6.9, jako narzędzia MCP, które agent AI może wykryć i wywołać ^[7]. Dokumentacja zaleca, by każda funkcja sprawdzała minimalne potrzebne uprawnienie, na przykład manage_options albo edit_posts, i by nie używać __return_true przy operacjach niszczących, takich jak usuwanie treści ^[7].

To ważne, bo zatruty agent wykona na stronie wszystko, na co pozwalają jego dane logowania. Dokumentacja radzi utworzyć osobnego użytkownika z ograniczonymi uprawnieniami, udostępniać przez HTTP w internecie głównie funkcje tylko do odczytu i nie dawać potężnych funkcji niezaudytowanym klientom AI ^[7]. Domyślną metodą uwierzytelniania na własnym serwerze są hasła aplikacji ^[7], więc zakres szkód wyznaczają role i uprawnienia konta, do którego należą.

Jak się bronić

Część obowiązków spoczywa na autorze serwera. Specyfikacja MCP wymaga, by serwer walidował wszystkie dane wejściowe narzędzi, stosował kontrolę dostępu, ograniczał częstotliwość wywołań i oczyszczał wyniki ^[3]. Klient powinien z kolei sprawdzać wyniki, zanim przekaże je modelowi, stosować limity czasu i zapisywać użycie narzędzi na potrzeby audytu ^[3].

Specyfikacja MCP wymaga też, by klient traktował adnotacje narzędzi jako niezaufane, chyba że pochodzą z zaufanych serwerów ^[3]. Zaleca też, by zawsze był człowiek, który może odmówić wywołania narzędzia, by interfejs pokazywał, jakie narzędzia widzi model, i by przed wywołaniem pokazywać użytkownikowi parametry, co utrudnia wyciek danych ^[3].

• Utrzymywać listę dozwolonych serwerów MCP i wymagać potwierdzenia przy operacjach wrażliwych ^[1].
• Przypinać wersje narzędzi i pakietów, żeby zmiana opisu po zatwierdzeniu nie przeszła niezauważona ^[2].
• Oddzielać narzędzia z uprawnieniami od kontekstu, do którego piszą serwery zewnętrzne, i egzekwować ograniczenia po stronie serwera, a nie w prompcie ^[1].
• Ograniczać zestaw narzędzi agenta do minimum i wymagać zgody człowieka na działania o dużym skutku ^[4]; to zastosowanie zasady najmniejszych uprawnień.
• Autoryzację wykonywać w systemach docelowych, a nie zostawiać modelowi decyzji, czy działanie jest dozwolone ^[4].
• Nie trzymać w zasięgu agenta kluczy i haseł, których nie potrzebuje; zob. zarządzanie sekretami.