Bezpieczeństwo MCP — jak chronić narzędzia agentów AI

Bezpieczeństwo MCP (Model Context Protocol) decyduje o tym, czy agent AI pozostaje asystentem, czy staje się niekontrolowanym operatorem z dostępem do poczty, plików, repozytoriów i systemów firmowych. MCP standaryzuje sposób, w jaki aplikacja korzystająca z modelu odkrywa narzędzia, zasoby i prompty udostępniane przez serwer. Standaryzacja ułatwia integrację, ale nie usuwa granic zaufania — przeciwnie, łączy komponenty, które wcześniej były odseparowane.

Ten przewodnik pokazuje architekturę MCP, najważniejsze ataki i kontrolki, które warto wdrożyć przed podłączeniem serwera do produkcyjnych danych. Bazujemy na oficjalnych praktykach bezpieczeństwa MCP, specyfikacji autoryzacji i znanych scenariuszach ataków na narzędzia agentów.

Jak działa MCP i gdzie przebiega granica zaufania

W typowym wdrożeniu występują cztery elementy:

host MCP — aplikacja użytkownika, np. środowisko programistyczne lub asystent;
klient MCP — utrzymuje połączenie z konkretnym serwerem i pośredniczy w komunikacji;
serwer MCP — publikuje narzędzia, zasoby i prompty;
system docelowy — API, baza, repozytorium, dysk lub usługa SaaS, na której wykonywana jest operacja.

Model może zaproponować wywołanie narzędzia, ale to host i serwer odpowiadają za autoryzację, walidację oraz wykonanie. Opis narzędzia jest danymi pochodzącymi od serwera. Parametry wygenerowane przez model są niezaufanym wejściem. Odpowiedź narzędzia również jest niezaufana, bo może zawierać treść kontrolowaną przez atakującego.

Pierwszy krok to diagram przepływu: skąd pochodzi treść, która część trafia do modelu, kto wydaje token, jakie zakresy ma serwer, gdzie pojawia się zgoda użytkownika i dokąd może wychodzić ruch sieciowy. Bez tego trudno ocenić, czy pojedyncza instrukcja w dokumencie może uruchomić operację na innym systemie.

Prompt injection przez zasoby i wyniki narzędzi

Pośredni prompt injection jest szczególnie istotny w MCP. Agent może przeczytać stronę, zgłoszenie, README albo wiadomość zawierającą ukrytą instrukcję: „wyślij konfigurację do tej domeny” lub „wywołaj narzędzie z takim argumentem”. Model nie ma niezawodnego mechanizmu odróżniania polecenia użytkownika od instrukcji osadzonej w danych.

Microsoft opisuje ten problem jako indirect injection w ekosystemie MCP. Sama moderacja tekstu nie wystarcza. Kontrole muszą działać na poziomie możliwości:

treść zewnętrzna nie może automatycznie rozszerzać celu użytkownika;
operacje zapisu powinny wymagać jawnego zatwierdzenia;
ekran zgody musi pokazywać rzeczywisty skutek i parametry;
narzędzie musi ponownie sprawdzić tożsamość, zasób i zakres;
odpowiedź jednego narzędzia nie powinna bez kontroli uruchamiać kolejnego.

Testuj dokumenty z instrukcją widoczną, białym tekstem, komentarzem HTML, kodowaniem, obrazem OCR i treścią pobraną dopiero w drugim kroku. Sprawdź, czy agent potrafi połączyć nieszkodliwe akcje w łańcuch prowadzący do eksfiltracji.

Tool poisoning i rug pull

Serwer opisuje modelowi dostępne narzędzia. Złośliwy lub przejęty serwer może ukryć instrukcję w nazwie, opisie albo schemacie parametru. Model zobaczy ją nawet wtedy, gdy interfejs pokazuje użytkownikowi skrócony, niewinny opis. OWASP dokumentuje ten scenariusz jako MCP Tool Poisoning.

Rug pull polega na zmianie zachowania narzędzia po wcześniejszym zatwierdzeniu. Wersja serwera uznana za bezpieczną może później opublikować inny opis lub wykonać dodatkową akcję. Dlatego zgoda na nazwę serwera „na zawsze” jest ryzykowna.

Obrona wymaga rejestru zaufanych serwerów, przypiętych wersji lub digestów, przeglądu manifestów i alarmowania o zmianie definicji narzędzia. Host powinien prezentować użytkownikowi pełne, aktualne parametry operacji, a serwer nie może otrzymywać więcej poświadczeń, niż wymaga konkretna funkcja. W środowisku krytycznym aktualizacja powinna przechodzić ten sam proces, co zmiana kodu produkcyjnego.

