Przejdź do głównej treści
Serwer MCP, który podłączasz, dostarcza narzędzia sięgające do sieci — fetch, web_search, poster webhooka. Nazwa narzędzia może być na twojej liście dozwolonych, argumenty mogą wyglądać czysto, a wywołanie wciąż kończy POST-owaniem twoich danych na host kontrolowany przez atakującego lub wyciąganiem poświadczeń z endpointu metadanych 169.254.169.254. Cel to ta część wywołania, której twoje reguły nazwy narzędzia nigdy nie widzą. Kontrola egress mcp zamyka tę lukę. Reguła egress zawęża werdykt firewalla do tego, dokąd narzędzie sięga — host, IP lub zakres CIDR — tak by ten sam http_fetch, który jest dozwolony do api.openai.com, był odmawiany do wszystkiego innego. Działa na powierzchni egress firewalla, na wierzchu ewaluacji per wywołanie, przez którą każde tools/call już przechodzi.
To zadanie konsoli. Reguły firewalla mieszkają na trasach /api/workspace/firewall/*, które uwierzytelniają się twoim tokenem sesji / dostępu — nie kluczem relay sk-orca-…. Autorowanie reguły wymaga roli Developer+.

​
1. Co kontroluje reguła egress

Normalna reguła dopasowuje na nazwie narzędzia i jego argumentach. Reguła egress dodaje trzeci wymiar: cel, do którego wywołanie się rozwiązuje. Ustawiasz stage reguły na egress i dołączasz listę egress_json wpisów allow / deny. Silnik wyciąga host docelowy z wywołania i odpala regułę tylko wtedy, gdy ten host jest w zakresie. Wpisy są dopasowywane na trzy sposoby:

Nazwa hosta

Dokładne dopasowanie bez rozróżniania wielkości liter, np. api.openai.com. Wiodąca kropka jest przycinana po obu stronach.

Literał IP

Dokładne dopasowanie wobec rozwiązanego IP wybierania, np. 169.254.169.254.

Zakres CIDR

Docelowe IP — literał lub rozwiązane przez DNS — musi wpaść w blok, np. 10.0.0.0/8.
Gdy cel jest nazwą hosta, ale twoja lista niesie wpisy IP/CIDR, nazwa jest rozwiązywana, a jej IP są ponownie sprawdzane — więc metadata.internal dopasowuje deny 169.254.0.0/16, mimo że nie jest wymienione po nazwie. To defensa-w-głąb na zasadzie best-effort przeciwko nazwie, która rozwiązuje się w odmówiony zakres; autorytatywny strażnik SSRF wciąż działa na warstwie wybierania bramy.

​
2. Jeden konkretny przykład

Odmów każdemu narzędziu o kształcie fetch dosięgania endpointu metadanych chmury i zakresów RFC-1918. To kanoniczne cięcie nogi eksfiltracji SSRF: werdykt deny na etapie egress, zawężony przez denylistę egress_json. 
curl https://api.orcarouter.ai/api/workspace/firewall/rules \
  -H "Authorization: Bearer <your-session-or-access-token>" \
  -H "Content-Type: application/json" \
  -d '{
    "policy_id": 12,
    "priority": 10,
    "label": "Deny SSRF / metadata egress",
    "stage": "egress",
    "tool_name_glob": "*",
    "verdict": "deny",
    "egress_json": "{\"deny\":[\"169.254.169.254\",\"10.0.0.0/8\",\"172.16.0.0/12\",\"192.168.0.0/16\"]}"
  }'
tools/call, którego cel rozwiązuje się w którykolwiek z tych zakresów, wraca do modelu jako błąd narzędzia; wywołanie do publicznego hosta, którego denylista nie pokrywa, przechodzi.
Listy allow/deny odwracają znaczenie wraz z werdyktem. Na regule deny (lub innej egzekwującej) lista deny to zbiór w zakresie, a allow wycina wyjątki — „odmów tym, oprócz tamtych”. Na regule allow role się odwracają: lista allow to zbiór w zakresie, a deny wycina wyjątki — „dopuść tylko te”. Niepuste egress_json musi zadeklarować co najmniej jeden wpis allow lub deny, albo zapis jest odrzucany.

​
3. Lista dozwolonych tylko jednego celu

Odwrotność powyższego przykładu: przypnij narzędzie fetch do jednego usankcjonowanego hosta i pozwól default_verdict polityki (lub późniejszej regule catch-all) obsłużyć resztę. Ponieważ to werdykt allow, lista allow to zbiór w zakresie. 
// egress_json na regule allow-verdict, stage=egress
{ "allow": ["api.openai.com", "api.anthropic.com"] }
Reguła teraz odpala (dopuszcza) tylko wtedy, gdy cel jest jednym z tych dwóch hostów. Cokolwiek innego spada do następnej reguły — sparuj to z polityką domyślnej odmowy, tak by niewymieniony cel był odmawiany, a nie przepuszczany.
Przetestuj to, zanim mu zaufasz. Zakładka Test konsoli i endpoint POST /api/workspace/firewall/test (Developer+) odtwarzają przykładowe wywołanie wobec twojej roboczej polityki, więc możesz potwierdzić werdykt na znanym celu bez wysyłania żywego ruchu.

​
4. Jak komponuje się z resztą firewalla

Reguła egress to jedna reguła pośród wielu w polityce firewalla przestrzeni roboczej. Silnik przechodzi reguły w kolejności priorytetu (najniższy najpierw) i wygrywa pierwsze dopasowanie, więc umieść ścisły deny egress nad dowolnym szerokim allow.
Werdykt na regule egressEfekt
denyBlokuje wywołanie do celów w zakresie — zarejestrowane na powierzchni egress i zwrócone do narzędzia jako błąd.
auditLoguje dopasowane wywołanie jako zdarzenie firewalla; wciąż dyspozytuje.
allowZezwala na cele w zakresie; paruje się z podłogą domyślnej odmowy.
pending_approval i cap_cost nie są egzekwowane na powierzchni egress — egress to sprawdzenie celu, nie wstrzymanie ani limit wydatku. Użyj tych werdyktów na powierzchniach mcp lub inbound zamiast tego. Zobacz referencję werdyktów.
Dwie powiązane kontrole warto okablować obok reguły egress:
Niezależnie od dowolnej reguły, którą autorujesz, brama MCP waliduje każdy endpoint serwera i jego rozwiązane IP wybierania wobec polityki SSRF — zakresy intranetowe i adres metadanych chmury są odmawiane, a IP jest ponownie sprawdzane na każdym przeskoku, by pokonać DNS rebinding. Twoja reguła egress nakłada politykę celu specyficzną dla przestrzeni roboczej na wierzchu tej bazy.
Pojedynczy deny egress zatrzymuje narzędzie dosięgające hosta. Reguła sekwencji zatrzymuje łańcuch — np. „odczytaj plik, potem egress w oknie” — flagując nogę egress tylko wtedy, gdy następuje po wrażliwym odczycie. To przerywacz śmiertelnej trójcy; zawężanie egress to kontrola per wywołanie.

​
5. Najpierw shadow, potem egzekwuj

Wytoczenie deny egress prosto do egzekwowania w ruchliwej przestrzeni roboczej ryzykuje zepsuciem legalnej integracji, o której zapomniałeś. Dwie siatki bezpieczeństwa:
  • Tryb shadow. Polityka w trybie shadow obniża każdy egzekwujący werdykt do audit — twój deny egress loguje [shadow] would deny … zamiast blokować, więc widzisz promień rażenia, zanim ugryzie.
  • Tryb observe. Ustawienie przestrzeni roboczej firewall_observe_mode loguje nieprzykryte wywołania jako Odkryte narzędzia, wystawiając prawdziwe cele, które twoje agenty już dosięgają, tak byś mógł napisać dokładną listę dozwolonych z danych zamiast zgadywania.
Dopasowywanie celu egress kluczuje na hoście, do którego wywołanie rozwiązuje się w czasie ewaluacji. Wrogi serwer wciąż może przepiąć DNS między sprawdzeniem polityki a faktycznym wybieraniem (TOCTOU) — i właśnie dlatego strażnik IP na warstwie gniazda bramy jest autorytatywną kontrolą, a ta reguła jest defensą-w-głąb, nie jedyną linią.

​
6. Role i trasy

Wszystkie trasy konsoli mają zakres przestrzeni roboczej i uwierzytelniają się twoim tokenem sesji / dostępu. Odczyty są otwarte dla każdego Membera; autorowanie lub edytowanie reguły wymaga Developer+.
Metoda i ścieżkaRolaCel
GET /api/workspace/firewall/policies/:idMemberOdczytaj politykę i jej reguły.
POST /api/workspace/firewall/rulesDeveloper+Dodaj regułę (ustaw stage: egress).
PUT /api/workspace/firewall/rulesDeveloper+Zaktualizuj regułę (id w ciele).
DELETE /api/workspace/firewall/rules/:idDeveloper+Usuń regułę.
POST /api/workspace/firewall/testDeveloper+Odtwórz przykładowe wywołanie wobec roboczej polityki.

​
Powiązane

Referencja reguł firewalla

Pełny DSL reguł — globy narzędzi, dopasowywanie args, listy egress, sekwencje.

Połącz serwer MCP

Zarejestruj serwer, tak by jego wywołania narzędzi przebiegały za firewallem.

Lista dozwolonych narzędzi MCP

Domyślnie odmawiaj narzędziom, których wyraźnie nie zatwierdziłeś.

Eksfiltracja danych

Zagrożenie, do zatrzymania którego zbudowana jest kontrola egress.