Przejdź do głównej treści
Model Context Protocol (MCP) pozwala agentom wywoływać narzędzia hostowane przez zewnętrzne serwery. To w równej mierze potężne i niebezpieczne: każdy serwer MCP, do którego agent się łączy, to świeży zestaw narzędzi, poświadczeń i zasięgu sieciowego, których nikt nie zrecenzował. Brama MCP Firewalla stawia pojedynczy audytowany punkt zwężenia przed nimi wszystkimi. Rejestrujesz każdy serwer MCP raz; brama wystawia ich narzędzia twoim agentom pod jednym połączeniem i przepuszcza każde tools/call przez silnik firewalla, zanim dotrze ono do prawdziwego serwera.

​
1. Co daje ci zarządzanie MCP

  • Jedna brama, każdy serwer. Twój agent łączy się z jednym endpointem. Brama agreguje narzędzia każdego osiągalnego zarejestrowanego serwera, w przestrzeni nazw <server>.<tool>, więc github.create_issue i shell.exec pojawiają się obok siebie pod jednym połączeniem MCP.
  • Polityka na każdym wywołaniu. Każde tools/call jest najpierw ewaluowane przez twoją politykę. Zablokowane wywołanie wraca do modelu jako błąd narzędzia (firewall deny: …), a nie awaria transportu, więc agent może zareagować, zamiast się wysypać. sanitize przepisuje argumenty przed przesłaniem; pending_approval wstrzymuje wywołanie.
  • Z ochroną SSRF. Zdalne endpointy są walidowane wobec polityki SSRF bramy — zakresy intranetowe i adresy metadanych chmury są blokowane, a rozwiązany IP wybierania jest ponownie sprawdzany, by pokonać DNS rebinding, na każdym przeskoku włącznie z przekierowaniami.
  • Zaszyfrowane poświadczenia. Sekrety auth serwera są szyfrowane w spoczynku i maskowane przy odczycie. Brama wstrzykuje je w czasie dyspozycji; nigdy nie docierają do modelu ani klienta.

​
2. Dwa rodzaje serwera

RodzajendpointZachowanie
BYO (bring-your-own)URL streamable-HTTPBrama proxuje tools/call do twojego zdalnego serwera MCP.
Dołączony (bundled)pustySerwer MCP OrcaRouter działający in-process. Zarejestrowany, by był widoczny i zarządzalny; nie sondowany osobno.

​
3. Rejestracja serwera

Rekord serwera niesie:
PoleUwagi
nameKlucz biznesowy, unikalny per przestrzeń robocza, ≤ 128 znaków. Bez . — to separator przestrzeni nazw <server>.<tool>.
endpointURL serwera MCP (≤ 512 znaków). Pusty dla dołączonego serwera.
auth_modenone (domyślnie), bearer, oauth lub basic.
auth_jsonPoświadczenia specyficzne dla trybu (zobacz niżej). Wymagane zawsze, gdy auth_mode nie jest none.
enabledDomyślnie true. Wyłączony serwer jest całkowicie pominięty w bramie.
statusOsiągalność — ok (domyślnie), degraded lub down. Ustawiana przez sondowanie.
Kształty poświadczeń wg trybu: 
// bearer
{ "token": "ghp_…" }
// oauth
{ "client_id": "…", "client_secret": "…", "token_url": "…" }
// basic
{ "username": "…", "password": "…" }
// none
""
Żądanie rejestracji wygląda tak: 
curl https://api.orcarouter.ai/api/workspace/firewall/mcp_servers \
  -H "Authorization: Bearer sk-orca-..." \
  -H "Content-Type: application/json" \
  -d '{
    "name": "github",
    "endpoint": "https://api.githubcopilot.com/mcp",
    "auth_mode": "bearer",
    "auth_json": "{\"token\":\"ghp_x\"}",
    "enabled": true
  }'
Zduplikowana nazwa w tej samej przestrzeni roboczej zwraca HTTP 409 (ta sama nazwa w innej przestrzeni roboczej jest w porządku).
Sekrety nigdy nie są przechowywane jako tekst jawny. auth_json jest szyfrowany w spoczynku kluczem sekretów przestrzeni roboczej. Jeśli ten klucz nie jest skonfigurowany, zapis jest odrzucany, zamiast utrwalać poświadczenie niezaszyfrowane. Przy odczycie sekrety i endpoint są maskowane; odeślij maskę z powrotem przy aktualizacji, aby zachować przechowywaną wartość. Przełączanie między dwoma trybami auth z poświadczeniami wymaga świeżego auth_json (szyfrogram jest związany kształtem ze swoim trybem).

​
4. Sondowanie — odkryj jego narzędzia

Zanim będziesz mógł napisać reguły wobec narzędzi serwera, musisz znać ich nazwy. Zasonduj serwer: 
curl -X POST \
  https://api.orcarouter.ai/api/workspace/firewall/mcp_servers/42/probe \
  -H "Authorization: Bearer sk-orca-..."
Brama uruchamia MCP initialize + tools/list wobec endpointu (używając odszyfrowanych poświadczeń, ograniczona do 10s), rejestruje status osiągalności oraz znacznik czasu i zwraca ogłoszone narzędzia wraz z ich schematami wejścia: 
{
  "status": "ok",
  "last_checked_at": 1700000000,
  "tools": [
    { "name": "create_issue", "description": "…", "input_schema": { } }
  ]
}
Teraz możesz autorować reguły jak tool_name_glob: github.*, wiedząc dokładnie, co przyjmuje github.create_issue. Dołączony serwer (z pustym endpointem) nie jest sondowalny i zwraca 400.

