Przejdź do głównej treści
Agent MCP to agent z zasięgiem. Każdy serwer Model Context Protocol, do którego się łączy, to świeży zestaw narzędzi, poświadczeń i celów sieciowych, których nikt nie przejrzał — a agent może wciągnąć nowy w środku uruchomienia. Ten przepis pokazuje cztery ruchy, które zamieniają rozrośniętą konfigurację MCP w zarządzaną na hostowanej bramie: jedna audytowana brama MCP, kwarantanna skilli, odmowa egress i zaszyfrowane uwierzytelnianie serwera. Wszystko to konfigurujesz z konsoli (lub REST API) wobec swojej przestrzeni roboczej. Twój agent dalej mówi MCP dokładnie jak wcześniej.

​
1. Po co zabezpieczać agenta MCP

Skieruj agenta na pięć serwerów MCP bezpośrednio, a masz pięć granic zaufania, pięć magazynów poświadczeń i zero wspólnego śladu audytu. Wywołanie tools/call, które odczytuje rekord klienta, i to, które uruchamia polecenie shell, wyglądają identycznie dla modelu, a serwer społecznościowy może po cichu zażądać shell.exec i zewnętrznego zakresu sieciowego przy pierwszym załadowaniu. Naprawa polega na uczynieniu OrcaRouter jedynym punktem zwężenia, który przekracza każde wywołanie. Aby zabezpieczyć ruch agenta MCP od początku do końca, kierujesz całą dyspozycję MCP przez bramę MCP Firewalla, więc każde tools/call jest ewaluowane przez politykę zanim dotrze do prawdziwego serwera — ze skillami ocenionymi pod kątem ryzyka, zarządzanym egress i poświadczeniami zaszyfrowanymi w spoczynku.
To przepis — zszywa istniejące funkcje w jedno konkretne przejście utwardzające. Dla pełnej referencji podążaj za linkami do Firewall, Serwery MCP oraz Skille.

​
2. Zacznij od bazy Secure Agents

Zanim napiszesz cokolwiek na zamówienie, ustaw postawę. W konsoli otwórz Firewall → Posture i zastosuj poziom autonomii balanced (poziom autonomii) (rola Developer). W jednej transakcji audytuje wywołania narzędzi i flaguje PII, jednocześnie odmawiając najbardziej destrukcyjnych akcji — obserwujesz, zanim szeroko egzekwujesz, z cofnięciem jednym kliknięciem. Gdy strumienie Events i Runs wyglądają dobrze, przejdź do tight: domyślna odmowa, destrukcyjny shell odmówiony, egress w kształcie SSRF odmówiony, plus egzekwowane guardrails PII Shield i Secrets Blocker. Ten pojedynczy przełącznik to podłoga, na której buduje ten przepis.
Wolisz wjeżdżać bez przełączania całej przestrzeni roboczej? Napisz poniższe reguły do jednej nazwanej polityki i włącz jej tryb cienia — ewaluuje i loguje, ale degraduje każdy egzekwujący werdykt do audit (powód poprzedzony [shadow] would …), dopóki nie jesteś pewien. Zobacz tryby egzekwowania.

​
3. Kieruj każde tools/call przez jedną bramę MCP

Zarejestruj każdy serwer MCP raz; brama agreguje ich narzędzia pod jednym połączeniem (przestrzeń nazw <server>.<tool>) i przepuszcza każde tools/call przez silnik firewalla. Zarejestruj serwer z konsoli (lub REST API, Developer+): 
curl https://api.orcarouter.ai/api/workspace/firewall/mcp_servers \
  -H "Authorization: Bearer <your-session-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 skieruj swojego klienta MCP na bramę — nie na serwery nadrzędne — używając dedykowanego klucza w zakresie firewall-gateway: 
https://api.orcarouter.ai/api/v1/firewall/mcp
Teraz github.create_issue i shell.exec pojawiają się obok siebie pod jednym połączeniem, a każda dyspozycja jest ewaluowana, zanim się uruchomi. Zablokowane wywołanie wraca do modelu jako błąd narzędzia (firewall deny: …), nie jako awaria transportu, więc agent może się dostosować.
Zwykły klucz relay dostaje 403 na trasie bramy /api/v1/firewall/mcp. Wybij dedykowany token bramy (is_firewall_gateway) dla połączenia MCP; odczyt plaintextu tego klucza bramy wymaga Admin+.
Zanim będziesz mógł pisać reguły wobec narzędzi serwera, przesonduj go, by odkryć ich nazwy i schematy: 
curl -X POST \
  https://api.orcarouter.ai/api/workspace/firewall/mcp_servers/42/probe \
  -H "Authorization: Bearer <your-session-token>"

​
4. Poddaj kwarantannie skille, które agent wciąga

Brama MCP zarządza wywołaniami; zarządzanie skillami zarządza zdolnościami, które agent ładuje. Każdy instalowalny skill, własny serwer MCP lub wtyczka są skanowane do pasma ryzyka i trybu egzekwowania, który jedzie na wierzchu każdego werdyktu reguły:
TrybEfekt w czasie wykonywania
allowWerdykty reguł decydują; skill niczego nie dodaje.
quarantineCokolwiek poniżej deny jest wstrzymane do pending_approval.
blockNarzędzia skilla są wymuszenie odmówione.
Sedno dla agenta MCP: zdolność, której nikt nie zatwierdził, nie dostaje darmowej przepustki. Gdy agent samodzielnie coś instaluje, a jego narzędzia po raz pierwszy przekraczają bramę, Firewall auto-wykrywa to i poddaje kwarantannie, dopóki człowiek tego nie przejrzy — nawet jeśli skanowanie wypadło czysto. Zatwierdź z góry serwery, którym ufasz; pozwól reszcie wylądować w kolejce przeglądu.
Trzymaj balanced/observe włączone, gdy poznajesz, co twój agent faktycznie instaluje, potem awansuj zaufane skille do allow i pozostaw długi ogon w kwarantannie. Zobacz Skille.

