Przejdź do głównej treści
Polityka firewalla decyduje jedną rzecz o każdym wywołaniu narzędzia, które robi twój agent: werdykt. Albo reguła dopasowuje i produkuje werdykt, albo żadna reguła nie pasuje i przejmuje werdykt domyślny polityki. Ta strona omawia oba — co każdy werdykt firewalla robi, jak rozwiązuje się cap_cost oraz dlaczego audit to wartość domyślna, od której zaczynasz. Gdzie werdykty żyją w gramatyce reguł, zobacz Reguły Firewall; dla wyboru werdyktu domyślnego przy tworzeniu polityki zobacz Utwórz i przypnij.

​
1. Sześć werdyktów reguł

Reguła produkuje dokładnie jeden z sześciu werdyktów. Pisz je w edytorze reguł konsoli; silnik przechodzi reguły w kolejności priorytetów i wygrywa pierwsze dopasowanie.
Wywołanie przebiega nietknięte. Wciąż ląduje w strumieniu zdarzeń jako allow, więc zachowujesz ślad audytu bez blokowania czegokolwiek. Użyj go jako wyraźnego pozwolenia w polityce default-deny.
Identyczny wynik dla ruchu co allow, ale wywołanie jest oznaczone jako coś, co chciałeś obserwować. To także wartość, na której ląduje werdykt domyślny od razu po wyjęciu z pudełka — obserwuj wszystko, nie blokuj nic, dopóki nie jesteś gotów egzekwować.
Wywołanie nigdy nie dociera do narzędzia. Na powierzchni inbound relay zwraca HTTP 400 z kodem błędu firewall_blocked, nazywając narzędzie i powód; na powierzchni mcp wraca jako błąd narzędzia, więc model może zareagować. Zobacz jak wygląda block.
Redaguje dopasowane podłańcuchy z argumentów wywołania narzędzia (sekret lub PII, który agent umieścił w polu command lub body) i przesyła oczyszczone wywołanie. Redaguje wyłącznie argumenty — nigdy treść, którą narzędzie zwraca. Na powierzchni inbound nie ma jeszcze argumentów czasu wywołania, więc sanitize eskaluje do deny. Zobacz sanityzację odpowiedzi.
Zamienia wywołanie w przegląd poza pasmem. Relay zwraca HTTP 400 z kodem firewall_approval_pending i id zatwierdzenia; wywołanie nie dociera do narzędzia. Recenzent rozstrzyga je w konsoli lub przez webhook callback, a agent ponownie wysyła z jednorazowym nagłówkiem zatwierdzenia. Zobacz zatwierdzenia.
Bezpiecznik kosztowy — pisany jako reguła, ale rozwiązywany do allow lub deny w czasie ewaluacji. Zobacz §3 i limit kosztu.
Tryb cienia spłaszcza egzekwowanie. W trybie cienia każdy egzekwujący werdykt (deny, sanitize, pending_approval oraz cap_cost, który rozwiązał się do deny) jest degradowany do audit, a powód jest poprzedzony przedrostkiem [shadow] would …. Wytocz egzekwującą politykę w ten sposób i obserwuj strumień zdarzeń, zanim przełączysz ją na żywo.

​
2. Werdykt domyślny

Werdykt domyślny (default_verdict na polityce) to to, co polityka robi, gdy żadna reguła nie pasuje do wywołania narzędzia. To podłoga twojej postawy i w przeciwieństwie do werdyktu reguły przyjmuje tylko trzy wartości:
default_verdictGdy żadna reguła nie pasuje…
audit (domyślny)Zezwól na wywołanie, ale je zarejestruj. Bezpieczne miejsce na start.
allowZezwól i zaloguj, bez rekordu przeglądu.
denyZablokuj wszystko, czego reguła wyraźnie nie zezwala — postawa default-deny.
Nowa polityka domyślnie ustawia audit: obserwuje każde wywołanie narzędzia i niczego nie blokuje, dopóki nie dodasz egzekwujących reguł. Trzy werdykty tylko-dla-reguł — sanitize, pending_approval i cap_cost — nie mogą być domyślne; werdykt domyślny to całościowy fallback, a te werdykty mają sens tylko ograniczone do konkretnego dopasowania.
deny jako werdykt domyślny to default-deny: każde wywołanie narzędzia, którego twoje reguły wyraźnie nie allow, jest blokowane. Potężne dla zamkniętego agenta, ale zatrzyma wywołania, których zapomniałeś dodać do listy dozwolonych. Połącz to z wyraźnymi regułami allow (lista dozwolonych narzędzi) i wytocz to najpierw w trybie cienia.

