Jak bezpiecznie podłączyć serwer MCP do asystenta AI
Serwer MCP może dać agentowi dostęp do plików, baz danych i narzędzi. Zobacz, jak ograniczyć uprawnienia, sekrety i ryzyko prompt injection.
Model Context Protocol, czyli MCP, ujednolica sposób, w jaki aplikacje AI łączą się z narzędziami i źródłami danych. Dzięki niemu asystent może odczytać dokument, przeszukać bazę, pobrać dane z API albo wykonać operację w zewnętrznym systemie.
Ta wygoda zmienia jednak model zagrożeń. Zwykły chatbot generuje tekst. Agent z MCP może otrzymać dostęp do realnych zasobów, dlatego każdy serwer należy traktować jak integrację z uprawnieniami, a nie jak niewinną wtyczkę.
Najpierw ustal, do czego serwer ma służyć
Zapisz jednozdaniowy cel integracji, na przykład: „serwer może wyłącznie odczytywać zgłoszenia z projektu X”. Jeżeli nie potrafisz precyzyjnie opisać celu, zakres prawdopodobnie jest za szeroki.
Zasada najmniejszych uprawnień oznacza, że serwer powinien otrzymać tylko te możliwości, które są konieczne:
- odczyt zamiast zapisu,
- jeden katalog zamiast całego dysku,
- jedna baza lub schemat zamiast konta administratora,
- ograniczony token API zamiast głównego klucza,
- osobne dane dostępowe dla każdej integracji.
Traktuj serwer jak obcy kod
Przed instalacją sprawdź:
- kto utrzymuje projekt,
- czy kod źródłowy jest dostępny,
- jakie polecenia są wykonywane podczas instalacji,
- jakie zmienne środowiskowe są wymagane,
- do jakich hostów serwer się łączy,
- czy projekt ma aktywne aktualizacje i zgłoszenia bezpieczeństwa.
Nazwa w katalogu integracji nie jest audytem bezpieczeństwa. Jeżeli serwer ma dostęp do kodu, poczty lub danych klientów, przejrzenie jego działania jest warte czasu.
Nie umieszczaj sekretów w konfiguracji współdzielonej
Klucze API i hasła przechowuj w menedżerze sekretów albo zmiennych środowiskowych wyłączonych z repozytorium. Nie wpisuj ich do pliku, który może trafić do Git.
Dobry sekret:
- ma minimalny zakres,
- można go szybko unieważnić,
- ma osobny właścicielski kontekst,
- jest rotowany,
- nie jest używany przez kilka niezależnych aplikacji.
Po przypadkowym ujawnieniu nie wystarczy usunąć klucza z ostatniego commita. Trzeba go unieważnić, ponieważ może pozostać w historii.
Local MCP i remote MCP to inne ryzyko
Serwer lokalny często działa jako proces uruchamiany przez klienta AI. Może odziedziczyć dostęp użytkownika do plików i programów. Ogranicz katalog roboczy, korzystaj z konta o mniejszych uprawnieniach i unikaj poleceń budowanych bezpośrednio z tekstu modelu.
Serwer zdalny wymaga poprawnej autoryzacji. Oficjalna specyfikacja autoryzacji MCP opiera się na standardowych mechanizmach OAuth. Token powinien być przeznaczony dla konkretnego serwera, a nie przekazywany dalej do innych usług.
Prompt injection nie znika dzięki MCP
Złośliwa instrukcja może znajdować się w stronie internetowej, dokumencie, komentarzu w kodzie albo wyniku wyszukiwania. Model może uznać ją za polecenie i spróbować użyć narzędzia w sposób niezgodny z intencją użytkownika.
Dlatego:
- dane z narzędzi traktuj jako niezaufane,
- oddzielaj treść od instrukcji systemowych,
- wymagaj potwierdzenia operacji zmieniających dane,
- ogranicz liczbę narzędzi dostępnych w jednej sesji,
- nie pozwalaj modelowi samodzielnie rozszerzać uprawnień,
- waliduj argumenty po stronie serwera.
Sam prompt „nie wykonuj niebezpiecznych poleceń” nie jest wystarczającą kontrolą.
Dodaj granicę między odczytem a działaniem
Operacje można podzielić na trzy poziomy:
| Poziom | Przykład | Zalecana kontrola |
|---|---|---|
| Odczyt | pobranie dokumentu | ograniczenie zakresu i logowanie |
| Zmiana odwracalna | utworzenie wersji roboczej | podgląd oraz potwierdzenie |
| Zmiana ryzykowna | usunięcie danych, publikacja, płatność | osobna autoryzacja i twarde reguły serwera |
Najbezpieczniej, gdy model przygotowuje propozycję, a użytkownik zatwierdza wykonanie. Automatyzację bez potwierdzenia dodawaj dopiero po zebraniu logów i testów.
Loguj decyzje, nie sekrety
Rejestruj nazwę narzędzia, czas, użytkownika, typ operacji i rezultat. Nie zapisuj pełnych tokenów, haseł ani całych dokumentów, jeśli nie jest to konieczne.
Log powinien pozwolić odpowiedzieć na pytania: kto uruchomił narzędzie, jakie zasoby zostały dotknięte i czy operacja się powiodła. Bez tego trudno analizować incydent.
Checklista przed podłączeniem
- Cel serwera jest jasno opisany.
- Uprawnienia są minimalne i możliwe do cofnięcia.
- Sekrety nie znajdują się w repozytorium.
- Operacje zapisu wymagają potwierdzenia.
- Argumenty narzędzi są walidowane po stronie serwera.
- Treści zewnętrzne są traktowane jako niezaufane.
- Dostęp i błędy są logowane bez ujawniania sekretów.
- Istnieje sposób natychmiastowego odłączenia integracji.
- Serwer został przetestowany na koncie i danych testowych.
Najważniejsza zasada
MCP nie jest z natury bezpieczny ani niebezpieczny. Jest warstwą integracji. O bezpieczeństwie decydują uprawnienia, jakość serwera, sposób autoryzacji i to, czy model może wykonać nieodwracalną operację bez kontroli człowieka.
Zacznij od odczytu, małego zakresu i danych testowych. Dopiero gdy widzisz rzeczywiste zachowanie systemu, dodawaj kolejne narzędzia i automatyzacje.