​
5. Odmów egress w kształcie SSRF

Skompromitowane lub zdezorientowane narzędzie MCP sięgające po cloud-metadata lub host w intranecie to klasyczna ścieżka eksfiltracji. Dwie warstwy ją pokrywają. Po pierwsze, brama waliduje każdy zdalny endpoint MCP i jego rozwiązany IP połączenia wobec polityki SSRF przy rejestracji i na każdym przeskoku dyspozycji — zakresy intranetu i adres cloud-metadata są odrzucane, ponownie sprawdzane, by pokonać DNS rebinding. To jest wbudowane; nie konfigurujesz tego. Po drugie, poziom autonomii tight dostarcza preset egress SSRF, który odmawia nazw narzędzi w kształcie fetch — http_fetch, web_search, fetch_url, request oraz ich formy w przestrzeni nazw <server>.* — więc narzędzie, którego całe zadanie to „idź pobierz ten URL”, jest zatrzymane, zanim wybierze numer. Aby zarządzać tym, dokąd narzędzia mogą sięgać po celu, napisz własną regułę egress z listą deny host/CIDR — to powierzchnia do przypinania zasięgu wychodzącego: 
// firewall rule, egress stage — deny outbound to an internal range.
// egress_json is a JSON *string*: {"deny":[…],"allow":[…]} of hosts/CIDRs.
{
  "stage": "egress",
  "verdict": "deny",
  "egress_json": "{\"deny\":[\"10.0.0.0/8\",\"169.254.169.254\"]}"
}
Żaden preset nie dostarcza reguł egress CIDR — preset SSRF dopasowuje nazwy narzędzi, nie cele. Napisz listę deny host/CIDR sam, gdy potrzebujesz kontroli na poziomie celu. Zobacz listy egress oraz zatrzymaj eksfiltrację.

​
6. Trzymaj poświadczenia serwera zaszyfrowane

Każde auth_json serwera MCP jest zaszyfrowane w spoczynku i maskowane przy odczycie; brama wstrzykuje poświadczenia w czasie dyspozycji, więc nigdy nie docierają do modelu ani klienta. Obsługiwane wartości auth_mode:
{ "token": "…" } — statyczny token bearer, wysyłany jako Authorization: Bearer.
{ "client_id": "…", "client_secret": "…", "token_url": "…" } — OAuth w trybie client-credentials; brama pobiera i odświeża token.
{ "username": "…", "password": "…" } — HTTP Basic auth.
"" — serwer nieuwierzytelniony. Domyślny.
Przy odczycie sekret jest maskowany; odbij maskę z powrotem przy aktualizacji, aby zachować przechowywaną wartość. status serwera (ok / degraded / down) z ostatniej sondy mówi ci, czy jest osiągalny, zanim na nim polegniesz.

​
7. Dodaj guardrail treści na żądaniu

Firewall zarządza akcjami; sparuj go z Guardrailem, aby tekst przepływający przez twojego agenta MCP też był prześwietlany. Preset Secrets Blocker wychwytuje poświadczenia w żądaniu, zanim model — lub jakiekolwiek narzędzie — je zobaczy, a PII Shield maskuje identyfikatory w drodze do środka. Oba włączają się z poziomem autonomii tight, albo dołącz nazwany guardrail do klucza relay agenta przez guardrail_id.
Werdykt sanitize firewalla redaguje argumenty wywołania narzędzia, nigdy treść, którą narzędzie zwraca. Usuń sekrety z żądania guardrailem Secrets Blocker; sanityzuj argumenty, które agent emituje, regułą firewalla. Pokrywają różne połowy przepływu.

​
8. Zweryfikuj i obserwuj

Potwierdź, że polityka robi to, czego oczekujesz, zanim jej zaufasz, potem miej oko na strumienie:

Przetestuj wywołanie narzędzia

Przepuść na sucho przykładowe tools/call wobec swojej polityki i zobacz werdykt, dopasowaną regułę i powód — nic nie dyspozytowane, nic logowane.

Discovered tools

Każde narzędzie, które przestrzeń robocza widziała, oznaczone covered lub gap — pisz reguły prosto z prawdziwego ruchu MCP.

Events & Runs

Każda dyspozycja, jej werdykt i powierzchnia, którą trafiła, zwinięte per uruchomienie agenta.

Strumień anomalii

Skoki tempa/kosztu, pętle ponawiania i nowe ścieżki narzędzi wobec wyuczonej bazowej linii.

​
9. Gdzie iść dalej

Zatruwanie narzędzi MCP

Model zagrożeń stojący za kwarantanną i bramą MCP.

Nadmierna sprawczość

Dlaczego domyślna odmowa i HITL mają znaczenie dla autonomicznego użycia narzędzi.

Przepis na agenta autonomicznego

Utwardź agenta o wysokiej autonomii od początku do końca.

Zatrzymaj eksfiltrację

Zablokuj egress wychodzący w głąb.