Firma Anthropic wprowadziła protokół kontekstowy modelu (MCP) w dniu 25 listopada 2024 r. jako „otwarty standard, który umożliwia programistom tworzenie bezpiecznych, dwukierunkowych połączeń między źródłami danych a narzędziami opartymi na sztucznej inteligencji”. W praktyce MCP pozwala asystentowi AI wywoływać lokalne programy, zwane serwerami MCP, które w jego imieniu odczytują pliki, wysyłają zapytania do baz danych lub łączą się z siecią. Jest to naprawdę przydatne, ale stanowi także nowy rodzaj powierzchni ataku: model decyduje, które narzędzie wywołać, na podstawie przeczytanego tekstu i nie zawsze jest w stanie odróżnić Twoje instrukcje od instrukcji innej osoby.
Jak faktycznie działa serwer MCP
Specyfikacja MCP definiuje dwa transporty. Przez stdio „klient uruchamia serwer MCP jako podproces” i obaj rozmawiają poprzez standardowe wejście i wyjście. Za pośrednictwem strumieniowego protokołu HTTP (który zastąpił oryginalny transport HTTP+SSE ze specyfikacji z listopada 2024 r.) serwer działa jako własny proces lokalny, a klient wysyła do niego żądania HTTP, opcjonalnie otrzymując z powrotem strumień zdarzeń wysłanych przez serwer (Specyfikacja MCP, transporty). Tak czy inaczej, lokalny serwer MCP zwykle działa z tymi samymi uprawnieniami do plików i sieci, co osoba, która go uruchomiła, ponieważ żaden zapis protokołu nie wymaga inaczej.
Sama specyfikacja bezpośrednio wskazuje ryzyko związane z wariantem HTTP: wymaga od serwerów sprawdzenia poprawności nagłówka Origin, zaleca powiązanie z 127.0.0.1 zamiast 0.0.0.0 podczas działania lokalnego i wzywa do uwierzytelniania przy każdym połączeniu, ostrzegając, że bez tego „napastnicy mogliby użyć ponownego wiązania DNS w celu interakcji z lokalnymi serwerami MCP ze zdalnych stron internetowych”.
Mechanizm: zdezorientowany zastępca
Klasyczna nazwa tego trybu awarii to zdezorientowany problem zastępcy: „program komputerowy, który został oszukany przez inny program (z mniejszymi uprawnieniami lub mniejszymi prawami) w celu nadużycia swoich uprawnień”. Agent AI z dostępem do narzędzia MCP to zastępca posiadający prawdziwe uprawnienia — do odczytywania plików, wysyłania żądań sieciowych — działający na podstawie instrukcji, które mogą pochodzić z treści, które miał jedynie podsumować lub przeanalizować. Jeśli treść zawiera własne instrukcje, agent może zastosować się do nich zamiast lub dodatkowo do Twoich. Oto, co klasa 10 najważniejszych zagrożeń dla aplikacji LLM według OWASP nazywa natychmiastowym zastrzykiem i nadmierną agencją: OWASP: Top 10 dla aplikacji LLM; OWASP LLM01:2025, Szybki zastrzyk.
Zademonstrowany przypadek: serwer GitHub MCP
To nie jest teoria. 26 maja 2025 r. Invariant Labs zgłosiło weryfikacja koncepcji przeciwko oficjalnemu serwerowi GitHub MCP, który miał wówczas około 14 000 gwiazd GitHub. Ich konfiguracja: agent mający dostęp do repozytorium publicznego i prywatnego został poproszony o sprawdzenie otwartych problemów w repozytorium publicznym. Stworzony problem w publicznym repozytorium zawierał ukryte instrukcje; agent, odczytując go w ramach swoich normalnych zadań, poszedł za nimi i podczas demonstracji ujawnił szczegóły prywatnego repozytorium, w tym informacje, które badacze określają jako osobiste, wątkowi problemu kontrolowanemu przez osobę atakującą. Firma Invariant Labs wyraźnie stwierdziła, że jest to zademonstrowany dowód słuszności koncepcji w repozytoriach testowych, a nie atak zaobserwowany w środowisku naturalnym, oraz że „nie jest to usterka w samym kodzie serwera GitHub MCP, ale raczej podstawowy problem architektoniczny, który należy rozwiązać na poziomie systemu agenta”. Modelem użytym w demonstracji był Claude 4 Opus.
Zabójcza trifecta
16 czerwca 2025 r. Simon Willison nazwał wzór stojący za takimi przypadkami „zabójcza trifecta”: agent mający (1) dostęp do prywatnych danych, (2) narażenie na niezaufane treści oraz (3) sposób komunikacji zewnętrznej. „Jeśli Twój agent łączy te trzy funkcje, osoba atakująca może łatwo oszukać go, aby uzyskać dostęp do Twoich prywatnych danych i wysłać je do atakującego”. Jako współautora wymienia MCP: „Problem z Model Context Protocol — MCP — polega na tym, że zachęca on użytkowników do mieszania i dopasowywania narzędzi z różnych źródeł, które mogą robić różne rzeczy”, co ułatwia korzystanie ze wszystkich trzech właściwości w jednej sesji bez konieczności podejmowania decyzji.
Dlaczego narzędzia dla punktów końcowych nie mogą tego zobaczyć
Z punktu widzenia systemu operacyjnego w przypadku GitHub MCP nie wydarzyło się nic niezwykłego: podpisana, zaufana aplikacja przeczytała jakiś tekst i wysłała żądanie sieciowe za pośrednictwem lokalnego procesu pomocniczego, do używania którego została skonfigurowana. Nie ma żadnego złośliwego pliku binarnego, który można by zgłosić, ani wykorzystania błędu związanego z bezpieczeństwem pamięci. Żądanie, które ma znaczenie – to, które przenosi dane – ma taki sam kształt, jak każde inne wywołanie narzędzia, które agent wykonuje poprawnie sto razy dziennie.
Co faktycznie zmniejsza ryzyko
- Daj każdemu serwerowi MCP najwęższy zakres narzędzi i plików, jakich potrzebuje, a nie szeroki dostęp do systemu plików lub powłoki, więc wywołanie przejętego narzędzia będzie miało mniej do zrobienia.
- Traktuj każdą treść, którą agent czyta spoza Twojej kontroli (problemy, strony internetowe, pobrane pliki), jako niezaufane dane wejściowe. Tę samą dyscyplinę należy zastosować w przypadku danych wprowadzanych przez użytkownika w każdym innym systemie.
- Postępuj zgodnie ze wskazówkami na poziomie transportu zawartymi w samej specyfikacji MCP: powiąż lokalne serwery z localhost, wymagaj uwierzytelnienia, sprawdź nagłówek Origin.
- Obserwuj lub kontroluj jeden krok wspólny dla każdej wersji tego ataku: połączenie wychodzące, które przenosi dane do atakującego. Ten krok następuje po tym, jak model został już oszukany, dlatego jest to najpewniejsze miejsce, aby go złapać.
Jaką rolę odgrywają FireAI i HisnLabs
The step an injected agent cannot skip is the outbound connection that carries your data out, which is exactly what a per-app firewall like FireAI is built to see and stop, whether the process asking to connect is a familiar app or an MCP server it has never seen before.
FireAI to własny produkt HisnLabs: zapora sieciowa z AI działająca bezpośrednio na Macu. Pokazuje prostym językiem każde połączenie nawiązywane przez twoje aplikacje i pozwala ci decydować, co opuszcza twojego Maca — jej AI działa lokalnie, więc twój ruch nigdy nie jest wysyłany do nas ani do nikogo innego. Zespół badań nad bezpieczeństwem HisnLabs dba o to, by te decyzje pozostały trafne: kataloguje, które domeny to zwykła telemetria, a które prawdziwa usługa, śledzi kraj i sieć stojące za połączeniem oraz trenuje lokalny model (funkcję Autopilot) na rzeczywistych wzorcach ruchu — a nic z tego nie opuszcza twojego Maca.
Możesz przeczytać o decyzjach technicznych, które za tym stoją, albo wypróbować FireAI przez 17 dni na FireAI od HisnLabs.