Przegląd serwera MCP, zanim agent AI dostanie narzędzia

Traktuj serwer MCP jak kod firmy trzeciej, który działa z Twoimi poświadczeniami, i przejrzyj go, zanim agent będzie mógł go wywoływać. Poniższe kontrole opierają się na specyfikacji autoryzacji MCP (rewizja 2025-06-18) oraz najlepszych praktykach bezpieczeństwa MCP (rewizja 2025-11-25). Rewizje się różnią, więc zanim oprzesz się na jakimkolwiek wymaganiu, sprawdź aktualną specyfikację.

Autoryzacja jest opcjonalna, więc sprawdź, czy w ogóle istnieje

Serwery na transporcie HTTP powinny stosować się do specyfikacji autoryzacji. Serwery na STDIO nie powinny - zamiast tego biorą poświadczenia ze środowiska. Dla lokalnego serwera STDIO wypisz zmienne środowiskowe, które konfiguracja klienta przekazuje do procesu, i zadaj sobie pytanie, czy każda z nich jest potrzebna.

Dla serwera HTTP wyślij nieuwierzytelnione żądanie:

curl -i https://mcp.example.com/mcp

Powinieneś dostać odpowiedź 401 Unauthorized z nagłówkiem WWW-Authenticate, który podaje adres URL metadanych zasobu. Pobierz go i sprawdź, czy dokument zawiera authorization_servers z co najmniej jednym wpisem. Jeśli serwer odpowiada danymi, na tym zakończ.

Następnie potwierdź punkty, które specyfikacja oznacza jako obowiązkowe:

• Klient wysyła Authorization: Bearer <access-token> w każdym żądaniu HTTP, a token nigdy nie pojawia się w query stringu URI.
• Endpointy serwera autoryzacji używają HTTPS, a redirect URI wskazują na localhost albo HTTPS.
• Serwer autoryzacji dopasowuje redirect URI dokładnie do wcześniej zarejestrowanych wartości.
• Klienci implementują PKCE.

Klienci powinni też weryfikować parametr state, a serwery autoryzacji powinny wydawać krótko żyjące access tokeny.

Audience i scope tokena

Klient musi wysyłać parametr resource (RFC 8707) zarówno w żądaniach autoryzacji, jak i w żądaniach tokena, a serwer musi sprawdzać, czy każdy token został wystawiony właśnie dla niego. W przeciwnym razie tokeny wystawione dla innych usług działają także wobec tego serwera.

Token passthrough jest jeszcze gorszy: serwer przyjmuje token, który nie został dla niego wystawiony, i przekazuje go bez zmian dalej. Mechanizmy kontrolne, takie jak rate limiting i monitoring, mogą zależeć od audience tokena, a logi systemów docelowych mogą przypisywać żądania do niewłaściwej tożsamości, co utrudnia dochodzenie.

Aby przetestować powiązanie z audience, użyj zarejestrowanego klienta i zażądaj tokena dla innego zasobu z token_endpoint podanego w metadanych serwera autoryzacji. Następnie odtwórz go (replay) wobec serwera MCP:

curl -i -H "Authorization: Bearer $OTHER_TOKEN" https://mcp.example.com/mcp

Oczekuj 401. Poprawny token bez wymaganych uprawnień powinien dostać 403. Jeśli serwer autoryzacji nie wystawi takiego tokena, zapytaj dostawcę, jak serwer MCP sprawdza audience.

Zapytaj też, gdzie serwer przechowuje tokeny. Publiczni klienci muszą mieć rotowane refresh tokeny, a tokeny cache'owane lub logowane na serwerze są celem kradzieży.

Serwery proxy i zgoda

Jeśli serwer MCP stoi przed API firmy trzeciej i używa jednego statycznego client ID, przeczytaj sekcję o confused deputy w najlepszych praktykach. Atak wymaga statycznego client ID, dynamicznej rejestracji klientów, ciasteczka zgody z serwera autoryzacji strony trzeciej oraz braku zgody dla każdego klienta osobno na proxy. Ostatni element leży po Twojej stronie: proxy powinno prowadzić rejestr zatwierdzonych wartości client_id dla każdego użytkownika i wyświetlać nazwę klienta, scope'y oraz redirect URI na własnej stronie zgody, która musi blokować osadzanie w iframe przez frame-ancestors lub X-Frame-Options: DENY.

Dodaj narzędzia do allowlisty, potem je ogranicz

Poproś serwer o listę narzędzi i porównaj ją z tym, czego wymaga zadanie. Wszystko ponad to jest nadmiarową funkcjonalnością (excessive functionality) w rozumieniu OWASP LLM06:2025. Usuń to albo zablokuj agentowi możliwość wywołania.

