Przejdź do głównej treści
Gdy agent wywołuje http_fetch, web_search lub dowolne narzędzie, które otwiera połączenie wychodzące, cel to część, którą najbardziej musisz zarządzać. Zdezorientowany lub porwany agent, który może sięgnąć do 169.254.169.254, odczytuje twoje poświadczenia chmury; taki, który może zrobić POST do hosta atakującego, eksfiltruje twoje dane. Kontrola egress agenta zarządza tym celem — piszesz regułę allow/deny host/CIDR na powierzchni egress firewalla, przypinasz ją do klucza, a brama sprawdza każdy wychodzący cel, który narzędzie agenta zgłasza, zanim wywołanie wyjdzie. To skupiona strona przypadku użycia. Dla pełnej gramatyki reguł i semantyki werdyktów zobacz Schemat reguły i Werdykty; jak egress siedzi wśród innych punktów egzekwowania, zobacz Etapy.

​
1. Kontrola egress agenta na powierzchni egress

Z czterech powierzchni firewalla egress to ta, która widzi wychodzący cel sieciowy, który narzędzie zgłasza — host, literał IP lub CIDR. Reguła przypięta do stage: egress dopasowuje na tym celu, nie na nazwie narzędzia ani jego argumentach, co czyni ją kontrolą SSRF i eksfiltracji danych: odpowiada, gdzie ten agent może sięgnąć, niezależnie od tego, które narzędzie sięgało.
Egress to ograniczanie celu, nie blokowanie narzędzia. Aby powstrzymać narzędzie przed istnieniem w ogóle, odmów go po nazwie na powierzchni inbound (Blokuj narzędzia). Kontrola egress zakłada, że narzędzie może legalnie pobierać — po prostu ogranicza dokąd.

​
2. Jeden przykład: odmów celów SSRF

Kanoniczna reguła egress odmawia endpointu metadanych chmury i prywatnych zakresów RFC-1918 — celów, do których narzędzie w kształcie fetch nigdy nie powinno sięgnąć. W konsoli przestrzeni roboczej otwórz politykę i dodaj regułę z stage egress, werdyktem deny i listą egress: 
{
  "label": "deny SSRF destinations",
  "stage": "egress",
  "verdict": "deny",
  "egress_json": "{\"deny\":[\"169.254.169.254\",\"10.0.0.0/8\",\"172.16.0.0/12\",\"192.168.0.0/16\"],\"allow\":[\"api.openai.com\"]}"
}
egress_json to string zakodowany w JSON niosący listy host/CIDR — zdekodowany to {"deny": [...], "allow": [...]}. Każdy wpis dopasowuje jako CIDR, literał IP lub nazwa hosta bez rozróżniania wielkości liter. Dla werdyktu deny lista deny to zestaw w zakresie (cele, które reguła blokuje), a lista allow wykrawa z niego wyjątki — więc reguła powyżej blokuje cztery zakresy, ale przepuszcza api.openai.com, nawet gdyby kiedykolwiek rozwiązał się w jeden z nich. Gdy cel to nazwa hosta, a nie literał IP, a twoja lista niesie wpisy IP/CIDR, nazwa jest rozwiązywana z najlepszą starannością, a jej adresy ponownie sprawdzane, więc metadata.internal wciąż dopasowuje deny 169.254.0.0/16, mimo że nie jest wymieniony po nazwie.
Dla postawy listy dozwolonych zamiast tego — pozwól tylko na nazwany zestaw celów i zablokuj resztę — napisz regułę z werdyktem allow i umieść swoje cele w liście allow. Polaryzacja się odwraca: allow staje się zestawem w zakresie, a deny wykrawa wyjątki. Połącz to z default_verdict polityki deny, aby wszystko, czego reguła allow nie pokrywa, było zablokowane.

​
3. Sam piszesz reguły CIDR — żaden preset ich nie dostarcza

Nie ma presetowej listy CIDR. OrcaRouter nie dostarcza wbudowanej reguły, która odmawia 169.254.169.254, RFC-1918 ani żadnego innego zakresu. Reguła allow/deny CIDR należy do ciebie — to przykład w §2, napisany przez ciebie wobec twojej własnej sieci. Skopiuj go, potem dostosuj zakresy i wyjątki listy dozwolonych do swojego środowiska.
To, co poziom autonomii tight i jego preset block_ssrf_egress dostarczają, to zestaw odmów na nazwach narzędzi w kształcie fetch — http_fetch, web_search, fetch_url, request, plus ich warianty MCP <server>.<tool>. To tępa postawa: odmawia narzędzi w kształcie egress wprost, zamiast ograniczać, dokąd mogą sięgnąć. Sięgnij po nią, gdy agent nie ma żadnego interesu w robieniu wywołań sieciowych w ogóle; sięgnij po regułę celu (§2), gdy pobiera, ale tylko z zatwierdzonego zestawu hostów.
PodejścieCo ograniczaAutor
Preset SSRF tightNazwy narzędzi w kształcie fetch (odmawia ich)Wbudowany
Reguła egress CIDR/hostCel, do którego fetch może sięgnąćTy

