Przejdź do głównej treści
Napisałeś regułę firewalla — deny na shell.exec, listę dozwolonych egress, klauzulę argumentu, która odpala tylko na rm -rf — i teraz chcesz wiedzieć, że robi dokładnie to, co myślisz, zanim zmieni choć jedno produkcyjne wywołanie narzędzia. Firewall daje ci trzy niedestrukcyjne sposoby na testowanie reguł firewalla, każdy odpowiadający na inne pytanie:

Dry-run jednego wywołania

Piaskownica Test przepuszcza jedno syntetyczne wywołanie narzędzia przez prawdziwy silnik i zwraca werdykt — nic dyspozytowanego, nic logowanego. Developer+.

Odtwórz postawę

Simulate odtwarza poziom autonomii wobec twojego ostatniego ruchu i liczy, ile wywołań by zablokował. Czytelne dla Membera.

Uruchom wobec ruchu na żywo

Tryb cienia ewaluuje całą politykę na prawdziwych wywołaniach, ale degraduje każdy egzekwujący werdykt do audit. Zerowy promień rażenia.
Wszystkie trzy konfigurują się przez konsolę (lub trasy zarządzania /api/workspace/firewall/*, które uwierzytelniają się twoją sesją / tokenem dostępu — nie kluczem relay sk-orca-…). Wywołania relay /v1/* twojego agenta nigdy się nie zmieniają, gdy testujesz.

​
1. Testuj reguły firewalla piaskownicą Test dry-run

Piaskownica Test to najściślejsza pętla: podaj jej pojedyncze syntetyczne wywołanie narzędzia, a uruchamia prawdziwy silnik ewaluacji — pełne rozwiązywanie polityki, reguły przechodzone w kolejności priorytetów, wygrywa-pierwsze-dopasowanie — potem zwraca werdykt, regułę, która go wyprodukowała, i czytelny dla człowieka powód. Wywołanie to dry run: nic nie jest dyspozytowane do żadnego narzędzia i nic nie jest zapisywane do strumienia zdarzeń ani inwentarza Discovered-tools. Odpowiada na jedno pytanie precyzyjnie: przy tej dokładnej nazwie narzędzia i tych argumentach, co decyduje moja polityka — i która reguła decyduje?
Piaskownica Test jest Developer+. Może podglądać wobec niezapisanej roboczej polityki po id, a odpowiedź ujawnia dopasowaną nazwę polityki i etykietę reguły, więc siedzi bliżej podglądu powierzchni zapisu niż zwykłego odczytu — w przeciwieństwie do Simulate i innych widoków odczytu, które są otwarte dla każdego członka.

​
Jeden konkretny dry run

Powiedzmy, że dodałeś regułę, która powinna odmawiać shell.exec tylko, gdy polecenie zawiera rm -rf. Chcesz potwierdzić dwie rzeczy w jednym posiedzeniu: niebezpieczne polecenie jest odmawiane, a niewinne wciąż przechodzi.
1

Przetestuj niebezpieczne wywołanie

W Security → Firewall otwórz zakładkę Test, wybierz powierzchnię response, wprowadź nazwę narzędzia shell.exec i argumenty {"command": "rm -rf /data"}, i uruchom. Odpowiedź nazywa werdykt i dopasowaną regułę:
{
  "verdict": "deny",
  "policy_name": "prod-agents",
  "rule_label": "block destructive shell",
  "reason": "destructive shell command",
  "gap": false,
  "shadow_mode": false
}
2

Przetestuj niewinne wywołanie

Uruchom je ponownie z {"command": "ls -la"}. Klauzula argumentu już nie dopasowuje, więc reguła spada do domyślnej polityki — powinieneś zobaczyć allow lub audit i pustą rule_label. Jeśli rm -rf odmawia, a ls -la nie, twoja klauzula argumentu jest poprawnie ograniczona.
3

Podejrzyj roboczą, zanim ją przypniesz

Przekaż policy_id, aby ewaluować wobec konkretnej roboczej polityki zamiast tej, do której obecnie rozwiązuje się twój ruch — więc możesz udowodnić, że nowa polityka jest poprawna, zanim przypniesz do niej klucz lub promujesz ją na domyślną przestrzeni roboczej.
Odczytaj gap w odpowiedzi. gap: true oznacza, że polityka rozwiązała się, ale żadna reguła wewnątrz niej nie dopasowała wywołania (a przestrzeń robocza jest w trybie obserwacji) — narzędzie wymknęło się każdej regule i spadło do domyślnej. To dziura w pokryciu do zamknięcia, zanim wydasz, nie werdykt, któremu ufać.
Piaskownica Test używa tych samych powierzchni co ewaluacja na żywo — inbound, response, mcp, egress (domyślnie inbound) — więc testuj każdą regułę na powierzchni, do której jest przypięta. Na inbound nie ma argumentów czasu wywołania, więc reguła sanitize eskaluje tam do bloku dokładnie tak, jak robiłaby to na produkcji; zobacz etapy, dlaczego powierzchnia ma znaczenie.

​
2. Symuluj poziom autonomii, zanim go zastosujesz

Piaskownica Test sprawdza jedno wywołanie. Simulate odpowiada na pytanie na poziomie postawy: gdybym przełączył całą tę przestrzeń roboczą na surowszy poziom autonomii, ile mojego ostatniego ruchu by zablokował? Simulate odtwarza reguły deny kandydującego poziomu wobec twoich końcowych zdarzeń firewalla i zwraca przyszły wpływ — tylko nazwy narzędzi i liczniki, nigdy argumenty. Jest tylko-do-odczytu i czytelny dla Membera, więc każdy w zespole może podejrzeć promień rażenia tight, zanim Developer się na niego zdecyduje.
  • tight — default-deny, odmowa destrukcyjnego shella, odmowa narzędzi w kształcie fetch (wektor SSRF), PII Shield + Secrets Blocker egzekwowane. Simulate pokazuje, ile twojego prawdziwego ruchu ta podłoga by wychwyciła.
  • balanced — domyślne audit, odmowa destrukcyjnego shella, PII Shield tylko-audit (flaguje PII). Rekomendowana postawa początkowa.
  • permissive — tylko obserwacja; nic nie egzekwowane.
Simulate niczego nie zmienia — to co-jeśli nad przeszłymi zdarzeniami. Zastosowanie poziomu autonomii (zapis Developer+) materializuje rzeczywiste, edytowalne wiersze polityki autonomy_* i guardrail, z cofnięciem jednym kliknięciem z migawki audytu. Podejrzyj z Simulate, potem zastosuj, gdy licznik wygląda dobrze.

​
3. Tryb cienia: testuj wobec ruchu na żywo bez promienia rażenia

Piaskownica Test i Simulate to podglądy offline. Tryb cienia to ten na żywo: flaga per polityka, która ewaluuje politykę na prawdziwym ruchu agentów, przechodzi każdą regułę, wybiera werdykt — potem degraduje każdy egzekwujący werdykt (deny, sanitize, pending_approval) do audit i poprzedza powód przedrostkiem [shadow] would …. Wywołanie zawsze przechodzi; nic nie jest blokowane, redagowane ani wstrzymywane. To sprawia, że strumień zdarzeń czyta się jak uruchomienie produkcyjne z wyłączonym egzekwowaniem. Filtruj po [shadow], a masz kompletną listę każdego wywołania, które polityka zaraz zacznie blokować — zanim zablokuje choć jedno.
Metoda testowaDziała wobecPytanie, na które odpowiada
Piaskownica TestJedno syntetyczne wywołanie„Jaki werdykt dostaje to dokładne wywołanie i która reguła decyduje?”
SimulateOstatnie zdarzenia„Ile wywołań zablokowałby surowszy poziom autonomii?”
Tryb cieniaRuch na żywo„Co ta polityka zablokowałaby na prawdziwym ruchu produkcyjnym?”
Tryb cienia to najgłębszy z trzech — pełne pokrycie na żywo z zerowym promieniem rażenia. Ma własną stronę: Wytocz politykę firewalla w trybie cienia omawia przełącznik, powody [shadow] would … i przełączenie na egzekwowanie.

​
4. Praktyczna kolejność testowania

Trzy narzędzia komponują się w jedną ścieżkę bezpiecznego wdrożenia — najtańsze sprawdzenie pierwsze, najszersze pokrycie ostatnie:
1

Zrób dry-run reguł, które właśnie napisałeś

Użyj Test, aby potwierdzić, że każda nowa reguła odpala na wywołaniach, na których powinna, i przepuszcza te, których nie powinna — w tym przypadki negatywne. Szybko, Developer+, nic persystowanego.
2

Oszacuj postawę (opcjonalne)

Jeśli sięgasz po poziom autonomii zamiast ręcznie pisanych reguł, Simulate poziom i odczytaj licznik przyszłych blokad wobec prawdziwego ruchu, zanim go zastosujesz.
3

Wprowadź w cień wobec ruchu na żywo

Włącz tryb cienia i pozwól płynąć reprezentatywnemu oknu prawdziwych wywołań. Odczytaj zdarzenia [shadow] would …; zacieśnij każdą regułę, która ujawnia fałszywie pozytywny przypadek — wciąż w cieniu, zerowy promień rażenia.
4

Egzekwuj

Gdy strumień odpala na tym, czego oczekujesz, i niczym, czego nie chcesz, wyłącz cień. Następne wywołanie egzekwuje naprawdę.
Testowanie podgląda politykę, nie zarządzane skille. Skill w trybie block lub quarantine wciąż egzekwuje nawet pod polityką w cieniu — dyspozycja przeglądu skilla wygrywa. Wprowadzenie polityki w cień nigdy nie było żądaniem zniesienia kwarantanny skilla.

​
5. Referencja API

Te trasy zarządzania używają twojego tokenu sesji / dostępu i są w zakresie przestrzeni roboczej:
Metoda i ścieżkaRolaCel
POST /api/workspace/firewall/testDeveloper+Dry-run jednego syntetycznego wywołania narzędzia wobec rozwiązanej (lub roboczej policy_id) polityki. Zwraca werdykt, policy_name, rule_label, reason, gap, shadow_mode. Nic dyspozytowanego ani logowanego.
GET /api/workspace/firewall/simulate?level=MemberOdtwórz poziom autonomii wobec ostatnich zdarzeń; zwraca liczniki przyszłych blokad.
GET /api/workspace/firewall/policies/:idMemberOdczytaj bieżącą flagę shadow_mode polityki.
PUT /api/workspace/firewall/policiesDeveloper+Przełącz shadow_mode na polityce.
Ciało Test przyjmuje surface (domyślnie inbound), wymagane tool_name, opcjonalne args_json oraz opcjonalne policy_id, by nadpisać rozwiązywanie.

​
Dokąd dalej

Tryb cienia

Wdrożenie na ruchu na żywo: [shadow] would …, filtr zdarzeń i przełączenie na egzekwowanie.

Waliduj argumenty

Ogranicz regułę do których argumentów — klauzule, które piaskownica Test pozwala zweryfikować wobec rm -rf vs ls -la.

Werdykty

Co allow / audit / deny / sanitize / pending_approval / cap_cost każdy robi, gdy test przestaje być testem.

Log zdarzeń

Gdzie lądują werdykty w cieniu — filtruj, wgłębiaj się w uruchomienia i dopasowane reguły.
Dla gramatyki dopasowania reguł, którą ćwiczą te testy, zobacz pełną referencję reguł firewalla; gdzie testowanie pasuje do szerszego modelu, zobacz tryby egzekwowania.