Przejdź do głównej treści
Agent AI nie tylko generuje tekst — on działa. Wywołuje shell.exec, odpytuje bazę danych, pobiera URL, dyspozytuje narzędzie przez serwer MCP. Każda z tych rzeczy to akcja o rzeczywistych konsekwencjach, której guardrails na poziomie promptu nie widzą. Firewall agentowy to płaszczyzna warstwy akcji, która nimi zarządza: nazwana polityka w zakresie przestrzeni roboczej, którą brama ewaluuje przy każdym wywołaniu narzędzia, zanim dotrze ono do narzędzia. Ta strona to hub sekcji Firewall — model polityki, werdykty, powierzchnie oraz to, jak polityka przypina się do klucza. Każda szprycha sięga głębiej, a pełna referencja silnika żyje w Firewall i Reguły Firewall.

​
1. Co robi firewall agentowy

Zapisujesz politykę raz w konsoli przestrzeni roboczej, przypinasz do niej klucz API (lub ustawiasz jeden jako domyślny dla przestrzeni roboczej), a od tej chwili każde wywołanie narzędzia, które ten klucz wystawia, jest sprawdzane wobec polityki w bramie. Bez ponownego wdrożenia, bez zmian w kodzie agenta — twój agent dalej wystawia wywołania narzędzi dokładnie jak wcześniej, a edycja polityki wchodzi w życie przy następnym wywołaniu dla każdego powiązanego z nią klucza. Polityka to uporządkowana lista reguł. Każda reguła decyduje, których wywołań narzędzi dotyczy oraz co z nimi zrobić. Silnik przechodzi reguły w kolejności priorytetów, wygrywa pierwsze dopasowanie, a jeśli nic nie pasuje, wraca do domyślnego werdyktu polityki.
Wykrywanie odbywa się w bramie, przy pierwszym użyciu — nie w momencie instalacji. Narzędzie, serwer MCP lub skill, który agent samodzielnie instaluje, jest wychwytywany przy pierwszym przekroczeniu bramy przez jego wywołanie. To jeden punkt zwężenia, który widzi każdego dostawcę, każdego agenta i każde wywołanie narzędzia niezależnie od tego, skąd zdolność się wzięła.

​
2. Konkretny przykład

Załóżmy, że chcesz blokować destrukcyjne polecenia shella, ale przepuszczać wszystko inne pod audytem. W konsoli tworzysz politykę z default_verdict = audit i jedną regułą: 
{
  "label": "block rm -rf",
  "tool_name_glob": "*.exec",
  "args_match_json": "{\"clauses\":[{\"path\":\"$.command\",\"op\":\"regex\",\"value\":\"rm -rf|drop table\"}]}",
  "verdict": "deny"
}
args_match_json to string zakodowany w JSON (brama waliduje go wobec schematu klauzul przy zapisie): path to JSONPath do argumentów wywołania, op to jeden z eq, contains, regex, in, cidr_match, gt, lt. Przypnij klucz do polityki (ustaw firewall_policy_id na kluczu). Teraz, gdy agent emituje shell.exec z command: "rm -rf /", brama zwraca HTTP 400 z kodem błędu firewall_blocked i powodem nazywającym narzędzie — a wywołanie nigdy nie dociera do shella. Każde inne wywołanie narzędzia jest dozwolone i rejestrowane do przeglądu.
Wytocz nową politykę najpierw w trybie cienia: ewaluuje i loguje dokładnie tak, jak robiłaby to na produkcji, ale każdy egzekwujący werdykt jest degradowany do audit, a powód jest poprzedzony przedrostkiem [shadow] would …. Obserwuj strumień zdarzeń, a potem wyłącz tryb cienia, aby egzekwować.

​
3. Polityka, reguły i rozwiązywanie

Polityka ma zakres przestrzeni roboczej i jest nazwana, z enabled, is_default, default_verdict (allow / audit / deny, domyślnie audit) oraz flagą shadow_mode. Reguła to jedno sprawdzenie wewnątrz niej — zobacz Utwórz politykę i Schemat reguły. Dla dowolnego wywołania narzędzia brama rozwiązuje aktywną politykę w kolejności:
  1. Powiązanie klucza — firewall_policy_id wywołującego klucza, gdy ta polityka istnieje i jest włączona.
  2. Domyślny przestrzeni roboczej — w przeciwnym razie włączona polityka is_default.
