Tool output poisoning: jak narzędzie przejmuje agenta AI

Tool output poisoning występuje, gdy wynik API, MCP, CLI lub wyszukiwarki zawiera instrukcję wpływającą na następny krok agenta. Model widzi odpowiedź jako observation, ale może potraktować ją jak polecenie o wyższym priorytecie.

Źródła ataku

Złośliwy tekst może znajdować się w nazwie pliku, opisie issue, rekordzie bazy, stderr, tool description albo komunikacie błędu. Atakujący nie musi kontrolować użytkownika — wystarczy, że kontroluje dane odczytane przez narzędzie.

Strukturyzuj wynik

Narzędzie powinno zwracać mały schemat JSON z typami, provenance i klasyfikacją zaufania. Usuń HTML, aktywny Markdown i niepotrzebne pola. Duży tekst przetwarzaj przez odizolowany komponent bez narzędzi.

Nie przekazuj surowego stderr do modelu uprzywilejowanego. Zmapuj błąd na kod i bezpieczny opis.

Autoryzacja następnego kroku

Porównaj proponowaną akcję z pierwotnym celem użytkownika, a nie z ostatnią observation. Validator sprawdza tool, parametry, zasób i odbiorcę. Nowa domena lub scope wymaga ponownego zatwierdzenia.

Testy

Wstrzykuj „ignore previous”, fałszywe reasoning, link exfiltracyjny i złośliwe parametry w każdym polu odpowiedzi. Sprawdź wieloetapowy łańcuch oraz drugi agent odbierający wynik.

OWASP nazywa ten wzorzec thought/observation injection i tool poisoning. W środowisku MCP połącz kontrolę z hardeningiem MCP.

Dlaczego wynik narzędzia jest wejściem niezaufanym

API, serwer MCP, wyszukiwarka i parser dokumentu zwracają dane kontrolowane częściowo przez podmiot zewnętrzny. Nawet poprawny JSON może zawierać tekst nakłaniający model do ujawnienia sekretu, zmiany celu lub uruchomienia następnego narzędzia. Podpis transportu potwierdza źródło, lecz nie czyni treści bezpieczną instrukcją.

Orkiestrator powinien oznaczać pochodzenie każdego pola oraz oddzielać dane od instrukcji sterujących. Model może analizować wynik, ale decyzję o następnej akcji podejmuje warstwa polityki na podstawie tożsamości, celu zadania, dozwolonego narzędzia i schematu argumentów. Tekst zwrócony przez narzędzie nie może tworzyć nowych uprawnień.

Walidacja i redukcja danych

Weryfikuj strukturę odpowiedzi, typy, długości, kodowanie i dopuszczalne wartości. Odrzucaj nadmiarowe pola, aktywny HTML oraz nieoczekiwane URI. Jeśli agent potrzebuje tylko statusu i identyfikatora, nie przekazuj mu całej odpowiedzi zawierającej komentarze i metadane. Redukcja kontekstu zmniejsza powierzchnię injection oraz ryzyko przypadkowego ujawnienia.

Przed akcją wysokiego wpływu zbuduj nowy, zaufany obiekt parametrów. Nie kopiuj bezpośrednio polecenia, ścieżki lub adresu z tekstowej obserwacji. Wymagaj zgodności originu, scope oraz jawnego potwierdzenia, gdy zmienia się odbiorca danych.

Macierz testów regresyjnych

Umieść złośliwą treść w wartości, nazwie pola, komunikacie błędu, paginacji, opisie narzędzia i odpowiedzi strumieniowej. Sprawdź, czy działa po streszczeniu, zapisaniu do pamięci i przekazaniu drugiemu agentowi. Testuj także konflikt między dwoma narzędziami oraz poprawną odpowiedź zawierającą link do nowej domeny.

Loguj surowe źródło w chronionym magazynie dowodowym, ale do modelu przekazuj znormalizowaną reprezentację. Alert powinien pokazać, która obserwacja poprzedziła odrzuconą akcję i jaka reguła polityki zadziałała.

Bezpieczne łączenie wielu agentów

W systemie wieloagentowym nie przekazuj swobodnego transcriptu jako zaufanego polecenia. Agent nadawca zwraca wynik zgodny ze schematem, identyfikator zadania, provenance i deklarowany poziom pewności. Agent odbiorca dostaje dane, lecz jego własna polityka ponownie ocenia każdą akcję.

Delegacja nie przenosi automatycznie uprawnień. Jeżeli agent badawczy może czytać internet, a agent wdrożeniowy ma dostęp do repozytorium, wynik pierwszego nie może stać się komendą drugiego. Potrzebna jest kontrolowana granica, która redukuje dane i wymusza nową autoryzację.

Reakcja na wykryte zatrucie

Zatrzymaj dalsze wywołania zależne od skażonego wyniku i oznacz cały trace. Ustal źródłowy serwer, wersję narzędzia, pola przekazane modelowi oraz wszystkie akcje podjęte później. Unieważnij cache i pamięć, do których wynik mógł zostać zapisany.

Po incydencie dodaj dokładny payload do regresji, ale również warianty semantyczne i inne miejsca osadzenia. Poprawka polegająca na blokadzie jednego zdania jest krucha. Skuteczna zmiana ogranicza przepływ uprawnień niezależnie od brzmienia treści.

Właściciel każdego narzędzia powinien publikować kontrakt danych i sposób zgłaszania nieoczekiwanej odpowiedzi. Zmiana schematu, nowy typ pola albo rozszerzenie opisu narzędzia uruchamia testy bezpieczeństwa tak samo jak zmiana kodu executora. To ogranicza ryzyko, że zwykła aktualizacja integracji utworzy nowy kanał instrukcji.

Źródła: OWASP Prompt Injection Prevention, OWASP MCP Security.