Prompt injection przez serwery MCP: scenariusze i zabezpieczenia

Skąd bierze się podatność MCP na prompt injection

Prompt injection przez MCP działa, bo model dostaje polecenie użytkownika, opisy narzędzi i wyniki ich wywołań jako jeden ciąg tokenów. Brytyjskie NCSC w tekście z grudnia 2025 ujmuje to tak: model nie ma wewnętrznego rozdziału danych od instrukcji, jest z natury podatny na pomylenie, a prompt injection może nigdy nie zostać całkowicie usunięty. Autor radzi traktować model jak zastępcę, którego można oszukać, a więc ograniczać skutki, zamiast liczyć na wyeliminowanie ataku.

MCP wnosi do tego dwie rzeczy. Dzięki niemu łatwo połączyć w jednym agencie narzędzia z różnych źródeł, na co zwraca uwagę Simon Willison, opisując lethal trifecta, czyli niebezpieczne połączenie trzech cech agenta: dostęp do danych prywatnych, kontakt z niezaufaną treścią i możliwość komunikacji na zewnątrz. Dochodzi kanał metadanych, bo serwer sam dostarcza tekst, który model czyta jako instrukcję obsługi. OWASP ujmuje oba zagrożenia w liście MCP Top 10 (status beta) jako MCP03 Tool Poisoning i MCP06 Prompt Injection via Contextual Payloads.

Czym jest tool poisoning w MCP?

Tool poisoning, pokazany przez Invariant Labs w kwietniu 2025, to atak, w którym serwer MCP wystawia niewinne narzędzie, a w opisie ukrywa polecenie, by przed wywołaniem przeczytać lokalny plik z sekretami i przekazać go w argumencie. Użytkownik widział proste podsumowanie, a model pełny opis. Atak wymaga złośliwego serwera, więc najlepiej działa na niego dobór serwerów, oraz to, czy klient pokazuje cały opis i pełne argumenty.

W tej samej publikacji opisano wariant shadowing. Opis narzędzia z jednego serwera zmienia użycie narzędzia z innego, zaufanego. W teście z Cursorem agent wysyłał wszystkie maile do atakującego, nawet gdy użytkownik podał innego odbiorcę. W logu zaufanego serwera widać wtedy tylko poprawne wywołanie, a przyczyna leży gdzie indziej. Izolacja serwerów w architekturze MCP dotyczy procesów i danych, natomiast w kontekście modelu wszystkie opisy lądują obok siebie.

Czym jest rug pull w MCP?

Rug pull, opisany przez Invariant Labs, polega na tym, że serwer MCP może zmienić opis narzędzia już po tym, jak klient go zatwierdził. Specyfikacja dopuszcza zmiany listy narzędzi i przewiduje powiadomienie notifications/tools/list_changed (na poziomie SHOULD), a rozdział o narzędziach nie wymaga ponownego zatwierdzenia po zmianie opisu. Autorzy zalecają klientom przypinanie wersji oraz sumę kontrolną opisów. Jeśli twój klient tego nie robi, sprawdzanie musi odbywać się poza nim, w bramie lub cyklicznym zadaniu porównującym wynik tools/list ze wzorcem.

Prompt injection przez dane z uczciwego serwera MCP

Prompt injection przez dane nie wymaga złośliwego serwera MCP, bo złośliwa jest tylko treść. W maju 2025 Invariant pokazało scenariusz z oficjalnym serwerem GitHub. Atakujący zakłada zgłoszenie w publicznym repozytorium z instrukcją dla agenta. Użytkownik prosi o przejrzenie otwartych zgłoszeń, a agent z tokenem obejmującym również repozytoria prywatne czyta dane o prywatnym projekcie i publikuje je w pull requeście w repozytorium publicznym. Autorzy piszą, że błąd nie leży w kodzie serwera GitHub i że łatka po stronie serwera tego nie rozwiąże. Wskazują też, że Claude Desktop domyślnie pyta o potwierdzenie każdego wywołania, ale wielu użytkowników agentów wybiera Always Allow i przestaje śledzić pojedyncze działania.

General Analysis w lipcu 2025 odtworzyło podobny schemat z Supabase. Klient umieszcza instrukcję w zgłoszeniu do działu wsparcia. Programista przegląda zgłoszenia w Cursorze, a asystent działa z rolą service_role, która omija row-level security. Czyta tabelę integration_tokens i wpisuje jej zawartość do tego samego wątku, gdzie atakujący ją odczytuje. Dane w teście były fikcyjne, a demonstracji nie powtórzono na obecnym serwerze. Wniosek tego tekstu, nie wynik testu: ten sam wzorzec dotyczy CRM-u, skrzynki pocztowej i każdego innego pola, które wypełnia ktoś z zewnątrz.

Jak zabezpieczyć agenta przed prompt injection przez MCP?