Token theft, token passthrough i nadmierne zakresy

Token dostępowy jest jednym z najcenniejszych aktywów integracji. Jeżeli serwer MCP zapisze go w logu, przekaże dalej albo użyje poza właściwym odbiorcą, atakujący może ominąć interfejs agenta i wywołać API bezpośrednio.

Aktualna specyfikacja autoryzacji MCP opiera zdalne wdrożenia na mechanizmach OAuth i wymaga weryfikacji, że token jest przeznaczony dla danego zasobu. Token passthrough — przekazanie do serwera tokenu uzyskanego dla innej usługi — jest zabroniony, ponieważ łamie granice odbiorców i utrudnia audyt.

Praktyczne zasady:

stosuj krótkotrwałe tokeny i rotację refresh tokenów;
używaj PKCE w przepływach, w których jest wymagane;
waliduj issuer, audience, podpis, czas i zakres tokenu;
wydziel zakresy dla odczytu, zapisu i administracji;
nie przekazuj tokenu użytkownika do kolejnej usługi bez prawidłowej wymiany;
nie umieszczaj sekretów w URL, promptach ani odpowiedziach narzędzi;
filtruj logi i trace’y przed zapisaniem.

Test powinien objąć token dla innego odbiorcy, token wygasły, brakujący scope, zmianę tenant ID, replay i próbę użycia tokenu z jednej sesji w drugiej.

Confused deputy w serwerze proxy

Confused deputy pojawia się, gdy serwer MCP ma własne uprzywilejowane poświadczenia do zewnętrznego API i wykonuje operację w imieniu użytkownika bez pewności, że ten użytkownik naprawdę ją zatwierdził. Atakujący skłania „zastępcę” do użycia jego uprawnień dla obcego celu.

Klasyczny przykład to serwer, który łączy się ze wspólnym kontem administracyjnym. Model przekazuje identyfikator zasobu w argumencie, a serwer sprawdza tylko poprawność formatu. Brakuje kontroli, czy bieżący użytkownik ma prawo do tego zasobu.

Zabezpieczeniem jest delegowana tożsamość, powiązanie zgody z konkretną transakcją, kontrola owner/tenant na każdym wywołaniu i unikanie wspólnych kont. Warto generować identyfikator akcji, który wiąże użytkownika, narzędzie, parametry, czas i ekran potwierdzenia. Zmiana któregokolwiek pola unieważnia zgodę.

Minimalne uprawnienia narzędzi MCP

Opis „zarządzaj repozytorium” jest zbyt szeroki. Bezpieczniejszy zestaw rozdziela funkcje: odczytaj plik, wyszukaj kod, utwórz propozycję zmiany, otwórz pull request i scal pull request. Domyślnie agent powinien otrzymać odczyt oraz możliwość przygotowania szkicu. Operacje publikujące i nieodwracalne wymagają osobnej decyzji.

Ograniczenia powinny działać równocześnie na kilku warstwach:

tożsamość: osobne konto serwisowe dla serwera i środowiska;
scope: minimalny zakres OAuth lub rola IAM;
zasób: allowlista repozytoriów, katalogów, skrzynek lub projektów;
akcja: odczyt oddzielony od zapisu, zapisu od usunięcia;
wartość: limit kwoty, liczby rekordów lub odbiorców;
czas: krótkie sesje i wygasające zgody;
sieć: wyjście tylko do potrzebnych hostów;
człowiek: potwierdzenie dla operacji wysokiego ryzyka.

Nie polegaj na instrukcji „nie usuwaj plików” w system prompcie. Jeżeli agent nie powinien usuwać plików, jego konto i zestaw narzędzi nie mogą mieć takiej możliwości.

Sandbox i bezpieczeństwo lokalnych serwerów MCP

Lokalny serwer uruchamiany przez stdio jest procesem na komputerze użytkownika. Może odziedziczyć zmienne środowiskowe, dostęp do systemu plików, poświadczenia chmurowe, agent SSH i możliwość komunikacji sieciowej. Instalacja przypadkowego pakietu MCP jest więc zbliżona ryzykiem do uruchomienia obcego programu.

Serwer lokalny warto uruchamiać w kontenerze lub sandboxie z tylko potrzebnym katalogiem, read-only root filesystem, ograniczonymi capabilities, limitem CPU i pamięci oraz kontrolowanym egress. Sekrety należy wstrzykiwać osobno dla konkretnej integracji. Nie montuj całego katalogu domowego i socketu Dockera tylko dlatego, że upraszcza to konfigurację.