Zapisz listę jako punkt odniesienia (baseline) i porównuj ją po każdej aktualizacji serwera, aby narzędzie dodane w aktualizacji zostało sprawdzone, zanim agent będzie mógł je wywołać. Następnie przejrzyj każde z pozostałych narzędzi:

• Czy jest otwarte, jak "uruchom polecenie powłoki" albo "pobierz URL"? Zastąp je wąskim narzędziem. Przykład OWASP to narzędzie do zapisu plików zamiast dostępu do shella.
• Z jakiej tożsamości korzysta w systemie docelowym? Narzędzie, które czyta dane, powinno łączyć się tylko z uprawnieniem SELECT, a nie UPDATE, INSERT i DELETE.
• Czy działa w imieniu jednego użytkownika? Wtedy powinno uwierzytelniać się przez OAuth z minimalnym scope'em, a nie przez generyczne konto uprzywilejowane.

Egzekwuj ograniczenia w systemie docelowym. OWASP nazywa to complete mediation: nie polegaj na modelu przy decydowaniu, czy dana akcja jest dozwolona.

Akceptacja przez człowieka dla akcji zapisu

Halucynacje i prompt injection to częste przyczyny szkodliwych działań, dlatego akcje o dużym wpływie wymagają człowieka w pętli. OWASP opisuje asystenta pocztowego, który streszcza przychodzące wiadomości. Podstawiony e-mail nakłania go do przeszukania skrzynki pod kątem wrażliwych informacji i przesłania ich atakującemu.

Rozszerzenie tylko do odczytu, scope OAuth tylko do odczytu albo ręczna weryfikacja każdej przygotowanej wiadomości przed wysłaniem - każde z tych rozwiązań przerwałoby ten atak. Łącz je warstwowo tam, gdzie to możliwe.

Wszystko, co usuwa, wysyła lub publikuje, należy do listy akcji wymagających zatwierdzenia. Umieść zatwierdzanie w rozszerzeniu albo w systemie docelowym. Logowanie i rate limiting nie zapobiegają excessive agency, ale ułatwiają zauważenie niechcianych działań.

Jeśli klient działa po stronie serwera

Podczas OAuth discovery klient pobiera adresy URL dostarczone przez serwer, w tym resource_metadata, authorization_servers i token_endpoint. Złośliwy serwer może skierować je na adresy wewnętrzne albo na endpoint metadanych chmury pod 169.254.169.254.

Wymagaj HTTPS na produkcji, blokuj zakresy prywatne i zarezerwowane oraz waliduj cele przekierowań albo wyłącz automatyczne przekierowania. Nie pisz walidacji IP ręcznie, ponieważ sztuczki z zapisem ósemkowym, szesnastkowym i IPv6 mapowanym na IPv4 pokonują własne parsery. Rozważ egress proxy, takie jak Smokescreen.

Potem to przetestuj. Postaw wrogi serwer testowy, który zwraca 401 z nagłówkiem WWW-Authenticate zawierającym adres resource_metadata wskazujący na http://169.254.169.254/, a następnie powtórz test z adresem, który przekierowuje na adres wewnętrzny. Klient powinien odrzucić oba przypadki, a nasłuch na wewnętrznym celu nie powinien odnotować żadnego żądania.

Od czego zacząć

1. Wypisz wszystkie serwery MCP używane przez Twoich agentów wraz z transportem i operatorem. Usuń każdy, którego nie potrafisz uzasadnić.
2. Uruchom curl -i wobec każdego serwera HTTP i potwierdź 401 z nagłówkiem WWW-Authenticate. Następnie odtwórz token wystawiony dla innego zasobu.
3. Dla serwerów proxy ze statycznym client ID przejrzyj przepływ zgody: rejestr per klient, zawartość strony zgody, ochrona przed osadzaniem.
4. Zapisz baseline listy narzędzi każdego serwera, zawęź ją do tego, czego wymaga zadanie, nadaj każdemu narzędziu tożsamość o najmniejszych uprawnieniach i wymagaj akceptacji człowieka dla narzędzi zapisu i usuwania.
5. Dla klientów działających po stronie serwera uruchom test SSRF z wrogim serwerem testowym.
6. Powtarzaj kroki od 2 do 5 za każdym razem, gdy serwer się aktualizuje, dodaje narzędzie lub zmienia scope'y.

Jeśli potrzebujesz zewnętrznego przeglądu, zobacz naszą usługę doradczą. Nasze testy penetracyjne mogą objąć kontrole tokenów i zgody w Twoim środowisku.