Przejdź do głównej treści
Statyczne reguły firewalla wychwytują wywołania, które wiedziałeś, jak nazwać. Nie mogą wychwycić wywołania, które jest indywidualnie dozwolone, ale złe w agregacie — 200 wywołań db.query o 3 w nocy w niedzielę, agenta walącego w jedno zawodzące narzędzie w ciasnej pętli, skok narzędzie-do-narzędzia, którego ta przestrzeń robocza nigdy wcześniej nie wykonała. Każde wywołanie przechodzi każdą regułę; wzorzec to problem. Wykrywanie anomalii firewalla to warstwa behawioralna. Brama uczy się normalnego kształtu użycia narzędzi twojej przestrzeni roboczej i ocenia aktywność na żywo wobec niego, ujawniając odchylenia na strumieniu, który może odczytać każdy Member. Tak zauważasz skompromitowanego agenta lub rozbieganą pętlę bez wcześniejszego napisania reguły dla kształtu, którego nigdy nie widziałeś. Ta strona to skupione lądowanie dla tego strumienia firewall anomaly detection; Przegląd Firewall to głęboka referencja.
Strumień anomalii to wykrywanie, nie egzekwowanie. Mówi ci, co wygląda źle — nie blokuje. Gdy wzorzec jest prawdziwy, zamieniasz go w regułę lub werdykt z limitem tempa, więc następne wystąpienie jest zatrzymane inline. Odczyt strumienia jest otwarty dla każdego Membera; zamiana znaleziska w politykę to Developer+.

​
1. Co flaguje wykrywanie anomalii firewalla

Cztery rodzaje sygnałów, każdy związany z innym trybem awarii:
Wolumen wywołań per narzędzie oceniany wobec wyuczonej bazowej linii godziny-tygodnia. Narzędzie odpala rate_spike, gdy jego liczba przekroczy bezwzględną podłogę i biegnie wysoko względem bazowej linii dla tej godziny, albo gdy jego z-score przekroczy próg. Kluczowanie na godzinie-tygodnia (nie godzinie-dnia) oznacza, że wtorek-14:00 jest porównywany z przeszłymi wtorkami-14:00, więc legalny ruch szczytu dnia roboczego nie czyta się jako skok, podczas gdy ten sam wolumen o 3 w nocy w niedzielę tak.
To samo porównanie godziny-tygodnia, zastosowane do zakumulowanego kosztu zamiast liczby wywołań. Narzędzie, którego wydatki biegną znacznie ponad jego wyuczoną normą kosztu, ujawnia się jako burn_spike — sygnał wczesnego ostrzeżenia dla agenta, który jest drogi, zanim stanie się destrukcyjny.
Grupa (conversation, tool, arguments), która powtarza się wiele razy w krótkim oknie — agent utknięty na ponownym wystawianiu tego samego zawodzącego wywołania narzędzia zamiast odzyskać się. Powolne, legalne odpytywanie go nie wyzwala; sygnałem jest ciasna pętla.
Kolejne przejście tool_a → tool_b, dla którego ta przestrzeń robocza nie ma wyuczonej bazowej linii. Pierwszy raz, gdy agent przechodzi, powiedzmy, crm.read → http.fetch, ta krawędź jest nowa — dokładnie rodzaj kroku, który robi łańcuch eksfiltracji danych.
Wykrywanie anomalii uzupełnia reguły sekwencji. Reguła sekwencji dopasowuje łańcuch, który zdefiniowałeś z wyprzedzeniem; novel_path flaguje przejście, którego nie — tak odkrywasz łańcuchy warte napisania reguły sekwencji.

​
2. 14-dniowa bazowa linia

Detektor to nie stały próg — to wyuczona norma. Dla każdego kubełka (tool, hour-of-week) brama trzyma kroczącą oczekiwaną liczbę wywołań i koszt, uzupełnione z 14-dniowego wglądu wstecz (około dwóch wystąpień każdego kubełka godziny-tygodnia — wystarczająco, by wygładzić pojedynczy dziwny dzień bez utraty tygodniowego kształtu). novel_path używa równoległej bazowej linii przejść: wyuczonej liczby wystąpień dla każdej krawędzi tool_a → tool_b w tej godzinie-tygodnia. Zupełnie nowa przestrzeń robocza nie ma jeszcze bazowej linii. To w porządku: bez wyuczonej normy detektory wolumenu spadają do bezwzględnej podłogi, więc oczywisty zalew jest wciąż wychwytywany pierwszego dnia, podczas gdy normy per godzina się wypełniają.
SygnałZ czego się uczy
rate_spike / burn_spikeLiczba i koszt per (tool, hour-of-week), 14-dniowe kroczące.
novel_pathLiczba przejść per (tool_a → tool_b, hour-of-week).
retry_loopBrak bazowej linii — okienkowy próg powtórzeń na (conversation, tool, args).
Strumień raportuje tylko nazwy narzędzi, zredagowane id tokenów i liczniki. Surowe id klucza API nigdy się nie pojawia — każdy element niesie jednokierunkowy skrót wywołującego tokenu, więc możesz odróżnić dwie anomalie bez tego, by strumień kiedykolwiek wyciekł klucz za nimi.

