Tryby egzekwowania: obserwacja, cień i egzekwowanie

Zanim reguła zablokuje ruch produkcyjny, chcesz wiedzieć, że odpala na właściwych rzeczach i niczym innym. OrcaRouter daje ci trzy postawy — obserwacja, cień i egzekwowanie — które pozwalają wdrażać stopniowo, z widocznością na każdym kroku i bez niespodzianek. Ta strona wyjaśnia, co każda postawa oznacza mechanicznie, jak przez nie przechodzić i jak poziomy autonomii ustawiają to wszystko w jednym kroku.

​

1. Trzy postawy na pierwszy rzut oka

​

2. Postawa obserwacji — mierz, zanim zaczniesz rządzić

Postawa obserwacji to nie jeden przełącznik. To kombinacja trzech niezależnych mechanizmów, które razem produkują „zezwalaj na wszystko, rejestruj wszystko”:

​

Tryb obserwacji firewalla (ustawienie przestrzeni roboczej)

Gdy wywołanie narzędzia rozwiązuje się do żadnej polityki w ogóle — brak dołączenia klucza i brak domyślnego przestrzeni roboczej — workspace-level tryb obserwacji firewalla określa, co się dzieje:

• Tryb obserwacji włączony: wywołanie jest dozwolone i logowane jako luka w pokryciu. Widok Discovered Tools wypełnia się z tych zdarzeń luk, pokazując dokładnie, które narzędzia twoje agenty uruchamiają bez żadnej reguły, która je obejmuje.
• Tryb obserwacji wyłączony: wywołanie jest dozwolone po cichu — bajt-identycznie z przestrzenią roboczą, która nigdy nie włączyła tej funkcji.

Tryb obserwacji jest powierzchnią wykrywania luk. Odpala tylko wtedy, gdy żadna polityka się nie rozwiązuje. Nie jest tym samym co posiadanie polityki ustawionej na audit.

​

Werdykt audit firewalla (domyślny per polityka)

Gdy polityka się rozwiązuje, ale żadna reguła nie pasuje do wywołania narzędzia, obowiązuje default_verdict polityki. Domyślna wartość default_verdict to audit — zezwól na wywołanie i zapisz je do przeglądu. Nowa polityka bez reguł i bez zmian konfiguracji nie blokuje niczego i po cichu nie zezwala na nic: audytuje wszystko, co widzi. audit jest też normalnym werdyktem reguły. Reguła, która pasuje i produkuje audit, przepuszcza wywołanie i rejestruje je — odpowiednik trybu audytu guardrail dla firewalla.

​

Akcja flag guardrail (akcja reguły per reguła)

Po stronie guardrails, akcja flag jest odpowiednikiem obserwacji: reguła odpala, dopasowanie jest rejestrowane w strumieniu Matches, a żądanie kontynuuje bez zmian. Bez blokady. Bez redagowania. Używaj flag, gdy chcesz zmierzyć regułę — zobaczyć, jak często odpala i na czym — zanim zobowiążesz się do block lub mask.

---

Razem te trzy produkują postawę obserwacji: tryb obserwacji wychwytuje nieobsłużone wywołania narzędzi; werdykty audit obejmują wywołania narzędzi pod polityką, ale jeszcze nie pod konkretną regułą; akcje flag obejmują sprawdzenia guardrail, na których egzekwowanie nie jesteś jeszcze gotowy.

​

3. Postawa cienia — waliduj przed egzekwowaniem

Tryb cienia to flaga per polityka (shadow_mode: true) na polityce firewalla. Gdy jest włączony:

• Polityka ewaluuje każde wywołanie narzędzia dokładnie tak jak na produkcji — reguły są dopasowywane, werdykty są obliczane, predykaty argumentów są testowane.
• Każdy egzekwujący werdykt (deny, sanitize, pending_approval) jest degradowany do audit zanim dotrze do narzędzia.
• Zalogowany powód jest poprzedzony przedrostkiem [shadow] would …, abyś mógł zobaczyć w strumieniu zdarzeń dokładnie, co by zostało zablokowane, zredagowane lub wstrzymane.

Tryb cienia to twój przełącznik bezpiecznego wdrożenia. Napisz politykę, włącz shadow, skieruj na nią rzeczywisty ruch, obserwuj widoki zdarzeń i uruchomień przez kilka godzin lub dni, potwierdź, że polityka odpala na właściwych narzędziach i niczym nieoczekiwanym, a potem wyłącz tryb cienia, aby zacząć egzekwować.

​

4. Postawa egzekwowania — rzeczywiste werdykty, rzeczywiste konsekwencje

W postawie egzekwowania nic nie jest degradowane:

• Firewall deny → agent widzi błąd narzędzia (MCP) lub HTTP 400 firewall_blocked (powierzchnia inbound). Błąd nazywa narzędzie i powód. Oznaczony skip-retry.
• Firewall sanitize → dopasowane podłańcuchy są redagowane z argumentów narzędzia i oczyszczone wywołanie jest przekazywane dalej.
• Firewall pending_approval → wywołanie jest wstrzymane; agent otrzymuje HTTP 400 firewall_approval_pending i id zatwierdzenia do odpytywania.
• Guardrail block → HTTP 400 guardrail_blocked, nazywając guardrail i regułę, która odpaliła. Nie kosztuje limitu.
• Guardrail mask → dopasowanie jest redagowane (np. jane@acme.com → [EMAIL]) i żądanie kontynuuje z oczyszczonym tekstem.

Aby osiągnąć postawę egzekwowania: wyłącz shadow_mode na polityce firewalla i zmień akcje reguł guardrail z flag na block lub mask odpowiednio.

​

5. Rekomendowane wdrożenie

​

6. Poziomy autonomii — ustaw to wszystko naraz

Dostrajanie polityk reguła po regule to precyzyjna ścieżka. Poziomy autonomii to ta szybka — jeden przełącznik, który atomowo ustawia postawę Firewall i Guardrails twojej przestrzeni roboczej w jednej transakcji, z jednym kliknięciem cofnięcia: Zastosuj przez POST /api/workspace/firewall/autonomy (Developer+). Endpoint Simulate (GET /api/workspace/firewall/simulate?level=) podgląda, co zmiana poziomu by zrobiła, zanim ją zastosujesz.

​

7. Mapa mechanizmów — które ustawienie co robi

Ta tabela to autorytatywna referencja. Cztery terminy są odrębne — nie mylić ich:

---

Tryby egzekwowania to nie binarne włącz/wyłącz. Przejdź przez obserwację → cień → egzekwowanie, a twoje reguły są weryfikowane na rzeczywistym ruchu, zanim go kiedykolwiek zablokują.