Zatrucie narzędzi MCP i rug-pulls

Serwer MCP lub zainstalowany skill strony trzeciej to zależność w łańcuchu dostaw. Dwa tryby awarii wyróżniają się:

• Zatrucie — serwer był złośliwy od pierwszego dnia. Jego manifest wyglądał łagodnie; niebezpieczne zachowanie było w implementacji narzędzia, nie w deklarowanych zakresach.
• Rug-pull — zaufałeś mu, a potem się zmienił. Pojawiło się nowe narzędzie, które operator serwera dodał po cichu, lub wpis w rejestrze społeczności został przejęty i zaktualizowany, aby dzwonił do domu.

Oba zagrożenia mają wspólną przyczynę: po tym jak powiedziałeś „ufam temu serwerowi”, twoje agenty nadal wywołują jego narzędzia — nawet nowe lub zmodyfikowane — bez dalszego przeglądu.

​

1. Jak zatrucie narzędzi MCP dociera do twoich agentów

Każde tools/call, które twój agent wydaje, podróżuje przez zadeklarowany zestaw narzędzi serwera MCP. Zatrute lub podlegające rug-pullowi serwery wykorzystują to zaufanie na kilka sposobów:

​

2. Obrony OrcaRouter

​

2.1 Każde tools/call jest ewaluowane przez firewall przed uruchomieniem

Serwery MCP łączą się z twoimi agentami przez bramę Firewall MCP pod adresem /api/v1/firewall/mcp. Brama nie przekazuje wywołania narzędzia, dopóki silnik firewalla nie ewaluuje go wobec twojej polityki. Oznacza to, że twoja lista dozwolonych jest źródłem prawdy — nie manifest narzędzi serwera. Jeśli rug-pull doda shell.exec, a twoja polityka nie ma reguły zezwalającej na to, werdykt to deny i wywołanie nigdy nie opuszcza bramy. Model otrzymuje błąd narzędzia (firewall deny: …) i może zareagować; narzędzie dodane przez atakującego jest martwe od razu. Werdykty, które silnik może zwrócić:

​

2.2 Auto-wykryte zdolności są poddawane kwarantannie do czasu przeglądu

Gdy agent samodzielnie instaluje zdolność — lub rug-pull dodaje nowe narzędzia, których nie było, gdy zarejestrowałeś serwer — Firewall auto-wykrywa nową zdolność poza gorącą ścieżką, syntezuje manifest, skanuje go i przypisuje pasmo ryzyka i tryb egzekwowania. Co kluczowe, auto-wykryte zdolności są zawsze poddawane kwarantannie niezależnie od wyniku skanu: są wstrzymane w pending_approval do czasu, gdy człowiek je przejrzy. Tak właśnie rug-pulle są zawarte. Operator nie może po cichu dodać nowego narzędzia i sprawić, że twoje agenty zaczną go używać — te wywołania są wstrzymane do czasu, gdy sprawdzisz i zatwierdzisz nową zdolność.

​

2.3 Skanowanie skilli przypisuje pasmo ryzyka i tryb egzekwowania

Każda installowalna zdolność — czy zarejestrowałeś ją, czy Firewall ją auto-wykrył — jest przepuszczana przez skaner skilli. Skaner uruchamia deterministyczne przejścia nad manifestem i deklarowanymi zakresami:

• prompt_injection — tekst manifestu próbujący przejąć instrukcje.
• tool_creep — narzędzia, które manifest używa, ale nigdy nie deklarował.
• network_egress — hosty HTTP(S) poza zatwierdzonymi zakresami sieciowymi.
• fs_write_unsafe — dostęp do systemu plików w trybie zapisu poza /tmp.

Wyniki zwijają się do pasma ryzyka (low / medium / high / critical) i trybu egzekwowania: Skill z pasmem high jest automatycznie poddawany kwarantannie; critical jest blokowany. Jedno znalezisko error (np. tool_creep dla niezadeklarowanego shell.exec) wystarczy, aby zablokować skill nawet gdy jego wynik numeryczny wygląda nisko. Tryb tylko się zaostrza — zatwierdzenie skilla nigdy nie łagodzi blokady ustawionej przez świeży skan.

​

2.4 Poświadczenia są przechowywane zaszyfrowane

Sekrety auth serwera są szyfrowane w spoczynku za pomocą klucza sekretów przestrzeni roboczej i wstrzykiwane przez bramę w czasie dyspozycji. Nigdy nie docierają do modelu, agenta ani argumentów wywołania. Skompromitowany serwer nie może eksfiltrować twoich kluczy API czytając swój własny auth_json.

​

3. Co zrobić po podejrzanym rug-pullu

1. Natychmiast wyłącz serwer — wyłączony serwer jest usuwany z rejestru runtime, a jego poświadczenia nigdy nie są odszyfrowywane. Użyj PUT /api/workspace/firewall/mcp_servers z "enabled": false.
2. Ponownie sonduj, aby wychwycić zmiany — POST /api/workspace/firewall/mcp_servers/:id/probe uruchamia tools/list i zwraca wszystkie nowe narzędzia, które pojawiły się od ostatniego sondowania.
3. Ponownie skanuj rekord skilla — POST /api/workspace/firewall/skills/:id/rescan ponownie uruchamia skaner wobec zaktualizowanego manifestu. Jeśli werdykt degraduje się do flagged lub blocked, Firewall emituje zdarzenie w twoim strumieniu.
4. Przejrzyj kolejkę pending_approval — wszystkie wywołania wstrzymane od czasu rug-pullu są w kolejce. Sprawdź i odmów je zamiast masowo zatwierdzać.
5. Audytuj log wywołań — sprawdź ślad zdarzeń Firewalla dla wywołań, które przeszły przed wykryciem zmiany.

​

4. Parowanie skanowania skilli z regułami firewalla

Skanowanie skilli i reguły firewalla są uzupełniające się i komponują:

• Reguła z tool_name_glob: community.* ustawiona na pending_approval zapewnia, że przejrzysz każde wywołanie z serwera ze źródeł społeczności, niezależnie od pasma ryzyka.
• Poddany kwarantannie skill nadpisuje regułę allow — nawet jeśli twoja polityka zezwala na http.fetch szeroko, poddany kwarantannie skill, który go posiada, nadal wstrzymuje wywołanie.
• Używaj skill_name_glob w regule do ograniczania bardziej rygorystycznych polityk do niezaufanych serwerów bez wpływu na twoje integracje first-party.

Zobacz Firewall: Serwery MCP dla pełnego modelu bramy i Firewall: Skille dla skanera i referencji trybów egzekwowania.

​

5. Powiązane zagrożenia

• Niebezpieczne wywołania narzędzi — reguły blokujące destrukcyjne lub nieodwracalne akcje narzędzi niezależnie od źródła.
• Eksfiltracja danych — reguły egress ograniczające, dokąd wywołania narzędzi mogą wysyłać dane.
• Model zagrożeń — pełna powierzchnia ataku, którą OrcaRouter jest zaprojektowany bronić.