Przejdź do głównej treści
Reguła firewalla odpala w konkretnym punkcie cyklu życia wywołania narzędzia. Ten punkt to jej etap — jedna z czterech powierzchni egzekwowania, każda widząca inny wycinek wywołania. Przypnij regułę do złego etapu, a zobaczy złe dane: lista dozwolonych egress na powierzchni inbound nie ma celu do sprawdzenia; klauzula argumentu na inbound nie ma jeszcze argumentów czasu wywołania. Ta strona to skupiony przewodnik po czterech etapach firewalla agentowego: co każda powierzchnia obserwuje, kiedy reguła powinna ją celować oraz jeden konkretny sposób, w jaki ta sama intencja jest wyrażana na różnych etapach. Dla pełnego słownika reguł zobacz Reguły Firewall; dla modelu polityki wokół niego Firewall.

​
1. Cztery etapy w skrócie

Każda ewaluacja jest oznaczona dokładnie jednym etapem. Reguła bez etapu ("") dotyczy wszystkich z nich; reguła przypięta do jednego etapu odpala tylko tam.
EtapCo widzi powierzchnia
inboundNarzędzia, które agent ogłasza w żądaniu
responsetool_calls, które model emituje w swojej odpowiedzi
mcptools/call dyspozytowane przez bramę MCP
egressWychodzący host / IP / CIDR, do którego sięga narzędzie
Nazwy etapów to stabilne wartości enum — ustawiasz je dosłownie w polu etapu edytora reguł lub jako właściwość stage przy autorowaniu przez API.
Etap zarządza jakie dane są w zakresie, nie jak surowy jest werdykt. deny to deny na dowolnym etapie; zmienia się to, czy reguła ma argumenty, nazwę narzędzia lub cel, których potrzebuje do dopasowania.

​
2. inbound — narzędzia, które agent ogłasza

Najwcześniejsza powierzchnia. Zanim model w ogóle się uruchomi, twój agent wysyła listę definicji narzędzi, które jest gotów pozwolić modelowi wywołać. Etap inbound widzi ten ogłoszony zestaw narzędzi i może zablokować niebezpieczne narzędzie zanim model będzie mógł je w ogóle wybrać. Na tym etapie nie ma argumentów czasu wywołania — model jeszcze nie zdecydował, jak cokolwiek wywołać — więc reguły inbound dopasowują na nazwie narzędzia (i opcjonalnie jego skillu właścicielu), nie na args_match_json.
Werdykt sanitize na inbound nie ma czego redagować (nie istnieją jeszcze argumenty), więc eskaluje do bloku. Pisz reguły inbound jako wyraźne allow / deny, a sanitize zachowaj na etapy wykonania.
Odmówione wywołanie tutaj zwraca HTTP 400 z kodem firewall_blocked, nazwane po narzędziu i powodzie, oraz oznaczone skip-retry.

​
3. response — wywołania narzędzi, które model emituje

Gdy model odpowie, może wyemitować jedno lub więcej tool_calls — konkretne wywołania z rzeczywistymi argumentami. Etap response je widzi, więc tu należą reguły na poziomie argumentów: nie „zablokuj shell.exec”, ale „zablokuj shell.exec tylko wtedy, gdy polecenie to rm -rf”. 
{
  "stage": "response",
  "tool_name_glob": "shell.exec",
  "verdict": "deny",
  "args_match_json": "{\"clauses\":[{\"path\":\"$.command\",\"op\":\"regex\",\"value\":\"rm -rf|mkfs|dd if=\"}]}"
}
Ponieważ wybrane przez model argumenty są obecne, sanitize działa tutaj — redaguje dopasowane podłańcuchy z argumentów wywołania i przesyła oczyszczone wywołanie. (Sanitize redaguje wyłącznie argumenty wywołania narzędzia; nigdy nie dotyka treści, którą narzędzie zwraca.)

​
4. mcp — wywołania dyspozytowane przez bramę

Gdy agent sięga do narzędzia przez bramę MCP OrcaRouter, każde tools/call jest ewaluowane na etapie mcp zanim zostanie dyspozytowane do zarejestrowanego serwera. To powierzchnia, która zarządza ruchem Model Context Protocol — ten sam słownik glob / argument / werdykt co response, zastosowany do dyspozycji MCP. Block tutaj pojawia się jako błąd narzędzia (firewall deny: <reason>) zamiast awarii transportu, więc model widzi odrzucenie i może zareagować — wybrać inne narzędzie, zapytać użytkownika lub zatrzymać się.
Etap mcp łączy się z zarządzaniem per serwer: każdy zarejestrowany serwer MCP ma własną sondę zdrowia i zaszyfrowane poświadczenia, a skille ładowane przez niego niosą pasmo ryzyka i tryb egzekwowania. Zobacz Firewall MCP i Skille Firewall.

