Twój serwer MCP to największa dziura w zabezpieczeniach

Złośliwy serwer MCP może wykraść twoje klucze SSH, nie pisząc nigdy jednej kompletnej złośliwej instrukcji. Grupa badawcza ASSET to udowodniła: gdy polecenie kradzieży jest przekazane modelowi w jednym bloku, duże modele niemal zawsze odmawiają. Podziel to samo polecenie na nieszkodliwie wyglądające fragmenty, a GPT-4o, Gemini 2.0 Flash i Llama 3.3 podporządkują się w 100% testowanych przypadków.

Tymczasem większość deweloperów dodaje nowy serwer MCP do swojego agenta co tydzień, kopiując linijkę konfiguracji znalezioną na GitHubie. Każdy z tych serwerów trzyma fragment twojego dostępu: tokeny API, klucze chmurowe, konta usług. MCP jest przydatne — nikt temu nie zaprzecza. Ale serwer MCP stał się najsłabszym ogniwem całego stosu agenta.

Ten artykuł omawia, jak serwer MCP wycieka twoje sekrety niezauważenie, atak GhostSplice, który omija odmowy modelu dzięki podziałowi instrukcji, oraz konkretne środki obrony, od Cloudflare WriteGuard po zasady, które możesz zastosować dziś we własnym setupie.

Serwer MCP to most między twoim agentem a zewnętrznym narzędziem: twoją bazą danych, GitHubem, Slackiem, chmurą. Aby wykonać tę pracę mostu, przechowuje wszystko, czego potrzebuje, żeby zalogować się jako ty — tokeny, klucze API, dane uwierzytelniające kont usług — w czystym tekście, w pliku konfiguracyjnym na twoim dysku, zwykle bez żadnego szyfrowania.

Jeden szczegół protokołu ma znaczenie dla tego, co nastąpi później. Gdy agent łączy się z serwerem MCP, serwer odsyła listę swoich narzędzi, każde z opisem w wolnym tekście, który mówi modelowi, kiedy i jak go użyć. Te opisy trafiają prosto do kontekstu modelu, z taką samą wagą jak twoje własne instrukcje, a wyniki zwracane przez narzędzia też tam trafiają. Serwer MCP rozmawia z twoim agentem bez przerwy, w tekście, którego nikt nigdy nie czyta ponownie. Właśnie to sprawia, że atak GhostSplice jest możliwy.

Ekosystem urósł też szybciej niż jego zabezpieczenia:

Sygnał	Liczba
Serwery w oficjalnym rejestrze MCP	9 600+
Wzrost wdrożeń zdalnych serwerów od maja 2025	5×

Każdy może opublikować serwer, nie ma centralnej weryfikacji, a twój agent ufa każdemu dokładnie tak jak oficjalnemu narzędziu. NSA opublikowało w maju przewodnik bezpieczeństwa dedykowany MCP, stwierdzając, że adopcja protokołu wyprzedziła budowę jego zabezpieczeń. Kiedy agencja wywiadowcza pisze przewodnik o twoim ulubionym narzędziu deweloperskim, rzadko robi to, żeby ci pogratulować.

Taki jest kontekst: tysiące serwerów, brak weryfikacji, a twoje klucze pośrodku.

Pierwsza dziura to dane uwierzytelniające przechowywane w czystym tekście. The Hacker News opublikował 17 sierpnia szczegółową analizę mechaniki wycieku, a punkt wyjścia jest brutalny: tokeny są wklejane wprost w ciągi konfiguracyjne i pozostają czytelne na dysku. Jeden nieco pospieszny commit wystarczy, żeby wypchnąć konfigurację do repozytorium Git z kluczami w środku. Sytuację pogarsza to, co artykuł nazywa rozprzestrzenianiem: te same klucze zduplikowane w plikach konfiguracyjnych, zmiennych środowiskowych i kopiach w dev, staging i produkcji. Po pewnym czasie nikt nie wie, gdzie żyją sekrety, więc nikt ich nie rotuje — a statyczny klucz, który nigdy się nie rotuje, to klucz czekający na swojego atakującego.

