Przejdź do głównej treści
Pojedyncze wywołanie narzędzia może wyglądać całkowicie niewinnie. Odczytaj jeden rekord CRM: dozwolone. Wywołaj narzędzie eksportu: dozwolone. Trafienie w zewnętrznego hosta: dozwolone. Kształt uruchomienia — pięćdziesiąt odczytów, potem eksport, potem egress do hosta, którego nigdy nie widziałeś o 3 w nocy w niedzielę — to atak. Werdykty per wywołanie oceniają każde wywołanie w izolacji i nigdy go nie widzą. Ta strona omawia dwa mechanizmy firewalla, które obserwują uruchomienie w czasie zamiast jedno wywołanie naraz: reguły sekwencji (uporządkowany łańcuch, który piszesz) oraz wykrywanie anomalii behawioralnych (odchylenie od wyuczonej normy twojej przestrzeni roboczej). Razem to sposób, w jaki wykrywasz zachowanie łańcucha ataku agenta, którego żadna pojedyncza reguła allow/deny nie może wychwycić.
Wszystko tutaj jest konfigurowane w konsoli (Security → Firewall), której trasy zarządzania używają twojej sesji / tokenu dostępu — nie klucza relay sk-orca-…. Wywołania /v1/* twojego agenta się nie zmieniają.

​
1. Dlaczego reguły per wywołanie pomijają łańcuch

Globy narzędzi i klauzule argumentów firewalla są z założenia bezstanowe i deterministyczne — decydują o jednym wywołaniu, szybko, na gorącej ścieżce. To dokładnie to, czego chcesz dla „zablokuj shell.exec rm -rf”. To dokładnie zła rzecz dla powolnej eksfiltracji, gdzie każde pojedyncze wywołanie jest legalne. Dwa komplementarne narzędzia wypełniają lukę:

Reguły sekwencji

Reguła, którą piszesz, dopasowująca uporządkowany łańcuch wywołań w oknie czasowym — „masowy odczyt → eksport → egress”. Ty nazywasz wzorzec.

Wykrywanie anomalii

Firewall uczy się normalnego kształtu użycia narzędzi każdej przestrzeni roboczej i flaguje odchylenia — pętle ponawiania, nigdy wcześniej niewidziane ścieżki narzędzi oraz skoki wolumenu/kosztu. Bez reguły do napisania.

​
2. Reguły sekwencji: nazwij łańcuch ataku

Reguła sequence żyje wewnątrz polityki firewalla jak każda inna reguła, ale zamiast pojedynczego tool_name_glob niesie uporządkowaną listę kroków. Każdy krok to glob narzędzia z opcjonalnym min_count i opcjonalnym egress: true; kroki muszą wystąpić w kolejności (przeplatanie z niezwiązanymi wywołaniami jest w porządku), a cały łańcuch musi zakończyć się w window_seconds. 
{
  "label": "bulk-read-then-exfil",
  "verdict": "audit",
  "sequence": {
    "window_seconds": 600,
    "steps": [
      { "match": "crm.*",   "min_count": 50 },
      { "match": "*.export" },
      { "match": "*", "egress": true }
    ]
  }
}
To odpala, gdy agent odczyta 50+ rekordów crm.*, potem wywoła dowolne narzędzie *.export, potem zrobi dowolne wywołanie egress — wszystko w ciągu dziesięciu minut. Każde wywołanie samo w sobie by przeszło; wzorzec to sygnał.
Sekwencja jest ewaluowana na wywołaniu, które ją kończy. Inline pętla reguł pomija reguły łańcucha (jedno wywołanie nie może zaspokoić wielokrokowego łańcucha); dopasowanie działa, gdy wywołanie mogłoby być ostatnim krokiem łańcucha, w którym to momencie firewall pobiera ostatnie zdarzenia tego principala i testuje łańcuch. verdict, który ustawiasz na regule, to to, co potem dzieje się z kończącym wywołaniem: audit rejestruje je i przepuszcza, pending_approval wstrzymuje je do przeglądu przez człowieka, a deny je blokuje. Więc łańcuch może zatrzymać swoje ostatnie wywołanie w czasie rzeczywistym — wybierz werdykt do dopasowania. Użyj audit, gdy chcesz tylko wykrywać i alarmować; użyj pending_approval lub deny (lub połącz z per wywołanie deny / regułą egress), gdy potrzebujesz twardego zatrzymania.
Pełna składnia pola sequence — window_seconds: 0 dla braku ograniczenia czasowego, domyślne min_count, semantyka porządkowania kroków — jest w schemacie reguły. Pisz reguły sekwencji w edytorze reguł konsoli; zapisywanie to akcja Developer+.

​
3. Wykrywanie anomalii: odchylenie od wyuczonej normy

Tam, gdzie reguły sekwencji pytają „czy ten konkretny wzorzec się zdarzył”, wykrywanie anomalii pyta „czy cokolwiek w tym uruchomieniu jest nienormalne dla tej przestrzeni roboczej”. Nie potrzebuje reguły — firewall buduje bazową linię z twojego własnego ruchu i ocenia aktywność na żywo wobec niej. Cztery rodzaje się ujawniają:
Wolumen wywołań per (narzędzie, klucz) oceniany wobec wyuczonej bazowej linii dla tej godziny-tygodnia. Wiersz ujawnia się, gdy liczba przekroczy bezwzględną podłogę i biegnie wysoko względem bazowej linii, albo gdy jego z-score przekroczy próg statystyczny. Więc „100 wywołań db.query o 3 w nocy w niedzielę” wyróżnia się, mimo że wtorkowy-14:00 wybuch tej samej wielkości by się nie wyróżniał.
Ten sam pomysł zastosowany do wydatków: narzędzie spalające wielokrotności swojego wyuczonego bazowego kosztu dla tej godziny-tygodnia. Wczesne ostrzeżenie denial-of-wallet — połącz je z regułą cap_cost, aby wyegzekwować twardy limit.
Grupa (conversation, tool, arguments), która powtarza się wiele razy w ciasnym oknie — agent utknięty na wywoływaniu tego samego zawodzącego narzędzia z tymi samymi argumentami w kółko, zamiast powolnego legalnego odpytywania.
Przejście tool_a → tool_b, którego ta przestrzeń robocza nigdy wcześniej nie wykonała. Pierwszy raz, gdy agent przechodzi z read_file prosto do http_fetch, ta krawędź się zapala, nawet jeśli oba narzędzia są indywidualnie dozwolone.

​
Bazowa linia godziny-tygodnia

Bazowa linia to 14-dniowa średnia krocząca kubełkowana po godzinie tygodnia (weekday × 24 + hour), więc wtorek-14:00 jest porównywany wobec przeszłej historii wtorku-14:00 konkretnie — nie płaskiej średniej wszech czasów, która wymyłaby twój prawdziwy dobowy i tygodniowy rytm. Zupełnie nowa przestrzeń robocza bez wyuczonej normy jeszcze wychwytuje oczywisty zalew przez bezwzględną podłogę, więc jesteś chroniony od pierwszego dnia.
Strumień raportuje nazwy narzędzi, zredagowane id kluczy, liczniki i z-score — nigdy surowego materiału klucza. Każda anomalia niesie sugerowaną naprawę (rate_limit, review lub block_tool), więc następny krok to jedno kliknięcie, nie zgadywanie.

​
4. Jeden konkretny przebieg

Załóżmy, że skompromitowany prompt napędza jednego z twoich agentów w ciasną pętlę awarii, potem sonduje ścieżkę eksportu, której nigdy nie dotykał. Oto, co widzisz — bez reguły napisanej z wyprzedzeniem:
1

Agent źle się zachowuje

Wstrzyknięte instrukcje popychają agenta do ponawiania zawodzącego db.query z identycznymi argumentami, potem wywołania report.export, po którym następuje wychodzący fetch — ścieżka, której ta przestrzeń robocza nigdy nie uruchomiła.
2

Otwórz strumień anomalii

W Security → Firewall → Anomalies uruchomienie ujawnia retry_loop na db.query i novel_path na krawędzi report.export → http_fetch. Czytanie strumienia to akcja Member — każdy w zespole może triażować.
3

Potwierdź w trace zdarzeń

Przejdź do logu zdarzeń i analityki uruchomień, aby zobaczyć dokładną sekwencję wywołań, skorelowaną z uruchomieniem agenta i konwersacją. Strumień anomalii jest czytelny dla Membera, ale log zdarzeń i trace uruchomienia niosą proweniencję wywołań narzędzi i są Developer+.
4

Zamień znalezisko w regułę

Teraz, gdy zobaczyłeś łańcuch, zakoduj go: deny na niebezpiecznym eksporcie, lista dozwolonych egress na fetchu albo reguła sekwencji, która audytuje cały wzorzec następnym razem. Wykrywanie anomalii znajduje nieznane; reguła przypina znane.
Jeśli strumień jest hałaśliwy, gdy stroisz — legalne zadanie wsadowe, które naprawdę skacze co niedzielę, powiedzmy — uśpij strumień anomalii na do 7 dni, gdy badasz. Uśpienie to akcja Developer+; okno jest zaciskane po stronie serwera, więc wykrywanie zawsze wraca samo.

​
5. Reguły sekwencji a wykrywanie anomalii

Rozwiązują sąsiednie problemy — wybierz ten, który pasuje do tego, co wiesz:
Reguła sekwencjiWykrywanie anomalii
Ty piszeszDokładny łańcuchNic — ono się uczy
WychwytujeZnany wielokrokowy wzorzecNieznane / nienormalne
DziałaStosuje werdykt reguły do kończącego wywołania (audit / pending_approval / deny)Ujawnia na strumieniu
Dojrzała przestrzeń robocza uruchamia oba: wykrywanie anomalii to radar, który ujawnia łańcuchy, których nie przewidziałeś — tylko ujawnianie, nigdy blokowanie; reguły sekwencji to sposób, w jaki kodyfikujesz te, które masz, więc są oznaczone, śledzone i (z werdyktem pending_approval lub deny) zdolne bramkować kończące wywołanie. Dla twardego zatrzymania pojedynczego wywołania niezależnie od jakiegokolwiek łańcucha sięgnij po werdykt per wywołanie.

​
6. RBAC i trasy stojące za strumieniem

Strumień anomalii i reguły sekwencji siedzą pod trasami zarządzania firewallem przestrzeni roboczej — twój token sesji / dostępu, nigdy klucz relay:
Metoda i ścieżkaRolaCel
GET /api/workspace/firewall/anomaliesMemberOdczytaj strumień anomalii (?window=).
POST /api/workspace/firewall/anomalies/snoozeDeveloper+Uśpij strumień ({until}, zaciśnięte do 7 dni).
POST /api/workspace/firewall/rulesDeveloper+Utwórz regułę sekwencji (lub dowolną) pod polityką.
POST /api/workspace/firewall/testDeveloper+Zrób dry-run polityki wobec przykładowego wywołania, zanim na nim polegniesz.
Odczyty strumienia są otwarte dla każdego Membera, by cały zespół mógł triażować; autorowanie reguł i uśpienie strumienia to zapisy Developer+, spójne z resztą modelu RBAC firewalla.

​
Dokąd dalej

Schemat reguły

Pełne pole sequence — kroki, min_count, window_seconds i każde inne pole reguły.

Log zdarzeń

Gdzie lądują dopasowane sekwencje i anomalie — filtruj po uruchomieniu, powierzchni i werdykcie.

Limit kosztu

Zamień sygnał burn_spike w twardy limit wydatków per uruchomienie.

Kontrola egress

Zatrzymaj ostatni krok eksfiltracji łańcucha na granicy sieci.
Dla scenariuszy atakujących, którym te mechanizmy przeciwdziałają, zobacz ataki łańcuchowe, eksfiltrację danych i nadmierną sprawczość. Dla głębokiej referencji firewalla zobacz Reguły Firewall.