Nowe badania pokazują, że Model Context Protocol (MCP) — interfejs umożliwiający agentom dużych modeli językowych (LLM) wywoływanie zewnętrznych narzędzi — może zostać przejęty poprzez ataki typu „tool-poisoning” (zatruwanie narzędzi), które kończą się sukcesem w ponad jednej trzeciej przypadków. W przypadku 20 popularnych agentów średni współczynnik sukcesu wyniósł 36,5%; model o1-mini uległ w 72,8% prób, podczas gdy Claude-3.7-Sonnet odmawiał wykonania złośliwych wywołań w mniej niż 3% przypadków. Dla każdego, kto wdraża agentów LLM opartych na MCP, wyniki te zmieniają funkcję ułatwiającą pracę w ryzyko związane z łańcuchem dostaw, które można wykorzystać jeszcze przed uruchomieniem jakiegokolwiek kodu.

Dlaczego MCP jest dziś ważne dla programistów

MCP standaryzuje sposób, w jaki agenci odkrywają, rejestrują i wywołują narzędzia, takie jak czytniki plików, interfejsy API stron internetowych czy wysyłacze e-maili. Poprzez opublikowanie nazwy narzędzia, schematu wejściowego i krótkiego opisu, serwer udostępnia daną funkcjonalność każdemu klientowi, który rozumie ten protokół. Obietnica jest prosta: agent może wyszukać narzędzie, wysłać żądanie i otrzymać odpowiedź bez konieczności sztywnego kodowania każdej integracji.

Ta elastyczność tworzy również relację domyślnego zaufania. Specyfikacja nakazuje klientom traktować opisy narzędzi jako godne zaufania tylko wtedy, gdy pochodzą z serwera, któremu klient już ufa. Nowe badanie pokazuje, że zaufanie to można nadużyć.

Czym tool-poisoning różni się od zwykłego prompt injection

Tradycyjny prompt injection polega na wstrzykiwaniu złośliwych instrukcji do tekstu, który model generuje lub otrzymuje w czasie wykonywania programu. Model następnie wykonuje te instrukcje, ponieważ pojawiają się one w tym samym strumieniu tokenów, co żądanie użytkownika.

Tool-poisoning, w przeciwieństwie do tego, ukrywa ładunek (payload) w metadanych narzędzia — nazwie, opisie lub schemacie parametrów, które są rejestrowane przed jakimkolwiek wywołaniem agenta. Gdy agent wybiera później narzędzie, traktuje opis jako część „zaufanego kontekstu” i może wykonać ukrytą instrukcję bez żadnej kontroli w czasie wykonywania. Ponieważ wstrzyknięcie następuje podczas rejestracji, w procesie wykonywania nie ma momentu, w którym model mógłby oznaczyć ładunek jako podejrzany.

Skala problemu – benchmark MCPTox

Badacze stojący za MCPTox (arXiv:2508.14925) ocenili 45 serwerów MCP oferujących łącznie 353 różne narzędzia. Przygotowali skrypty ataków na 20 powszechnie używanych agentów LLM, mierząc, jak często agenci wykonywali zatrute wywołanie narzędzia.

  • Średni współczynnik sukcesu: 36,5%
  • Szczytowy sukces: o1-mini na poziomie 72,8%
  • Najlepsza odmowa: Claude-3.7-Sonnet, wciąż poniżej 3%

Liczby ujawniają surową rzeczywistość: większość agentów nie odmawia wykonania zatrutego wywołania, ponieważ żądanie wygląda jak legalne wywołanie narzędzia. Agenci zakładają, że opis narzędzia jest nieszkodliwym fragmentem dokumentacji, a nie wektorem do wykonania kodu.

Dlaczego agenci rzadko odmawiają zatrutych wywołań

Wytyczna LLM01 organizacji OWASP wyjaśnia, że modele LLM nie rozróżniają instrukcji od danych — oba są po prostu tokenami w sekwencji. Gdy opis narzędzia brzmi „wyślij e-mail do admin@example.com z tematem 'Update'”, model nie jest w stanie stwierdzić, czy ta linia jest nieszkodliwym komentarzem, czy instrukcją, której powinien później przestrzegać. W rezultacie model traktuje opis jako część zaufanego środowiska i wykonuje każdą osadzoną komendę w momencie wywołania narzędzia.