Wyłączona przypięta polityka firewalla wraca do domyślnej polityki przestrzeni roboczej — to różni się od guardrails, gdzie wyłączone powiązanie rozwiązuje się do braku. Wyłącznik firewalla na kluczu oznacza „użyj domyślnej”, a nie „brak egzekwowania”. Zobacz Zarządzanie politykami.
Gdy żadna polityka nie rozwiąże się w ogóle, zachowanie zależy od ustawienia firewall_observe_mode przestrzeni roboczej: przy włączonym trybie obserwacji wywołanie jest dozwolone, ale logowane jako luka w pokryciu (pojawia się w Discovered Tools); przy wyłączonym wywołanie jest po cichu dozwolone.

​
4. Werdykty

Reguła — lub wartość domyślna — produkuje jeden z:
WerdyktCo robi
allowPrzepuść, zalogowane.
auditPrzepuść + zarejestruj do przeglądu. Zwykła wartość domyślna.
denyZablokuj. HTTP 400 firewall_blocked na inbound; błąd narzędzia na MCP.
sanitizeZredaguj dopasowane podłańcuchy z argumentów narzędzia i prześlij dalej.
pending_approvalWstrzymaj dla człowieka; HTTP 400 firewall_approval_pending.
cap_costOdrzuć, gdy wydatki uruchomienia przekroczą limit per reguła.
Werdykt sanitize redaguje wyłącznie argumenty wywołania — nigdy treść, którą narzędzie zwraca. Na powierzchni inbound, gdzie nie ma jeszcze argumentów czasu wywołania, sanitize eskaluje do bloku. Zobacz Werdykty i Sanityzacja odpowiedzi.

​
5. Cztery powierzchnie egzekwowania

Każde wywołanie narzędzia jest ewaluowane wobec dokładnie jednej powierzchni — przypnij regułę do jednej polem stage lub zostaw je puste, aby dotyczyła wszystkich.

inbound

Narzędzia, które agent ogłasza modelowi w żądaniu. Zablokuj niebezpieczne narzędzie, zanim model w ogóle będzie mógł je wybrać.

response

tool_calls, które model emituje w swojej odpowiedzi.

mcp

tools/call dyspozytowane przez bramę MCP. Zobacz Serwery MCP.

egress

Wychodzący host / IP / CIDR, do którego sięga narzędzie — powierzchnia SSRF i eksfiltracji danych.

​
6. Dopasowanie

Reguły wyrażają, które wywołania narzędzi wychwytują, małym, deterministycznym słownikiem, który jest bezpieczny na gorącej ścieżce:
Glob z rozróżnianiem wielkości liter na nazwie narzędzia (shell.*, *.delete), opcjonalnie połączony AND z globem na skillu właścicielu. Zobacz Składnia globów i Lista dozwolonych narzędzi.
Predykaty JSONPath nad argumentami wywołania z operatorami eq, contains, regex, in, cidr_match, gt, lt — różnica między „zablokuj shell.exec” a „zablokuj go tylko wtedy, gdy polecenie to rm -rf”. Klauzule fail closed (reguła, nie żądanie). Zobacz Walidacja argumentów.
Listy dozwolonych i odmów host / IP / CIDR na powierzchni egress. Możesz napisać własną regułę odmowy dla metadanych chmury lub zakresów RFC-1918. Zobacz Kontrola egress.
Reguła sequence dopasowuje uporządkowany łańcuch wywołań w oknie (egzekwowana reaktywnie); reguła cap_cost odmawia, gdy zakumulowane wydatki uruchomienia agenta przekroczą limit w centach. Zobacz Reguły sekwencji i Limit kosztu.