​
3. Jeden konkretny odczyt

Powiedzmy, że klucz agenta zaczyna pętlić. Pobierz strumień w konsoli pod Security → Firewall → Anomalies lub odczytaj go bezpośrednio — każdy Member może: 
curl https://api.orcarouter.ai/api/workspace/firewall/anomalies \
  -H "Authorization: Bearer $ORCA_SESSION_TOKEN"

{
  "data": {
    "items": [
      {
        "id": "3f1c9a7b0e2d4a86",
        "kind": "retry_loop",
        "tool_name": "db.query",
        "token_id_redacted": "sk-***-9f2a",
        "count": 412,
        "baseline": 0,
        "z_score": 0,
        "suggested_action": "rate_limit",
        "first_seen": 1749470400,
        "last_seen": 1749470520
      }
    ],
    "snoozed_until": 0
  }
}
Element retry_loop nie niesie baseline ani z_score (te pola pozostają 0 — należą do detektorów wolumenu/kosztu) i niesie stabilne nieprzezroczyste id, więc dwie odrębne pętle na tym samym narzędziu nie kolidują na jednym wierszu. rate_spike to odwrotność: raportuje wyuczoną baseline i z_score i zostawia id puste.
$ORCA_SESSION_TOKEN to twój token sesji / dostępu konsoli — to samo auth co każda trasa zarządzania /api/workspace/firewall/*. To nie klucz relay sk-orca-… (te służą tylko do wywołań modelu /v1/*) i nie klucz firewall-gateway. Klucz relay na tej trasie jest odrzucany.
Każdy element nazywa narzędzie, zredagowany token, ile wywołań odpaliło, z-score (tylko sygnały wolumenu/kosztu) oraz suggested_action (rate_limit, block_tool lub review). Stąd działasz: rzuć regułę deny na narzędzie, zwaliduj jego argumenty lub otwórz log zdarzeń, aby zobaczyć dokładnie, co agent zrobił.

​
4. Uśpienie strumienia

Znany test obciążeniowy lub planowane uzupełnienie rozświetli strumień. Zamiast gonić za hałasem, uśpij go — na do 7 dni: 
curl -X POST https://api.orcarouter.ai/api/workspace/firewall/anomalies/snooze \
  -H "Authorization: Bearer $ORCA_SESSION_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{"until": 1749643200}'
Gdy uśpienie jest aktywne, strumień nie zwraca żadnych elementów i raportuje snoozed_until; czyści się sam w momencie, gdy minie termin. Limit to twardy pułap — until wpisane palcem na klawiaturze lub wrogo, dalej w przyszłość, jest zaciskane, więc wykrywania anomalii nie da się uciszyć w nieskończoność. Wysłanie POST z until w przeszłości lub teraz czyści istniejące uśpienie.
Odczyt strumienia to akcja Member; uśpienie go to Developer+ — wyciszenie ogólnoprzestrzennego sygnału bezpieczeństwa to zapis, nie odczyt.

​
5. RBAC w skrócie

Powierzchnia analityki dzieli się wzdłuż zwykłej linii odczyt/działanie:
AkcjaRola
Odczyt strumienia anomaliiMember
Odczyt ustawień, polityk, wykrytych narzędziMember
Uśpienie strumieniaDeveloper+
Events, runs, aggregate, traceDeveloper+
Napisanie reguły ze znaleziskaDeveloper+
Lżejsze widoki agregowane — ustawienia, polityki i mapa pokrycia wykrytych narzędzi — to też odczyty Member; szczegół zdarzeń i uruchomień na poziomie wierszy jest Developer+, ponieważ niesie dane argumentów per wywołanie.

​
6. Od sygnału do polityki

Strumień to początek pętli, nie koniec:
1

Wypatrz wzorzec

novel_path lub rate_spike pokazuje kształt, którego nie oczekiwałeś. Odczytaj go wobec logu zdarzeń, aby potwierdzić, że jest prawdziwy, nie jednorazowy.
2

Napisz regułę

Zamień znalezisko w egzekwowanie — block, klauzulę argumentu, regułę sekwencji dla łańcucha lub limit kosztu dla przepalania.
3

Wytocz to bezpiecznie

Wyląduj regułę najpierw w trybie cienia, aby zmierzyć jej promień rażenia, zanim zablokuje choć jedno wywołanie, potem egzekwuj.

​
Dokąd dalej

Przegląd Firewall

Pełna referencja wykrywania anomalii i reszta płaszczyzny polityki.

Log zdarzeń

Wgłęb się z anomalii w dokładne wywołania za nią.

Zablokuj narzędzie

Zamień znalezisko w egzekwującą regułę.

Tryby egzekwowania

Jak wykrywanie, audit, cień i egzekwowanie pasują do siebie.
Dla zagrożeń, które te sygnały odsłaniają, zobacz eksfiltrację danych i nadmierną sprawczość.