​
3. cap_cost rozwiązuje się do allow lub deny

cap_cost to jedyny werdykt, który nie jest tym, co pojawia się w twoich zdarzeniach. Piszesz regułę z limitem cap_cost_cents, ale w czasie ewaluacji silnik rozwiązuje go do konkretnego allow lub deny, zanim zdarzenie zostanie zarejestrowane — więc strumień zdarzeń nigdy nie niesie dosłownego werdyktu cap_cost, tylko allow/deny, które agent faktycznie zobaczył. Limit jest per uruchomienie agenta: silnik porównuje zakumulowane wydatki uruchomienia z twoim limitem.
  • Poniżej limitu → rozwiązuje się do allow. (Wewnętrznie traktowane to jest jako niedopasowanie, więc ewaluacja kontynuuje do następnej reguły, zamiast pozwolić cap_cost wygrać pierwsze dopasowanie jako przyznanie.)
  • Powyżej limitu → rozwiązuje się do deny, z powodem nazywającym sumę uruchomienia względem limitu. To terminalny wynik bezpiecznika.
// A rule that caps a run at $5.00 of accumulated spend.
{
  "label": "run cost ceiling",
  "tool_name_glob": "*",
  "verdict": "cap_cost",
  "cap_cost_cents": 500
}
cap_cost odpala tylko na powierzchniach przed-dyspozycją (inbound, mcp) — punktach, gdzie zablokowanie wywołania wciąż zapobiega wydatkowi. Na powierzchniach po-dyspozycji response i egress jest bezwładny (nie ma już czego zatrzymać), więc silnik je tam pomija.

​
4. Jak wybierany jest werdykt

Dla dowolnego wywołania narzędzia rozwiązywanie jest takie samo niezależnie od tego, który werdykt wygrywa:
Brama wybiera politykę przypiętą do wywołującego klucza (firewall_policy_id) lub domyślną przestrzeni roboczej — zobacz rozwiązywanie.
Reguły działają w kolejności priority ASC. Pierwsza reguła, której powierzchnia, glob narzędzia, opcjonalne klauzule argumentów i opcjonalny zakres egress wszystkie pasują, produkuje werdykt.
Jeśli żadna reguła nie pasuje, stosuje się default_verdict polityki — audit, chyba że go zmieniłeś.
Jeśli wywołanie jest własnością zarządzanego skilla, skill w trybie block wymusza deny, a skill w trybie quarantine eskaluje wszystko poniżej deny do pending_approval.

​
5. Zachowanie kosztu i ponawiania przy deny

Werdykt firewalla na powierzchni inbound odpala przed wywołaniem modelu nadrzędnego, więc deny tam nie kosztuje tokenów modelu. Błąd jest oznaczony skip-retry — ponowne uruchomienie tego samego zablokowanego wywołania po prostu znów by zablokowało, więc brama mówi klientowi, by go nie ponawiał. To różni się od bloku guardrail, który prześwietla tekst promptu/odpowiedzi (PII, sekrety) zamiast akcji narzędzi i zwraca własny błąd guardrail_blocked. Żądanie może przejść przez obie płaszczyzny.
Każdy werdykt pozostawia ślad. Każda ewaluacja — allow, audit, deny, rozwiązany cap_cost, wstrzymane zatwierdzenie — jest rejestrowana jako zdarzenie firewalla, filtrowalne po werdykcie, powierzchni, narzędziu i uruchomieniu. Strumień zdarzeń to sposób, w jaki potwierdzasz, że polityka produkuje werdykty, których oczekujesz. Zobacz log zdarzeń i analitykę.

​
Dokąd dalej

Utwórz i przypnij politykę

Wybierz werdykt domyślny i powiąż politykę z kluczem.

Limit kosztu

Napisz limit wydatków i jak rozwiązuje się per uruchomienie.

Tryb cienia

Degraduj każdy egzekwujący werdykt do audit, gdy mierzysz wpływ.

Referencja reguł

Pełny język dopasowania stojący za werdyktem.
Dla zagrożeń, które te werdykty mają zatrzymać, zobacz niebezpieczne wywołania narzędzi i nadmierną sprawczość.