Zatruwanie narzędzi: gdy narzędzia agenta zwracają się przeciw niemu
Jak podmienione opisy narzędzi i spreparowane wyniki kierują autonomicznych agentów ku szkodliwym działaniom — i kontrole walidacji, izolacji oraz pochodzenia, które temu zapobiegają.
Definicja
Zatruwanie narzędzi (tool poisoning) to atak, który kompromituje narzędzia, na których polega agent AI — lub ich wyniki — tak by podejmował szkodliwe decyzje. Obejmuje podmienione opisy narzędzi, złośliwe lub przejęte API oraz spreparowane odpowiedzi kierujące agenta ku niebezpiecznym akcjom.
Agent z założenia ufa swoim narzędziom — po to mu je dajemy. Zatruwanie narzędzi przekuwa to zaufanie w broń. Zamiast atakować to, co agent czyta, atakujący atakuje to, czego agent używa.
Dwie powierzchnie: opisy i wyniki
Zatruwanie narzędzi ma dwa punkty wejścia.
Opisy narzędzi. Agent często wybiera narzędzie na podstawie opisu. Jeśli opis jest kontrolowany przez atakującego lub podmieniony — częste ryzyko przy zewnętrznych serwerach MCP — atakujący może zafałszować wybór narzędzia albo ukryć instrukcje w metadanych czytanych podczas planowania.
Wyniki narzędzi. Cokolwiek narzędzie zwraca, staje się kontekstem, na którym agent działa. Przejęte API albo legalne zwracające dane pod wpływem atakującego może dostarczyć injection kanałem, któremu agent z założenia ufa.
Dwie powierzchnie i ich kontrole obok siebie:
| Powierzchnia ataku | Jak jest nadużywana | Typowe źródło | Główna kontrola |
|---|---|---|---|
| Opis narzędzia | Fałszuje wybór narzędzia lub ukrywa instrukcje w metadanych | Zewnętrzne serwery MCP, rejestry narzędzi | Przypinanie, wersjonowanie i podpis definicji; przegląd zmian |
| Wynik narzędzia | Zwraca spreparowane dane działające jak injection | Przejęte lub kontrolowane przez atakującego API | Walidacja i sprawdzanie typów; traktowanie jako niezaufane dane |
Dlaczego to groźne?
Cała architektura zakłada, że narzędzia są wiarygodne. Obrona dostrojona do wejścia użytkownika nie pilnuje warstwy narzędzi, więc zatruty wynik często przychodzi nieprzesiany — a ponieważ agent mu ufa, płynie prosto ku akcji. W połączeniu z nadmiernymi uprawnieniami jedna zatruta odpowiedź może wyzwolić operację nieodwracalną.
Obrona, która działa
- Traktuj wyniki narzędzi jako niezaufane dane, nigdy jako instrukcje. Waliduj, sprawdzaj typy i ograniczaj to, co wraca.
- Przypinaj i przeglądaj opisy narzędzi. Nie pozwól, by zewnętrzne serwery po cichu zmieniały, co narzędzie deklaruje; wersjonuj i podpisuj definicje, gdzie się da.
- Izoluj wykonanie. Uruchamiaj narzędzia w piaskownicach, by złośliwe narzędzie nie sięgnęło poza swój zakres.
- Minimalne uprawnienia. Zatrute narzędzie do streszczeń nie może płacić ani usuwać — zawęź każde narzędzie ściśle.
- Monitoruj traces. Wypatruj wyników nagle zawierających język rozkazujący lub wyzwalających nietypowe wywołania następcze; obserwowalność jest Twoją detekcją.
Zasada
Zaufanie do narzędzi powinno być ograniczone, nie zakładane. Daj każdemu narzędziu najmniejszy potrzebny dostęp, weryfikuj to, co zwraca, i trzymaj człowieka w pętli przy czymkolwiek nieodwracalnym — ta sama obrona w głąb, którą zaleca OWASP Top 10 dla aplikacji agentowych. Pojęcia są w słowniku.
Najczęstsze pytania
Czym zatruwanie narzędzi różni się od prompt injection?
Prompt injection sadzi instrukcje w treści, którą agent czyta — stronie, dokumencie; zatruwanie narzędzi atakuje samą warstwę narzędzi, czyli opis mówiący agentowi, co narzędzie robi, albo wynik, który ono zwraca. Różnica jest istotna, bo oba docierają innymi kanałami i wymagają innej obrony. Injection jedzie w danych, które agent pobrał; zatruwanie narzędzi jedzie kanałem, któremu agent z założenia ufa, i właśnie to czyni je skutecznym. Zatruty wynik narzędzia to w istocie injection dostarczony tylnymi drzwiami: obrona dostrojona do przesiewania wejścia użytkownika nigdy nie zagląda w to, co zwraca API. W praktyce ataki się nakładają i łączą — zatrute narzędzie może nieść injection, a injection może skierować agenta ku złośliwemu narzędziu — więc traktuj jako niezaufane zarówno opisy, jak i wyniki narzędzi, nie tylko prompt użytkownika.
Czym jest zatruty opis narzędzia?
Agent decyduje, które narzędzie wywołać, częściowo na podstawie jego opisu — metadanych w języku naturalnym mówiących, co narzędzie robi i kiedy go użyć. Zatruty opis to taki, który atakujący kontroluje lub podmienił, a działa na dwa sposoby. Może zafałszować wybór narzędzia, popychając agenta do wywołania niewłaściwego albo użycia groźnego do błahego zadania. Albo może przemycić instrukcje w same metadane, tak że już samo przeczytanie katalogu dostępnych narzędzi wstrzykuje polecenia do planowania agenta. To szczególne ryzyko przy zewnętrznych serwerach MCP, gdzie definicje narzędzi pochodzą spoza Twojej granicy zaufania i mogą zmienić się po cichu między wywołaniami. Obrona to przypinanie definicji do znanych wersji, przegląd zmian przed ich przyjęciem i podpisywanie definicji tam, gdzie platforma na to pozwala, by opis nie mógł się zmienić Ci pod ręką.
Jak się bronić?
Traktuj wszystko, co produkuje warstwa narzędzi, jako niezaufane — tak samo jak treść pobraną z otwartego internetu. Waliduj i sprawdzaj typy wyników narzędzi oraz ograniczaj je do oczekiwanych kształtów, zamiast wpuszczać surowe odpowiedzi prosto z powrotem do kontekstu agenta. Przypinaj i przeglądaj opisy narzędzi, by zewnętrzny serwer nie zmienił po cichu, co narzędzie deklaruje, i wersjonuj lub podpisuj definicje, gdzie się da. Izoluj wykonanie narzędzi w piaskownicach, by złośliwe narzędzie nie sięgnęło poza swój zakres. Stosuj minimalne uprawnienia, tak by nawet w pełni zatrute narzędzie nie wyzwoliło działania o dużym skutku — agent streszczający nie może płacić ani usuwać. Na koniec monitoruj traces pod kątem wyników nagle zawierających język rozkazujący lub wyzwalających nietypowe wywołania następcze. Żadna pojedyncza kontrola nie wystarczy; chodzi o warstwowe ograniczanie, by jedno zatrute narzędzie nie sięgnęło niczego nieodwracalnego.
Czy zewnętrzne narzędzia MCP są bezpieczne?
Da się ich używać, ale nie są bezpieczne domyślnie — każdy zewnętrzny serwer MCP traktuj jako niezaufaną infrastrukturę, nie zaufane rozszerzenie agenta. Ryzyko polega na tym, że i opisy, i wyniki narzędzi pochodzą spoza Twojej kontroli, więc serwer może pokazać nieszkodliwy opis, przejść Twój przegląd, a później zwracać spreparowane dane albo zmienić definicję między wywołaniami. To nie znaczy, że ich unikać; ekosystem jest zbyt użyteczny. Znaczy to opakować je w kontrole, które stosujesz do każdej niezaufanej zależności: przypnij konkretne wersje, przejrzyj zakresy, o które prosi każde narzędzie, uruchom je z minimalnymi uprawnieniami i waliduj wyniki. Przy czymkolwiek nieodwracalnym zostaw punkt akceptacji człowieka między narzędziem a akcją. Wygoda zewnętrznego narzędzia nigdy nie jest warta oddania mu niezawężonego dostępu do produkcji.