Agents Rule of Two, reguła opublikowana przez Metę w październiku 2025, mówi, że w jednej sesji agent może mieć najwyżej dwie z trzech cech: przetwarzanie niezaufanych danych, dostęp do systemów wrażliwych lub prywatnych danych, możliwość zmiany stanu lub komunikacji na zewnątrz. Jeśli zadanie wymaga wszystkich trzech, agent nie powinien działać samodzielnie. Autorzy zastrzegają, że to uzupełnienie innych zasad i że nawet zgodny projekt może zawieść, gdy użytkownik odruchowo potwierdzi ostrzeżenie. Regułę łatwo zastosować, bo daje odpowiedź tak lub nie dla konkretnego przepływu. To ocena tego tekstu.

NCSC formułuje to podobnie: model przetwarzający niezaufaną treść nie powinien mieć uprawnionych narzędzi, a jego uprawnienia mają spaść do poziomu najmniej zaufanej strony, której treść czyta. Takie ograniczenia przerwałyby oba scenariusze z danymi, ale to wniosek, nie wynik testu. Poniższe środki nie zależą od zachowania modelu:

• Rozdzielenie sesji: przegląd publicznych zgłoszeń odbywa się bez dostępu do repozytoriów prywatnych, a wynik przechodzi do drugiej sesji jako krótkie, ustrukturyzowane dane.
• Token ograniczony do zadania: jedno repozytorium, jeden projekt bazy, rola tylko do odczytu. Trzeba pamiętać, że read-only chroni przed zapisem, a nie przed odczytem i wynosem danych, do których rola ma dostęp.
• Kontrola wyjścia: lista dozwolonych miejsc dla ruchu wychodzącego i wyłączenie narzędzi publikujących w sesjach czytających treści z zewnątrz.
• Polityka po stronie deterministycznej: reguła w bramie albo kliencie, na przykład jeden wątek jedno repozytorium, sprawdzana kodem poza modelem.
• Sprawdzanie zmian w opisach narzędzi i zatwierdzone wersje serwerów.

Co nie wystarcza przeciw prompt injection

Filtry wejścia przeciw prompt injection są co najwyżej dodatkiem. NCSC odradza czarne listy fraz, bo atakujący przeformułuje polecenie, a oznaczanie treści zewnętrznej tagami XML jedynie utrudnia atak. Willison zwraca uwagę w tekście z czerwca 2025, że 95 procent skuteczności deklarowane przez dostawców w bezpieczeństwie aplikacji webowych byłoby wynikiem niezaliczonym. Dotyczy to również funkcji guardrails w bramach, które deklaruje na przykład agentgateway. Mogą wyłapać znane wzorce i dać sygnał w logach, ale nie mogą być jedyną barierą przy danych wrażliwych.

Specyfikacja nakłada na serwer obowiązek sanityzacji wyjścia, a klientowi zaleca walidację wyników przed przekazaniem ich do modelu. Oba punkty są potrzebne, ale nie rozstrzygają sprawy. Zgłoszenie z GitHuba czy wątek wsparcia to poprawny tekst, a serwer nie ma jak odróżnić zdania od klienta od instrukcji dla agenta. Dokumentacja Claude Code ostrzega podobnie: serwery pobierające treści z zewnątrz narażają na prompt injection. Takie serwery trzeba więc oznaczyć w rejestrze jako źródło niezaufanych danych.

Potwierdzanie przez człowieka też ma granice. Specyfikacja zaleca człowieka w pętli, a Cursor domyślnie prosi o zgodę, ale Meta zastrzega, że użytkownik może odruchowo potwierdzić ostrzeżenie, a Invariant pisze o użytkownikach Always Allow, którzy przestają śledzić pojedyncze działania. Zatwierdzanie zarezerwuj dla kilku działań o wysokiej stawce i pokazuj pełne argumenty, bo specyfikacja wprost zaleca to jako ochronę przed wyciekiem. Reszta ma być uniemożliwiona konfiguracją uprawnień. Na koniec zostaje detekcja: NCSC zaleca logowanie wejść, wyjść i wywołań, a także obserwowanie nieudanych wywołań, które mogą oznaczać, że ktoś sondował agenta.

Powiązane materiały

• Czym jest MCP i kiedy firma go nie potrzebuje
• Serwer MCP w produkcji: lista kontrolna przed dopuszczeniem
• MCP gateway i rejestr serwerów: budować czy kupić

Źródła

• NCSC: Prompt injection is not SQL injection
• Simon Willison: The lethal trifecta for AI agents
• Invariant Labs: MCP Security Notification, Tool Poisoning Attacks
• Invariant Labs: atak na serwer GitHub MCP
• General Analysis: demonstracja wycieku przez Supabase MCP
• Meta AI: Agents Rule of Two
• Model Context Protocol: Tools
• Model Context Protocol: Architecture
• OWASP: MCP Top 10
• Cursor Docs: Model Context Protocol
• agentgateway
• Claude Code Docs: Connect Claude Code to tools via MCP