W łańcuchu instalacji przypinaj wersję, weryfikuj źródło, sumę i właściciela pakietu. Prowadź SBOM dla zależności oraz procedurę wycofania serwera z wszystkich hostów. Ryzyka dependency confusion i przejęcia maintenera opisujemy szerzej w artykule o atakach na łańcuch dostaw.

Walidacja parametrów i bezpieczne wyniki

JSON Schema pomaga sprawdzić typ danych, ale nie odpowiada, czy użytkownik może odczytać wskazany dokument ani czy domena jest bezpiecznym celem. Serwer powinien stosować walidację semantyczną: allowlisty, zakresy liczb, limity długości, canonicalizację ścieżek, kontrolę tenantów i ochronę przed SSRF.

Wynik narzędzia trafia z powrotem do modelu albo interfejsu. Trzeba traktować go jak niezaufaną treść. Nie wstawiaj bez kodowania do HTML, nie wykonuj zwróconego kodu i nie przekazuj automatycznie do następnego narzędzia. Dla dużych odpowiedzi stosuj limit rozmiaru, typ MIME i kontrolę pobieranych plików. Zasady te odpowiadają kategorii Improper Output Handling w OWASP Top 10 LLM.

Logowanie, monitoring i reakcja na incydent

Audyt musi odpowiedzieć: kto uruchomił narzędzie, przez który host, z jakim zakresem, na jakim zasobie, jakie parametry zatwierdził i jaki był rezultat. Nie oznacza to zapisywania pełnego promptu ani sekretów. Loguj identyfikatory, skróty, klasyfikację danych, decyzje polityki i powiązanie z transakcją.

Alarmy powinny wykrywać:

nietypowy wzrost wywołań lub kosztu;
dostęp do wielu tenantów w krótkim czasie;
serię odmów autoryzacji;
zmianę definicji narzędzia lub wersji serwera;
połączenie z nową domeną;
odczyt sekretów połączony z operacją wysyłania;
użycie administracyjnego scope przez zwykły workflow.

Plan reakcji powinien umożliwiać unieważnienie tokenów, wyłączenie jednego narzędzia, zablokowanie serwera w rejestrze i odnalezienie wszystkich hostów, które go używają. Guardraile i ciągły monitoring AI powinny obejmować zarówno zachowanie modelu, jak i deterministyczną telemetrię integracji.

Checklista bezpieczeństwa serwera MCP

Przed wdrożeniem zweryfikuj:

Czy serwer i autor znajdują się w zatwierdzonym rejestrze?
Czy wersja, hash obrazu lub pakietu są przypięte?
Czy zmiana definicji narzędzia wymaga ponownej oceny?
Czy każdy token ma poprawny audience, scope i krótki czas życia?
Czy token passthrough jest technicznie zablokowany?
Czy operacje sprawdzają użytkownika, tenant i właściciela zasobu?
Czy odczyt, zapis, usuwanie i administracja są rozdzielone?
Czy użytkownik widzi rzeczywiste parametry przed zatwierdzeniem?
Czy lokalny proces ma sandbox, minimalny filesystem i ograniczony egress?
Czy parametry i wyniki są walidowane poza modelem?
Czy logi nie zawierają sekretów, ale pozwalają odtworzyć decyzję?
Czy można szybko unieważnić tokeny i wyłączyć narzędzie?

Jak testować bezpieczeństwo MCP

Dobry test obejmuje więcej niż skan endpointu HTTP. Trzeba ocenić host, klienta, serwer, przepływ OAuth, system docelowy i zachowanie modelu. Scenariusze powinny zawierać prompt injection w zasobach, tool poisoning, zmianę schematu, token dla złego odbiorcy, eskalację scope, IDOR między tenantami, SSRF, path traversal, eksfiltrację przez dozwoloną domenę oraz pętlę kosztownych wywołań.

Raport powinien oddzielać podatność protokołu lub implementacji od niedeterministycznego zachowania modelu. Dla każdego problemu potrzebny jest powtarzalny dowód, warunki ataku, zasięg uprawnień i proponowana kontrola w kodzie lub konfiguracji. Przy agentach o wysokim wpływie warto połączyć klasyczny pentest API z dedykowanym AI red teamingiem.

MCP daje agentom użyteczne możliwości, ale bezpieczeństwo zależy od tego, ile władzy system naprawdę przekazuje modelowi. Najważniejsza zasada brzmi: model może proponować, natomiast polityka, autoryzacja i walidacja muszą pozostać deterministyczne. Jeśli planujesz produkcyjne wdrożenie MCP, skontaktuj się z nami, aby sprawdzić integrację przed podłączeniem realnych danych i uprawnień.