Przejdź do głównej treści
Zewnętrzny serwer MCP to niezrecenzowany pakiet narzędzi, żywe poświadczenie i świeży zasięg sieciowy. W chwili, gdy agent dzwoni do jednego bezpośrednio, nikt nie obserwuje wywołania — a „serwer zmienił swoje narzędzia po tym, jak go zatwierdziłeś” to prawdziwy atak, nie hipoteza. Zanim skierujesz agenta na serwer, który ktoś inny obsługuje, chcesz powtarzalnej odprawy przedlotowej. Ta strona to ta odprawa przedlotowa: krótka, uporządkowana lista kontrolna do oceny połączeń serwera mcp na OrcaRouter przy użyciu kontroli, które już istnieją — ewaluacja per wywołanie, lista dozwolonych z domyślną odmową, limity egress, zaszyfrowane poświadczenia i kwarantanna skilla. Każdy krok linkuje do skupionej instrukcji po głębię. Uruchom ją raz na nowy serwer; uruchom ponownie kroki wrażliwe na dryf, gdy serwer się zmieni.
Każdy krok konfiguracji tutaj jest robiony z konsoli (lub z REST API twoim tokenem sesji/dostępu) i jest bramkowany rolami. Tylko trasy bramy firewalla i wywołania relay /v1/* noszą klucz w stylu sk-orca-....

​
1. Lista kontrolna do oceny połączeń serwera mcp

Pracuj z góry na dół. Pierwsze trzy kroki są obowiązkowe dla każdego serwera, którego sam nie obsługujesz; reszta go utwardza.

1. Zasonduj, zanim zaufasz

Odkryj prawdziwą listę narzędzi i osiągalność, zanim napiszesz choć jedną regułę.

2. Domyślna odmowa, potem lista dozwolonych

Dopuść tylko narzędzia, które zrecenzowałeś; wszystko inne jest odmawiane.

3. Zaszyfruj poświadczenie

Przechowuj auth tak, by było szyfrowane w spoczynku, maskowane przy odczycie, nigdy niewidziane przez model.

4. Zablokuj egress

Ogranicz, dokąd narzędzia serwera mogą sięgać w sieci.

5. Kwarantannuj samodzielnie instalowane skille

Wstrzymaj cokolwiek, co agent instaluje sam, dopóki człowiek tego nie zrecenzuje.

6. Najpierw shadow, potem obserwuj

Wytocz jako tylko-audit, potem czytaj zdarzenia i anomalie przed egzekwowaniem.

​
2. Zasonduj, zanim zaufasz

Nie możesz zrecenzować narzędzi, których nigdy nie widziałeś, a ogłoszona lista narzędzi serwera to rzecz najbardziej prawdopodobnie zmieniająca się pod tobą. Zarejestruj serwer, potem zasonduj go — brama uruchamia MCP initialize + tools/list wobec endpointu i zwraca prawdziwe narzędzia z ich schematami wejścia, plus status osiągalności ok, degraded lub down. 
# Trasa konsoli, wołana z twoim tokenem sesji/dostępu (UserAuth). Developer+.
curl -X POST \
  https://api.orcarouter.ai/api/workspace/firewall/mcp_servers/42/probe \
  -H "Authorization: Bearer <your-access-token>"
Przeczytaj nazwę każdego narzędzia i co przyjmują jego argumenty. Serwer ogłaszający shell.exec lub http_fetch, których się nie spodziewałeś, to ustalenie, nie detal — to cały sens sondowania najpierw.
Zasonduj ponownie, gdy serwer zmienia właściciela lub podejrzewasz dryf. Nowe narzędzie pojawiające się na liście — „rug pull” — to dokładnie to, na co uważasz. Zobacz Obrona przed rug-pull.
Pełna referencja rejestracji i sondowania mieszka w Firewall: serwery MCP; krok-po-kroku od początku do końca to Połącz serwer MCP.

​
3. Domyślna odmowa, potem lista dozwolonych narzędzi, które zrecenzowałeś

Lista dozwolonych to różnica między „serwer może robić sześć rzeczy” a „serwer może robić cokolwiek jego operator zdecyduje jutro”. Ustaw default_verdict polityki na deny, potem dodaj regułę per narzędzie, które zrecenzowałeś i któremu ufasz. Ponieważ brama tworzy przestrzeń nazw każdego narzędzia <server>.<tool>, możesz zawęzić reguły do jednego serwera, nie dotykając innych. 
// Polityka na powierzchni mcp: domyślnie deny, dopuść tylko to, co zrecenzowałeś.
// tool_name_glob wspiera wildcard pełnosegmentowy: "github.*" (prefiks),
// "*.exec" (sufiks) lub "*.shell.*" (infiks). Globy w środku segmentu jak
// "github.get_*" spadają do dokładnego dopasowania i się nie rozwiną.
{
  "default_verdict": "deny",
  "rules": [
    { "tool_name_glob": "github.create_issue", "verdict": "allow" },
    { "tool_name_glob": "github.get_issue",    "verdict": "allow" }
  ]
}
Teraz github.create_issue się uruchamia, github.get_issue się uruchamia, a świeżo wprowadzone github.delete_repo jest odmawiane, dopóki nie zrecenzujesz i nie dopuścisz. Odmówione tools/call wraca do modelu jako błąd narzędzia (firewall deny: …) — agent się dostosowuje, zamiast się wysypywać. Zobacz Lista dozwolonych narzędzi MCP po pełny przepis i Reguły firewalla po DSL dopasowywania.

​
4. Zaszyfruj poświadczenie — nigdy nie ręcznie sklejaj auth

Zewnętrzny serwer prawie zawsze potrzebuje poświadczenia, a poświadczenie to rzecz, którą najmniej chcesz mieć leżącą w tekście jawnym lub docierającą do modelu. Zarejestruj auth serwera przez OrcaRouter, tak by było szyfrowane w spoczynku, maskowane przy odczycie i wstrzykiwane tylko w czasie dyspozycji. auth_mode to jedno z none, bearer, oauth lub basic: 
# Trasa konsoli, UserAuth, Developer+.
curl https://api.orcarouter.ai/api/workspace/firewall/mcp_servers \
  -H "Authorization: Bearer <your-access-token>" \
  -H "Content-Type: application/json" \
  -d '{
    "name": "github",
    "endpoint": "https://api.githubcopilot.com/mcp",
    "auth_mode": "bearer",
    "auth_json": "{\"token\":\"ghp_x\"}"
  }'
Poświadczenie jest szyfrowane i maskowane w chwili, gdy jest przechowywane — nigdy nie dociera do modelu ani klienta, a przy odczycie widzisz tylko maskę. Przy aktualizacji odeślij maskę z powrotem, aby zachować przechowywaną wartość; wyślij świeży auth_json tylko wtedy, gdy rotujesz. Zobacz Uwierzytelnij i Rotacja poświadczeń.

​
5. Zablokuj egress: dokąd jego narzędzia mogą sięgnąć?

Werdykty per wywołanie decydują, które narzędzie się uruchamia; egress decyduje, dokąd może sięgnąć. Narzędzie, które „zwraca dane”, i narzędzie, które „eksfiltruje twoje sekrety na host atakującego”, mogą być tym samym narzędziem z innym argumentem — kontrola egress to to, co je rozróżnia. Brama już waliduje każdy zdalny endpoint i jego rozwiązane IP wybierania wobec polityki SSRF na każdym przeskoku, odmawiając zakresów intranetowych i adresu metadanych chmury i ponownie sprawdzając IP, by pokonać DNS rebinding. Na wierzchu tego autoruj własną regułę deny egress dla hostów i CIDR-ów, których ten serwer nigdy nie powinien dotknąć: 
// Reguła etapu egress zawęża swój werdykt do wychodzącego celu.
// egress_json niesie listy allow + deny host/CIDR.
{
  "stage": "egress",
  "verdict": "deny",
  "egress_json": "{\"deny\":[\"10.0.0.0/8\"]}"
}
Nie ma presetu, który dostarcza za ciebie reguły CIDR — sam autorujesz listę deny host/CIDR, zawężoną do tego, czego ten serwer legalnie potrzebuje. Zobacz Limity egress i Eksfiltrację danych.

​
6. Kwarantannuj to, co agent instaluje sam

Serwer, który zarejestrowałeś, to jedno ryzyko; skille, serwery MCP BYO i wtyczki, które agent sam instaluje potem, to inne. OrcaRouter skanuje każdą instalowalną zdolność, przypisuje jej pasmo ryzyka i wyprowadza tryb egzekwowania — allow, quarantine lub block — który jedzie na wierzchu każdego werdyktu reguły. Cokolwiek auto-wykrytego przy pierwszym użyciu jest kwarantannowane, dopóki człowiek tego nie zrecenzuje: zdolność, której nikt nie zatwierdził, nie dostaje darmowej przepustki tylko dlatego, że przeszła skan łagodnie. Zdolność w quarantine eskaluje cokolwiek krótszego niż deny do pending_approval, więc jej narzędzia uruchamiają się dopiero po tym, jak spojrzysz.
Nie próbuj rejestrować każdego skilla ręcznie. Zatwierdź z góry te, którym ufasz, i pozwól reszcie być auto-wykrytą i kwarantannowaną — potem recenzuj z prawdziwych danych. Tryb zaostrza się ściślej przy ponownym skanie, nigdy luźniej. Zobacz Firewall: skille i Zatruwanie narzędzi MCP.

​
7. Najpierw shadow, potem obserwuj ślad

Nie przełączaj świeżutkiego serwera prosto na egzekwowanie. Postaw politykę w trybie shadow — egzekwujące werdykty są obniżone do audit i logowane jako [shadow] would … — tak byś mógł zobaczyć, co zostałoby zablokowane, zanim faktycznie jest. Gdy ślad audytu wygląda poprawnie, zdejmij tryb shadow i egzekwuj. Gdy żywe, kontrole nadal obserwują:
Każde zarządzane wywołanie rejestruje swój werdykt, powierzchnię i dopasowaną regułę. Czytaj je, by potwierdzić, że lista dozwolonych i reguły egress zachowują się zgodnie z zamiarem. Zobacz Audyt zdarzeń MCP.
Skoki tempa i kosztu wobec wyuczonej bazy, plus pętle ponowień i nowe ścieżki narzędzi, wystawiają się jako anomalie — odczytywalne przez każdego Membera.
Włącz tryb observe, by logować wywołania, których polityka jeszcze nie pokrywa, jako luki, tak byś zaostrzał z tego, co agent faktycznie robi, a nie ze zgadywania.

​
8. Szybka ścieżka: wybierz poziom autonomii

Jeśli wolisz nie budować ręcznie kroków 3–5 dla serwera, któremu nie w pełni ufasz, zastosuj poziom autonomii i edytuj stamtąd. Poziomy piszą prawdziwe, edytowalne wiersze polityki i guardrail — to punkt startowy, nie czarna skrzynka:
PoziomCo ustawia
permissiveTryb observe włączony — loguje wszystko, nie egzekwuje niczego.
balancedPolityka default-audit, która odmawia destrukcyjnego shella, plus guardrail PII Shield w trybie tylko-flag.
tightPolityka domyślnej odmowy odmawiająca destrukcyjnego shella i narzędzi o kształcie fetch (http_fetch/web_search/fetch_url/request — wektor SSRF), plus guardraile PII Shield i Secrets Blocker egzekwowane. Sekrety w argumentach są łapane przez guardrail Secrets Blocker na żądaniu, nie przez regułę arg-narzędzia.
Dla zewnętrznego serwera, który wciąż oceniasz, zacznij na tight, zasonduj, potem rozluźnij konkretne narzędzia do listy dozwolonych. Cofnięcie jednym kliknięciem przywraca migawkę sprzed zastosowania.
Odczyty ustawień, polityk, odkrytych narzędzi, anomalii, zarejestrowanych serwerów MCP i skilli są otwarte dla każdego Membera; odczyty zdarzeń, uruchomień i agregatów wymagają Developer+, a każdy zapis wymaga Developer+. Ujawnienie tekstu jawnego klucza tokenu to również Developer+.

​
9. Dokąd dalej

Połącz serwer MCP

Zarejestruj, zasonduj i wyeksponuj serwer przez bramę.

Lista dozwolonych narzędzi MCP

Domyślnie odmawiaj serwerowi i zezwól tylko na zrecenzowane narzędzia.

Obrona przed rug-pull

Złap serwer lub skill, który zmienia się po tym, jak go zatwierdziłeś.

Przegląd bezpieczeństwa MCP

Pełna mapa powierzchni zarządzania MCP.
Nowy w modelu? Przeczytaj Guardrails vs. firewall po to, gdzie pasuje zarządzanie MCP, potem Nadmierną sprawczość i Niebezpieczne wywołania narzędzi dla zagrożeń, które ta lista kontrolna zamyka.