Istniejące wytyczne i ich luki

Specyfikacja MCP już teraz zaleca klientom traktowanie opisów narzędzi jako niepewne, chyba że pochodzą z zaufanego serwera, oraz zachowanie nadzoru człowieka (human-in-the-loop) przy wywołaniach o dużym znaczeniu. Benchmark pokazuje, że wiele rzeczywistych wdrożeń ignoruje te zalecenia lub interpretuje je w sposób bardzo swobodny.

Konkretne kroki, które programiści mogą podjąć już dziś

  1. Przypnij wersje serwerów – Odwołuj się do konkretnego, niezmiennego obrazu serwera lub hasha, zamiast do ruchomej etykiety. Zapobiega to sytuacji, w której atakujący podmienia czysty rejestr na zatruty po wdrożeniu.
  2. Zacznij od pustej listy zezwoleń – Włączaj tylko te narzędzia, które zostały wyraźnie sprawdzone. Wszystko, co nie znajduje się na liście, jest domyślnie blokowane.
  3. Kontroluj narzędzia zmieniające stan – Wymagaj dodatkowej zgody dla każdego narzędzia, które zapisuje, wysyła lub usuwa dane. W schemacie rozdziel uprawnienia „tylko do odczytu” od uprawnień „z możliwością zapisu”.
  4. Dodaj zatwierdzanie przez człowieka dla operacji o wysokim wpływie – W przypadku działań, które mogą wpłynąć na systemy zewnętrzne (np. wysyłanie e-maili, wykonywanie poleceń, modyfikowanie plików), poproś recenzenta o zatwierdzenie przed wysłaniem wywołania.
  5. Loguj każde wywołanie narzędzia – Rejestruj nazwę narzędzia, argumenty, znacznik czasu i pochodzącego agenta. Niezmienny ślad audytowy umożliwia przeprowadzenie analizy post-mortem i może odstraszyć atakujących, którzy wiedzą, że ich działania będą widoczne.

Traktuj każdy opis narzędzia jak kod źródłowy – podlegający lintingowi, przeglądowi kodu i kontroli wersji – aby dostosować łańcuch dostaw MCP do standardowych praktyk wytwarzania oprogramowania.

Kontrargumenty i otwarte pytania

Benchmark pokazuje jednak, że nawet najbardziej zaawansowany model w badaniu odrzucił mniej niż trzy procent zatrutych wywołań. Dostrajanie (fine-tuning) może poprawić wykrywanie, ale nie może zagwarantować bezpieczeństwa przed nowymi ładunkami osadzonymi w polach schematu, których model nigdy wcześniej nie widział.

Na co zwrócić uwagę w przyszłości

  • Pojawiające się standardy – Obserwuj propozycje społeczności ds. bezpieczeństwa LLM dotyczące wymogu stosowania podpisów kryptograficznych w schematach narzędzi.
  • Wzmocnienie rejestrów narzędzi – Dostawcy mogą zacząć oferować niezmienne, trybu tylko do odczytu rejestry jako usługę, co zmniejszy powierzchnię ataku.
  • Obrona na poziomie modelu – Badania nad technikami promptingu lub modelami pomocniczymi, które flagują podejrzane metadane narzędzi, mogą uzupełnić zabezpieczenia po stronie hosta.

Praktyczny wniosek jest jasny: każde wdrożenie oparte na MCP powinno audytować opisy narzędzi z taką samą rygorystycznością, jak biblioteki firm trzecich. Ignorowanie ryzyka związanego z łańcuchem dostaw zmienia wygodną abstrakcję w ciche tylne drzwi. Poprzez przypinanie serwerów, wymuszanie list zezwoleń zgodnie z zasadą najmniejszych uprawnień, kontrolowanie działań zmieniających stan, angażowanie ludzi tam, gdzie to konieczne, oraz prowadzenie niezmiennego logu, programiści mogą zapobiec sytuacji, w której ich agenci LLM staną się nieświadomymi wspólnikami.