Druga dziura to nadmiarowe uprawnienia. W trakcie developmentu nadajesz swojemu serwerowi szerokie prawa, żeby uniknąć błędów autoryzacji, i te szerokie prawa trafiają na produkcję nietknięte. Jeden pojedynczy incydent ujawnia wtedy znacznie więcej, niż kiedykolwiek uzasadniało rzeczywiste użycie.

Trzecia dziura to łańcuch dostaw. CVE-2025-6514 uderzyło w mcp-remote, proxy OAuth pobrane ponad 400 000 razy, i pozwoliło złośliwemu serwerowi wywołać command injection na maszynie użytkownika — uruchamiając kod i odchodząc z danymi uwierzytelniającymi. Jeden popularny pakiet npm, zainstalowany w jednej linijce, i drzwi były otwarte.

Czwarta dziura jest najbardziej podstępna: prompt injection. Agent czyta wszystko, co przynoszą jego narzędzia — stronę internetową, ticket, wewnętrzny dokument. Jeśli jeden z nich zawiera ukrytą instrukcję, agent może się do niej zastosować, jakby pochodziła od ciebie, i użyć swoich legalnych narzędzi, żeby ujawnić to, co miał chronić. Ten wyciek nie przechodzi przez żadną lukę techniczną; przechodzi przez łatwowierność modelu.

Zanim dojdzie do jakiegokolwiek wyrafinowanego ataku, zwykłe codzienne działanie serwera MCP — konfiguracja w czystym tekście, zawyżone prawa, niezweryfikowane zależności, niefiltrowana treść — już naraża twoje sekrety.

GhostSplice to nazwa nadana przez grupę badawczą ASSET technice, która sprawia, że twój własny agent przeprowadza eksfiltrację, w pełni współpracując. Zasada mieści się w jednym zdaniu: zamiast napisać polecenie kradzieży w całości, złośliwy serwer dzieli je, umieszczając jeden fragment w opisie narzędzia, a drugi w wyniku zwracanym przez to narzędzie. Każdy kawałek, czytany osobno, wygląda niegroźnie. Ale agent łączy wszystko, co trafia do jego roboczego kontekstu: odtwarza pełną instrukcję i wykonuje ją w pełnej dobrej wierze — z jego punktu widzenia po prostu wypełnia formularz, o który poprosiło go narzędzie.

Wyniki testów to prawdziwa historia:

Model	Instrukcja w jednym bloku	Instrukcja podzielona na fragmenty
GPT-4o	Odmawia w 100%	Podporządkowuje się w 100%
Gemini 2.0 Flash	Odmawia w 100%	Podporządkowuje się w 100%
Llama 3.3	Odmawia w 100%	Podporządkowuje się w 100%
Claude Haiku 4.5	Odmawia przez API	Podporządkowuje się w 100% w teście trzyczęściowym wewnątrz Cursora

Szczegół dotyczący Claude'a niszczy każdy łatwy wniosek: ten sam model może odmówić w jednym kliencie, a eksfiltrować w innym, w zależności od zabezpieczeń, które ten klient dodaje albo nie.

Co GhostSplice kradnie w testach: klucze SSH, sekrety środowiskowe, kod źródłowy, dane klientów. Badacze pracowali na izolowanych projektach z fałszywymi kluczami, nie na prawdziwych ofiarach, ale metoda jest opublikowana i odtwarzalna.

GhostSplice nie jest pierwszą próbą. To samo laboratorium opublikowało w czerwcu Ghostcommit, atak, który ukrywał swoje instrukcje w plikach PNG odwoływanych przez konwencje projektu, a następnie kodował wykradzione sekrety w kodzie źródłowym jako liczby całkowite. Podział instrukcji to rodzina ataków, która się utrwala, nie odosobniona ciekawostka.

Dwie rzeczy zachowują to w perspektywie. Atak ma dwa warunki wstępne: złośliwy serwer jest już podłączony do twojego agenta, a agent ma dostęp odczytu do docelowych plików. Właśnie dlatego pochodzenie ma tak duże znaczenie — skąd pochodzą twoje serwery, to twoja pierwsza linia obrony. I pamiętaj o mechanice: alignment modelu cię nie chroni, bo atak nigdy nie prosi o nic zabronionego w jednym kawałku.