​
4. Jak wygląda zablokowany egress

Gdy cel dopasowuje egzekwującą regułę egress, wywołanie jest odmawiane, zanim opuści bramę, a ewaluacja jest rejestrowana jako zdarzenie firewalla z powierzchnią egress i werdyktem deny. W trybie cienia deny jest degradowane do audit z powodem poprzedzonym przedrostkiem [shadow] would …, więc możesz zmierzyć dokładnie, które cele reguła zablokowałaby wobec prawdziwego ruchu, zanim ją wyegzekwujesz.
Zniekształcona lub bez-wpisowa lista egress jest traktowana zachowawczo: egzekwująca reguła deny wciąż bramkuje (literówka nie może po cichu zatrzymać jej blokowania), ale reguła allow ze zepsutą listą nie odpali — inaczej źle wpisana lista dozwolonych stałaby się allow-all i przesłoniła domyślne deny. Nowe reguły są walidowane przy zapisie (lista musi deklarować co najmniej jeden wpis allow lub deny), więc to chroni tylko stare wiersze.

​
5. Pisz z prawdziwego ruchu, potem wytocz

Log zdarzeń rejestruje host celu w każdym zdarzeniu powierzchni egress (egress_host/egress_url), więc filtruj go do powierzchni egress i napisz swoją listę deny z celów, które faktycznie się pojawiły, zamiast zgadywać. Zakładka Discovered Tools to zwinięcie per nazwa narzędzia (nazwy narzędzi i powierzchnie, na których odpaliły) — mówi ci, które narzędzia w kształcie fetch działały, nie hosty, do których sięgnęły. Zobacz Analitykę.
Zakładka Test w konsoli robi dry-run polityki wobec przykładowego tool_name + powierzchni (+ opcjonalne argumenty) i zwraca werdykt, dopasowaną regułę i powód — nic nie jest dyspozytowane. Potwierdza, która reguła rozwiązuje wywołanie; aby potwierdzić swoją matematykę CIDR/host wobec prawdziwych celów, użyj trybu cienia poniżej (ładunek Test nie niesie celu, więc dopasowanie listy egress jest ćwiczone na ruchu egress na żywo). Zobacz Testowanie reguł.
Włącz tryb cienia, a deny egress jest logowane tak, jak by odpaliło, bez blokowania. Obserwuj log zdarzeń filtrowany do powierzchni egress, potwierdź, że wychwytuje cele, których oczekujesz, potem wyłącz cień.
Ograniczanie celu w bramie to obrona w głąb, nie ostatnia linia. IP, na które nazwa hosta rozwiązuje się w czasie ewaluacji, może różnić się od tego, na które narzędzie faktycznie dzwoni (DNS rebinding). Utrzymuj kontrolę IP-deny też na swojej własnej warstwie egress/dialer; reguła bramy to tani wstępny przechwyt dla oczywistych przypadków.

​
6. Przypnij politykę i kto może ją edytować

Polityka niczego nie robi, dopóki klucz się do niej nie rozwiąże. Przypnij w konsoli, ustawiając firewall_policy_id na kluczu, lub uczyń politykę domyślną dla przestrzeni roboczej. Rozwiązywanie to: przypięta polityka klucza (gdy istnieje i jest włączona), inaczej domyślna przestrzeni roboczej. Cała konfiguracja reguł egress działa w konsoli pod twoją sesją (/api/workspace/firewall/*):
AkcjaRola
Odczyt polityk, presetów, wykrytych narzędzi, Simulate autonomiiMember
Tworzenie / edycja / usuwanie reguł egress i politykDeveloper+
Endpoint Test dry-run (POST /test)Developer+
Odczyt logu zdarzeń i agregatów uruchomieńDeveloper+

​
Powiązane

Eksfiltracja danych

Zagrożenie, któremu zaradza kontrola egress.

Etapy

Cztery powierzchnie i gdzie siedzi egress.

Werdykty

Co deny, audit i allow robią na drucie.

Blokuj narzędzia

Odmów narzędzia fetch po nazwie zamiast po celu.

Niebezpieczne wywołania narzędzi

Szersza klasa ryzyka.

Referencja firewalla

Pełna referencja reguł + dopasowania, w tym listy egress.