​
7. Zatwierdzenie przez człowieka, autonomia i anomalie

  • Człowiek w pętli. Werdykt pending_approval wstrzymuje wywołanie i zwraca jego id zatwierdzenia. Recenzent rozstrzyga je w konsoli (Developer+) lub przez podpisany HMAC webhook callback; agent odpytuje i ponownie wysyła z jednorazowym nagłówkiem X-OrcaRouter-Firewall-Approval. Zobacz Zatwierdzenia i Webhook zatwierdzeń.
  • Poziomy autonomii. Jeden przełącznik ustawia całą twoją postawę: tight (default-deny + odmowa destrukcyjnego shella + odmowa narzędzi w kształcie fetch (http_fetch/web_search/fetch_url/request, wektor SSRF) + PII Shield + Secrets Blocker egzekwowane), balanced (domyślnie audit, odmowa destrukcyjnego shella, PII Shield tylko audit) lub permissive (tylko obserwacja). Każdy zapisuje rzeczywiste, edytowalne wiersze polityki i guardrail, z cofnięciem jednym kliknięciem z migawki audytu.
  • Wykrywanie anomalii. Poza statycznymi regułami firewall ocenia użycie narzędzi wobec wyuczonej bazowej linii godziny-tygodnia (14-dniowej) i flaguje skoki tempa/kosztu, retry_loop oraz novel_path na strumieniu czytelnym dla Membera, który możesz uśpić na do 7 dni.

​
8. Gdzie pasuje firewall

Firewall to równolegli warstwy akcji dwóch sąsiednich płaszczyzn:
PłaszczyznaZarządzaKiedy po nią sięgnąć
GuardrailsTekst promptu i odpowiedziPII, sekrety, jailbreaki, intencja injection
Firewall agentowyAkcje narzędziKtóre narzędzia, wywołania MCP, hosty i koszt
ZgodnośćDowody i frameworkiGotowość SOC 2 / HIPAA / EU AI Act
Zarówno płaszczyzna treści, jak i akcji może dotyczyć pojedynczego żądania, a poziom autonomii konfiguruje je razem. Zobacz Guardrails vs. Firewall i stos kontrolny.

​
9. Przypinanie i łączenie

Polityka wiąże się z kluczem przez firewall_policy_id (konfigurowane w konsoli; powiązanie żyje na kluczu w bramie). Dwa sposoby, by wywołanie narzędzia dotarło do silnika, oba wymagające klucza w zakresie firewall-gateway (is_firewall_gateway = true) — zwykły klucz relay dostaje 403 na tych trasach:
  • Brama MCP — skieruj swojego klienta MCP na ujednolicony endpoint ANY /api/v1/firewall/mcp; każde tools/call jest ewaluowane inline. Zobacz Serwery MCP.
  • Hook evaluate — wywołaj POST /api/v1/firewall/evaluate (lub /evaluate_plan dla wielokrokowego planu) z własnej pętli agenta przed dyspozycją i działaj wedle werdyktu.
Cała konfiguracja konsoli działa pod twoją sesją przez /api/workspace/firewall/*. Odczyty polityk, ustawień, wykrytych narzędzi, tylko-do-odczytu symulatora autonomii oraz strumienia anomalii są otwarte dla każdego członka przestrzeni roboczej; piaskownica dry-run Test, log Events / Runs oraz wszystkie zapisy wymagają Developer+. Zobacz Klucze gateway i Testowanie reguł.

​
10. Zagrożenia, którym ta płaszczyzna zaradza

Niebezpieczne wywołania narzędzi

Odmawiaj destrukcyjnego shella, dropów DB i ryzykownych czasowników po globie + argumentach.

Eksfiltracja danych

Listy egress i reguły sekwencji read-then-export.

Zatruwanie narzędzi MCP

Ewaluacja per wywołanie na powierzchni mcp przed dyspozycją.

Nadmierna sprawczość

Zatwierdzenia, limity kosztów i postawa default-deny.

​
Następne kroki

Utwórz politykę

Zapisz swoją pierwszą politykę i regułę.

Werdykty

Co każdy werdykt robi na drucie.

Log zdarzeń

Odczytaj, co firewall zdecydował i dlaczego.