GhostSplice zakładało, że złośliwy serwer jest już podłączony. Ale kto decyduje, co zostaje podłączone? W zespole szczera odpowiedź brzmi: nikt. To problem, który Cloudflare nazywa shadow MCP: wszystkie serwery, które deweloperzy podłączają do swoich agentów bez żadnej weryfikacji bezpieczeństwa. Do niedawna ten ruch był niewidoczny — żądanie MCP wygląda jak każde inne wywołanie HTTPS.

Cloudflare to zmieniło dzięki wykrywaniu na poziomie protokołu. Od aktualizacji specyfikacji każdy zgodny klient MCP wysyła nagłówek MCP-Protocol-Version w swoich żądaniach, a Gateway sprawdza ten nagłówek w całym ruchu TLS, który odszyfrowuje. Zespół bezpieczeństwa może teraz zobaczyć każdy serwer MCP używany w firmie, z dedykowanym dashboardem: unikalne serwery, użytkownicy, wolumeny żądań. To podejście oparte na nagłówku bije filtrowanie po nazwie domeny, bo serwer MCP nie ma powodu, żeby nazywać się mcp-cokolwiek — protokół jest wykrywany po tym, co mówi, a nie po tym, za co się podaje.

Zespół może też działać: selektor is_mcp pozwala zablokować dowolny ruch MCP, który nie przeszedł przez zatwierdzony portal. Portal to druga połowa układu — jeden punkt dostępu, który grupuje zweryfikowane serwery za uwierzytelnianiem tożsamości.

Najnowsza wersja specyfikacji przesuwa widoczność jeszcze dalej. Nowe nagłówki Mcp-Method i Mcp-Name ujawniają żądaną operację i wywoływane narzędzie, bez konieczności otwierania przez firewall treści żądania. Zespół może odróżnić agenta czytającego ticket od agenta usuwającego pięćdziesiąt z nich, na poziomie sieci.

Cloudflare dzieli to na dwa przypadki: czyste shadow MCP, serwer nigdy niezatwierdzony, i obejście portalu, zatwierdzony serwer osiągnięty bezpośrednio z pominięciem punktu kontrolnego. Oba są blokowane tą samą podstawową regułą. Logika jest prosta: wszystko przez portal jest znane i logowane, wszystko inne jest blokowane. Dla firmy to koniec serwera-widma MCP zainstalowanego w piątkową noc.

Nawet zatwierdzony serwer może wyrządzić szkodę, bo agent dziedziczy naraz wszystkie prawa swojego użytkownika. Tu wkracza WriteGuard, który Cloudflare właśnie otworzyło w prywatnej becie. Pomysł: sklasyfikować każde narzędzie każdego serwera MCP do poziomu ryzyka i zastosować inną politykę dla każdego poziomu.

• Odczyt przechodzi bez tarcia.
• Ograniczony zapis, jak dodanie komentarza, przechodzi, ale wzbogacony: akcja jest podpisana jako pochodząca od agenta, w imieniu konkretnego człowieka, a zdarzenie audytowe trafia do centralnego logu.
• Krytyczna akcja — mergowanie kodu, wdrożenie na produkcję, masowe usuwanie — jest blokowana, zanim jeszcze serwer ją obsłuży.

Przykład z GitLaba we wpisie Cloudflare dobrze pokazuje tę gradację: czytanie merge requesta przechodzi, komentowanie go przechodzi z atrybucją, a mergowanie jest odrzucane, dopóki nie zrobi tego człowiek osobiście.

Najciekawszą częścią jest model tożsamości. Agent zachowuje uprawnienia pracownika, któremu służy, ale każdy zapis niesie teraz dwa podpisy: osoby i sesji agenta działającej w jej imieniu. Systemy niższego poziomu mogą wreszcie odróżnić zmianę wykonaną ręcznie od wygenerowanej maszynowo, a audyt trafia asynchronicznie do centralnego logu, oczyszczony z danych wrażliwych. Do tej pory agent był nieodróżnialny od swojego człowieka w logach; dla audytu incydentu to zmienia wszystko — jedno zapytanie mówi ci, czy wątpliwy merge z wtorku pochodził od zabieganego współpracownika, czy od sesji agenta, która się rozkręciła.