​
5. Cykl życia i egzekwowanie

  • Włączony vs. wyłączony. Wyłączony serwer jest usuwany z rejestru czasu wykonania — jego narzędzia znikają z bramy, a jego poświadczenia nigdy nie są odszyfrowywane. To przełącznik wyłączający.
  • Osiągalność. status (ok / degraded / down) odzwierciedla ostatnie sondowanie; nieosiągalny serwer jest pomijany, gdy brama buduje swój zestaw narzędzi.
  • Werdykt per wywołanie. Przy dyspozycji silnik zwraca werdykt dla konkretnego wywołania <server>.<tool> z jego argumentami:
    • allow / audit → przesłane (audit loguje, wciąż dopuszcza).
    • sanitize → przesłane z przepisanymi argumentami.
    • deny / pending_approval / cokolwiek nieznanego → zablokowane jako błąd narzędzia. (Przez ujednoliconą bramę wstrzymane wywołanie wypływa jako trwały błąd, zamiast przewlekać id zatwierdzenia — użyj hooka evaluate, gdy potrzebujesz uścisku dłoni zatwierdzenia.)
  • Usunięcie to miękkie usunięcie; slot nazwy jest zwalniany natychmiast, więc możesz ponownie zarejestrować pod tą samą nazwą.
Każda zmiana natychmiast unieważnia per-przestrzeń-roboczą cache narzędzi bramy, więc nowo zarejestrowany, wyłączony lub ponownie zasondowany serwer wchodzi w życie przy następnym połączeniu, a nie po TTL cache.

​
6. Łączenie klienta

Skieruj dowolnego klienta MCP na endpoint bramy z tokenem w zakresie firewall-gateway: 
https://api.orcarouter.ai/api/v1/firewall/mcp
Brama mówi streamable HTTP (POST wiadomości, GET dla strumienia SSE, DELETE do zakończenia sesji) i identyfikuje się jako orcarouter-firewall-gateway. Ogłasza narzędzia każdego włączonego, osiągalnego serwera pod przestrzenią nazw <server>.<tool>, re-eksponując schemat wejścia każdego narzędzia dosłownie. Token bez zakresu firewall-gateway dostaje 403 — wybij dedykowany token bramy do tego.

​
API reference

​
Konsola (w zakresie przestrzeni roboczej, RBAC)

Metoda i ścieżkaRolaCel
GET /api/workspace/firewall/mcp_serversMemberLista serwerów (sekrety zamaskowane, endpoint zredagowany).
GET /api/workspace/firewall/mcp_servers/:idMemberPojedynczy serwer, zamaskowany.
POST /api/workspace/firewall/mcp_serversDeveloper+Zarejestruj serwer (409 przy zduplikowanej nazwie).
PUT /api/workspace/firewall/mcp_serversDeveloper+Zaktualizuj serwer (id w ciele).
DELETE /api/workspace/firewall/mcp_servers/:idDeveloper+Miękkie usunięcie; zwalnia nazwę.
POST /api/workspace/firewall/mcp_servers/:id/probeDeveloper+Zasonduj osiągalność + odkryj narzędzia.

​
Brama (token w zakresie firewall-gateway)

Metoda i ścieżkaCel
ANY /api/v1/firewall/mcpUjednolicony endpoint dyspozycji bramy MCP.
GET /api/v1/firewall/mcp_serversRejestr czasu wykonania (odszyfrowane auth, tylko włączone serwery) dla proxy SDK.
POST /api/v1/firewall/evaluateEwaluuj pojedyncze tools/call, zanim sam je zdyspozytujesz.

​
FAQ

Żeby było jedno miejsce, które widzi każde wywołanie narzędzia. Bez bramy każdy agent łączy się z każdym serwerem MCP bezpośrednio — brak wspólnej polityki, brak śladu audytu, brak ochrony SSRF i poświadczenia rozproszone po konfiguracjach agentów. Brama centralizuje to wszystko: jedno połączenie, jedna polityka, jeden audytowany log, zaszyfrowane sekrety wstrzykiwane przy dyspozycji.
Model odbiera je jako błąd narzędzia (firewall deny: <reason>), w tym samym kształcie, jaki dostałby z dowolnego zawodzącego narzędzia. To pozwala agentowi się dostosować — spróbować innego podejścia, zapytać użytkownika lub zatrzymać się — zamiast traktować to jako awarię transportu.
Tak — po to właśnie jest przestrzeń nazw <server>.<tool>. Reguła z tool_name_glob: trusted.* może allow, podczas gdy community.* jest audit-owane lub pending_approval. Połącz to z globem nazwy skilla dla jeszcze drobniejszego zawężenia.
Tak. URL-e endpointów i ich rozwiązane IP wybierania są walidowane wobec polityki SSRF przy rejestracji i na każdym przeskoku dyspozycji — zakresy intranetowe i adres metadanych chmury są odrzucane, a rozwiązany IP jest ponownie sprawdzany, by pokonać DNS rebinding. Sparuj to z regułą egress, aby zarządzać tym, dokąd narzędzia mogą sięgać.

​
Zobacz także

Chcesz głębiej wejść w bezpieczeństwo agentów? Przewodniki Secure Your Agents (Zero Trust) osadzają tę funkcję w przepływie pracy zero-trust.

Zabezpiecz serwery MCP (Zero Trust)

Łącz, uwierzytelniaj i zarządzaj serwerami MCP w postawie zero-trust.

Lista kontrolna zaufania MCP

Co zweryfikować, zanim zaufasz serwerowi MCP innej firmy.