Przejdź do głównej treści
Agent mówiący w Model Context Protocol (MCP) jest tylko tak bezpieczny, jak serwery, z którymi się łączy. Każdy serwer MCP to świeży zestaw narzędzi, świeże poświadczenie i świeży zasięg sieciowy — a w chwili, gdy agent dzwoni do jednego bezpośrednio, nikt nie obserwuje wywołania. To jest cały problem, który bezpieczeństwo mcp musi rozwiązać: nie „czy to jedno narzędzie jest bezpieczne”, ale „kto zarządza wszystkimi z nich, przy każdym wywołaniu, z jednym śladem audytu.” Odpowiedzią OrcaRoutera jest pojedynczy audytowany punkt zwężenia. Rejestrujesz każdy serwer MCP raz; agenty łączą się z jedną bramą; a każde tools/call przebiega przez silnik firewalla, zanim dotrze do prawdziwego serwera. Ta strona to mapa tej powierzchni — brama, werdykt per wywołanie, zarządzanie skillami, egress i zaszyfrowane poświadczenia — z linkami do skupionych instrukcji dla każdego z nich.
Każda akcja zarządzania tutaj jest konfigurowana z konsoli (lub z REST API przy użyciu twojego tokenu sesji/dostępu) i jest bramkowana rolami. Tylko wywołania relay /v1/* oraz trasy bramy firewalla noszą klucz w stylu sk-orca-....

​
1. Dlaczego bezpieczeństwo mcp potrzebuje bramy

Skieruj dziesięć agentów na pięć społecznościowych serwerów MCP bezpośrednio, a dostaniesz najgorsze z każdego świata: brak wspólnej polityki, brak śladu audytu, poświadczenia skopiowane do dziesięciu konfiguracji agentów oraz narzędzie o nazwie shell.exec o jedno przekierowanie od twojego endpointu metadanych chmury. Brama zwija to w jedno zarządzane połączenie.

Jedno połączenie, każdy serwer

Agenty łączą się z pojedynczym endpointem. Brama agreguje narzędzia każdego włączonego, osiągalnego serwera pod przestrzenią nazw <server>.<tool>.

Polityka na każdym wywołaniu

Każde tools/call jest ewaluowane przez twoją politykę firewalla przed dyspozycją.

Zaszyfrowane poświadczenia

Sekrety auth serwera są szyfrowane w spoczynku, maskowane przy odczycie i wstrzykiwane przy dyspozycji — nigdy nie docierają do modelu ani klienta.

Egress pod kontrolą

Endpoint zarejestrowanego serwera jest domyślnie walidowany wobec prywatnych zakresów IP i metadanych chmury. Dla celów per-narzędzie zastosuj bazową denylistę egress SSRF lub autoruj własne reguły host/CIDR.
Po fundamenty stojące za tym wszystkim zajrzyj do Zabezpieczania agentów AI i Dlaczego zero trust.

​
2. Cztery klocki konstrukcyjne

Zarządzanie MCP na OrcaRouter to cztery współpracujące elementy. Wybierz ten, który pasuje do pytania, na które próbujesz odpowiedzieć.
Pojedynczy endpoint, z którym łączą się twoje agenty zamiast dzwonić do serwerów bezpośrednio. Agreguje narzędzia każdego zarejestrowanego serwera, z przestrzenią nazw <server>.<tool>, i re-eksponuje schemat wejścia każdego narzędzia dosłownie. Zacznij od Połącz serwer MCP i Uwierzytelnij; pełna referencja mieszka w Firewall: serwery MCP.
Brama przepuszcza każde tools/call przez firewall na powierzchni mcp i zwraca werdykt — allow, audit, deny, sanitize lub pending_approval — przed dyspozycją. Zobacz Lista dozwolonych narzędzi MCP i Oczyszczanie argumentów narzędzi.
Zdolności, które agent sam instaluje — skille, serwery MCP BYO, wtyczki — są skanowane, otrzymują pasmo ryzyka i tryb egzekwowania (allow / quarantine / block), który jedzie na wierzchu każdego werdyktu reguły. Zobacz Firewall: skille i Obrona przed rug-pull.
Sekret auth każdego serwera jest szyfrowany w spoczynku i maskowany przy odczycie. Zobacz Uwierzytelnij i Rotacja poświadczeń.

​
3. Jak ewaluowane jest tools/call

Gdy agent wywołuje narzędzie przez bramę, wywołanie nie idzie prosto do serwera. Jest dopasowywane wobec polityki twojej przestrzeni roboczej, na wierzchu nakładany jest tryb egzekwowania posiadającego skilla, i tylko werdykt allow / audit / sanitize dociera do prawdziwego serwera.
WerdyktCo widzi agent
allow / auditPrzesłane. audit dodatkowo loguje zdarzenie.
sanitizePrzesłane z zredagowanymi argumentami (nigdy wynikiem).
deny / pending_approvalZwrócone jako błąd narzędzia, więc agent może się dostosować, zamiast się wysypać.
Zablokowane wywołanie MCP wraca jako błąd narzędzia (firewall deny: …), w tym samym kształcie, jaki zwraca dowolne zawodzące narzędzie — agent może spróbować inaczej, zapytać użytkownika lub zatrzymać się. To nie jest awaria transportu.
Słownik werdyktów, powierzchnie i dopasowywanie reguł są udokumentowane w całości w Firewall i Reguły firewalla; model koncepcyjny jest w Trybach egzekwowania i Jak OrcaRouter inspekcjonuje.

​
4. Zarejestruj serwer (jeden konkretny przykład)

Rejestrujesz każdy serwer raz. Rekord serwera niesie name (unikalny per przestrzeń robocza, bez .), endpoint, auth_mode (none / bearer / oauth / basic) i jego zaszyfrowane poświadczenia. Zrób to z konsoli — zapis wymaga Developer+. 
# Trasa konsoli, wołana z twoim tokenem sesji/dostępu (UserAuth).
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\"}",
    "enabled": true
  }'
Następnie zasonduj go, by odkryć jego narzędzia i zarejestrować osiągalność (ok / degraded / down): 
curl -X POST \
  https://api.orcarouter.ai/api/workspace/firewall/mcp_servers/42/probe \
  -H "Authorization: Bearer <your-access-token>"
Teraz możesz pisać reguły wobec github.*, wiedząc dokładnie, co przyjmuje github.create_issue. Krok-po-kroku od początku do końca mieszka w Połącz serwer MCP.
Sekrety nigdy nie są przechowywane jako tekst jawny. auth_json jest szyfrowany w spoczynku i maskowany przy odczycie; przy aktualizacji odeślij maskę z powrotem, aby zachować przechowywaną wartość. Zobacz Rotacja poświadczeń.

​
5. Połącz agenta z bramą

Gdy serwery są zarejestrowane, skieruj dowolnego klienta MCP na bramę z kluczem w zakresie firewall-gateway (token bez tego zakresu dostaje 403): 
https://api.orcarouter.ai/api/v1/firewall/mcp
Brama mówi streamable HTTP i ogłasza narzędzia każdego włączonego, osiągalnego serwera pod przestrzenią nazw <server>.<tool>. SDK, który sam proxuje wywołania, może odczytać rejestr czasu wykonania z GET /api/v1/firewall/mcp_servers tym samym tokenem bramy.

​
6. Zablokuj, dokąd narzędzia mogą sięgnąć

Werdykty per wywołanie zarządzają którym narzędziem; kontrole egress zarządzają dokąd może ono sięgnąć. Współpracują dwie warstwy. Po pierwsze, gdy brama łączy się z endpointem zarejestrowanego serwera, ten URL jest domyślnie walidowany wobec zakresów prywatnych (RFC1918), loopback, link-local i metadanych chmury — a host jest rozwiązywany przez DNS, więc nazwa, która rozwiązuje się w zablokowany zakres, też jest odmawiana. Więc serwer BYO skierowany na 169.254.169.254 lub adres intranetowy jest odrzucany, chyba że wyraźnie umieściłeś go na białej liście. Po drugie, dla celów per-narzędzie reguła egress niesie listę allow/deny host/CIDR dopasowywaną wobec wychodzącego celu wywołania na powierzchni egress. Szablon bazowego przypadku użycia dostarcza gotową regułę deny egress, której lista już pokrywa zakresy prywatne, loopback, link-local i metadanych chmury (w tym 169.254.169.254 i metadata.google.internal), więc jej zastosowanie daje ci obronę SSRF/metadanych bez autorowania CIDR-ów ręcznie.
SSRF i egress to różnica między „to narzędzie zwróciło dane” a „to narzędzie wyeksfiltrowało twoje sekrety na host atakującego.” Zastosuj bazową denylistę egress i dodaj własne reguły host/CIDR — zobacz Limity egress i Eksfiltracja danych.

​
7. Obserwuj to: zdarzenia, uruchomienia i anomalie

Każde zarządzane wywołanie zostawia ślad. Zdarzenia firewalla rejestrują werdykt, powierzchnię i dopasowaną regułę; uruchomienia grupują wywołania sesji; a strumień anomalii flaguje skoki tempa i kosztu wobec wyuczonej bazy. Odczyty ustawień, polityk i odkrytych narzędzi są otwarte dla każdego Membera; odczyty zdarzeń/uruchomień/agregatów wymagają Developer+.

​
8. 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 narzędzia, które zrecenzowałeś.

Obrona przed rug-pull

Zarządzaj serwerami i skillami, które zmieniają się po tym, jak je zatwierdziłeś.

Firewall: serwery MCP

Pełna referencja pól i tras.
Nowy w modelu? Przeczytaj Guardrails vs. firewall, aby zobaczyć, gdzie pasuje zarządzanie MCP, potem Zatruwanie narzędzi MCP i Nadmierna sprawczość dla zagrożeń, które zamyka.