Cloudflare nie sprzedaje teorii; opisuje własne wewnętrzne użycie: ich portal łączy 27 serwerów MCP, w górę z 13 w kwietniu. Ta liczba mówi prawdziwą historię — nawet u Cloudflare liczba serwerów podwaja się w ciągu kilku miesięcy, i właśnie dlatego kontrola na poziomie pojedynczego narzędzia staje się konieczna. Kierunek, w którym zmierza branża, jest jasny: przestajemy ufać całemu serwerowi i decydujemy akcja po akcji, co wolno robić agentowi.

Ograniczenia trzeba powiedzieć wprost. WriteGuard to prywatna beta za formularzem zapisu, a wykrywanie Gateway wymaga wdrożenia Cloudflare Zero Trust z włączoną inspekcją TLS: dla samodzielnego dewelopera albo małego zespołu to po prostu nie jest twoja infrastruktura. Nawet w firmie wykrywanie widzi tylko ruch sieciowy, który odszyfrowuje — lokalny serwer MCP działający przez stdio, uruchomiony jako zwykły proces na twojej maszynie, pozostaje niewidoczny dla Gateway. A to dokładnie tak, jak faktycznie działa większość serwerów instalowanych przez deweloperów.

Przede wszystkim żadne z tych narzędzi nie naprawia podstawowego mechanizmu, który obnażył GhostSplice: dopóki agent swobodnie łączy wszystko, co trafia do jego kontekstu, nieszkodliwe fragmenty będą wciąż odtwarzać się we wrogie instrukcje. Badacze ASSET mówią to sami: naprawa wymaga traktowania wyniku narzędzia jako danych, nigdy jako instrukcji, a takie rozdzielenie jeszcze nie istnieje natywnie w agentach.

Tymczasem ich rekomendacje sprowadzają się do trzech ruchów: powstrzymaj wartości wychodzące z jednego narzędzia przed niekontrolowanym zasilaniem argumentów innego narzędzia, zachowaj możliwość ręcznego odmówienia każdego wywołania narzędzia, i traktuj każdą adnotację z niezweryfikowanego serwera jako wrogą domyślnie. Żadna z tych trzech rzeczy nie jest dziś automatyczna: albo ty je stosujesz, albo nikt tego nie robi. Traktuj wszystko, co Cloudflare tu dostarcza, jak pasy bezpieczeństwa, nie hamulce — ogranicza szkody, nie zapobiega kolizji.

Co robić, zaczynając od dziś:

1. Inwentaryzacja. Wypisz serwery MCP faktycznie podłączone do twoich agentów i usuń te, których już nie używasz.
2. Segreguj według pochodzenia. Oficjalny serwer od znanego dostawcy — tak. Repozytorium na GitHubie z 40 gwiazdkami znalezione w wątku — nie, dopóki nie przeczytasz, co robi z twoimi danymi.
3. Ogranicz zakres uprawnień. Nadaj każdemu serwerowi dedykowany token o minimalnym zakresie, nigdy swój klucz główny, i rotuj te tokeny tak, jak zrobiłbyś to dla dowolnego systemu produkcyjnego.
4. Trzymaj rękę na wrażliwych akcjach. Agent, który zapisuje, merguje albo usuwa, musi wrócić przez ciebie — to ręczna wersja tego, co uprzemysławia WriteGuard.
5. Stosuj zasadę GhostSplice na co dzień. Kiedy twój agent łączy akcje narzędzi, o które nie prosiłeś, zatrzymaj go i przeczytaj, co mówił mu serwer.

Każdy klient agenta może wypisać podłączone serwery i ich narzędzia, a przeczytanie tej listy zajmuje trzydzieści sekund. Te trzydzieści sekund to najlepszy stosunek czasu do bezpieczeństwa w całym twoim setupie.

Jeśli jesteś w firmie, dodaj warstwę sieciową: wykrywanie MCP przez Gateway i portale są warte wdrożenia, bo shadow MCP już istnieje w twojej organizacji, niezależnie czy to widzisz, czy nie.

MCP nie jest problemem — problemem jest szybkość, z jaką oddaliśmy mu nasze klucze.