​
5. egress — wychodzący cel, do którego sięga narzędzie

Ostatnia powierzchnia. Gdy narzędzie zgłasza wychodzący cel sieciowy, etap egress na nim dopasowuje — powierzchnia SSRF i eksfiltracji danych. Reguły egress nie dopasowują na samym wzorcu nazwy narzędzia; dopasowują na liście host / IP / CIDR: 
{
  "stage": "egress",
  "verdict": "deny",
  "egress_json": "{\"deny\":[\"169.254.169.254\",\"10.0.0.0/8\"],\"allow\":[\"api.openai.com\"]}"
}
Wpisy dopasowują jako CIDR, literał IP lub nazwa hosta bez rozróżniania wielkości liter. Sam piszesz reguły odmowy host i CIDR — endpoint metadanych chmury (169.254.169.254) i zakresy RFC-1918 to kanoniczne rzeczy do odmowy. Zobacz Reguły Firewall §6 dla polaryzacji allow/deny.
Żaden preset nie dostarcza reguł CIDR. Postawa SSRF poziomu autonomii tight (autonomy level) odmawia nazw narzędzi w kształcie fetch (np. http_fetch, web_search, fetch_url); odmowa egress oparta na celu to coś, co piszesz dla hostów i zakresów, do których twoje agenty nigdy nie mogą sięgnąć.

​
6. Wybór właściwego etapu

Ten sam cel bezpieczeństwa często ma najlepszy etap. Dopasuj intencję do powierzchni, która faktycznie niesie dane, których potrzebujesz:
Jeśli model nigdy nie powinien nawet zobaczyć narzędzia, odmów go na inbound. Block ląduje przed wywołaniem modelu, więc nie kosztuje tokenów modelu.
Klauzule argumentów potrzebują wybranych przez model argumentów, które istnieją tylko na response i mcp. Odmawiaj na niebezpiecznym argumencie lub sanitize, aby usunąć sekret lub wartość PII, którą agent umieścił w argumencie.
Wywołania kierowane przez bramę MCP są ewaluowane na mcp przed dyspozycją — punkt zwężenia dla narzędzi każdego zarejestrowanego serwera.
Reguły oparte na celu — zablokuj IP metadanych chmury, odmów CIDR, dodaj do listy dozwolonych zatwierdzone hosty — mają sens tylko na egress.
Reguła bez etapu działa na wszystkich czterech. Użyj jej do reguły w stylu default_verdict na całość lub narzędzia, którego odmawiasz wszędzie, gdzie się pojawia.

​
7. Etapy a tryb cienia

Flaga shadow_mode polityki jest niezależna od etapu. Włącz ją, a każdy egzekwujący werdykt — na dowolnym etapie — jest degradowany do audit, a powód jest poprzedzony przedrostkiem [shadow] would …, więc możesz potwierdzić, że reguła odpala na właściwej powierzchni, zanim zmieni ruch na żywo. Zobacz Tryb cienia i Tryby egzekwowania.

​
8. Gdzie etapy pasują do szerszego obrazu

Cztery etapy to gdzie egzekwowania; reszta modelu to co i kto.

Werdykty

Co każdy etap może zrobić, gdy dopasuje — allow, audit, deny, sanitize, wstrzymaj do zatwierdzenia, ogranicz koszt.

Lista dozwolonych narzędzi

Użyj inbound, aby ograniczyć zestaw narzędzi, który agent ogłasza.

Walidacja argumentów

Pisz klauzule argumentów response / mcp, które bramkują narzędzie po tym, jak jest wywoływane.

Kontrola egress

Blokuj wychodzące cele na powierzchni egress — granica eksfiltracji.
Dla tego, jak te powierzchnie siedzą na ścieżce inspekcji, zobacz Jak OrcaRouter inspekcjonuje i notatki o opóźnieniu ścieżki egzekwowania. Dla zagrożeń, którym każdy etap zaradza, zobacz Niebezpieczne wywołania narzędzi, Eksfiltrację danych i Zatruwanie narzędzi MCP.