Przejdź do głównej treści
Gdy twoja polityka firewalla osądza wywołanie narzędzia, zapisuje wiersz. Strumień zdarzeń to ten bieżący log: jeden rekord na ewaluację, niosący werdykt, powierzchnię, na której odpalił, narzędzie, powód oraz uruchomienie/sesję, do których należał. Tak odpowiadasz na jedyne pytanie, które ma znaczenie po wydaniu polityki — czy firewall faktycznie zrobił to, co myślę, że zrobił, na wywołaniach, na których myślę, że to zrobił? To twoja powierzchnia logów firewalla AI. Każde allow, każde deny, każde wstrzymane zatwierdzenie, każde „byłoby” trybu cienia ląduje tutaj, filtrowalne i skorelowane z uruchomieniem agenta, które je wyprodukowało.
Strumień zdarzeń jest Developer+ do odczytu. Każdy wiersz rezerwuje ograniczone pole args_summary na migawkę argumentów wywołania narzędzia, więc powierzchnia siedzi ponad czytelnymi dla Membera (ustawienia, polityki, wykryte narzędzia, strumień anomalii). Konfiguruj to wszystko z konsoli — to trasy uwierzytelniane sesją, nie wywołania relay.

​
1. Co ląduje w strumieniu zdarzeń

Każda ewaluacja, którą silnik uruchamia, jest rejestrowana — nie tylko bloki. allow i audit zostawiają wiersz dokładnie tak, jak robi to deny, więc strumień to kompletny ślad, nie log wyjątków. Werdykt w wierszu to ten, który agent faktycznie zobaczył:
WerdyktOznacza
allow / auditPrzepuszczone; audit flaguje to jako coś, co chciałeś obserwować.
denyZablokowane — firewall_blocked (HTTP 400) inbound, błąd narzędzia na mcp.
sanitizePrzesłane z dopasowanymi podłańcuchami zredagowanymi z argumentów wywołania.
pending_approvalWstrzymane dla człowieka; wiersz oznacza, że wywołanie było bramkowane.
observeŻadna polityka nie dopasowała — luka w pokryciu trybu obserwacji.
Nigdy nie zobaczysz dosłownego cap_cost w strumieniu. Reguła cap-cost rozwiązuje się do konkretnego allow lub deny w czasie ewaluacji i to jest to, co zostaje zalogowane — werdykt, którego uruchomienie faktycznie doświadczyło.
W trybie cienia egzekwujące werdykty są degradowane do audit, a powód jest poprzedzony przedrostkiem [shadow] would …, więc strumień pokazuje ci dokładnie, co polityka by zablokowała, zanim przełączysz ją na żywo.

​
2. Co rejestruje każde zdarzenie

Pojedyncze zdarzenie to zdenormalizowana migawka — wystarczająca, by zrekonstruować decyzję bez łączenia z czymkolwiek:
verdict, surface (inbound / response / mcp / egress), tool_name oraz reason dla człowieka („destructive shell command”, „egress to 169.254.169.254 denied”). Gdy dopasowująca reguła miała etykietę, policy_name i rule_label nazywają dokładną regułę, która odpaliła — więc wiersz wskazuje prosto z powrotem na linię, którą napisałeś.
request_id łączy zdarzenie z logiem żądań; conversation_id grupuje sesję wielo-turową; agent_run_id (z step_id / parent_step_id) wiąże je z jednym pełnym uruchomieniem agenta i wywołaniem LLM, które zażądało narzędzia. To one czynią strumień trace’em, a nie płaską listą — zobacz §4.
token_name, model_name oraz ip wywołującego — klucz, model i pochodzenie za wywołaniem. skill_name nazywa skill właściciela (skill), gdy wywołanie było mu przypisywalne, a quarantine flaguje wstrzymanie kwarantanny skilla.
args_summary to ograniczone pole migawki argumentów wywołania narzędzia (powód, dla którego ta powierzchnia jest Developer+). Na zdarzeniu egress egress_host rejestruje wychodzący cel, który był osądzony.
args_summary jest ograniczone — surowe bajty argumentów nigdy nie są zapisywane dosłownie do strumienia, a hash grupowania pętli ponawiania, który wspiera wykrywanie anomalii, jest tylko-serwerowy: nigdy nie wysyła się w API.

​
3. Jeden konkretny przykład

Twój agent wyemitował wywołanie shell.exec z rm -rf /data, reguła deny je wychwyciła, a ty chcesz zobaczyć tę jedną decyzję. Filtruj strumień po werdykcie i narzędziu: 
# Developer+ console session — GET /api/workspace/firewall/events
curl https://api.orcarouter.ai/api/workspace/firewall/events?verdict=deny&tool=shell.exec \
  -H "Authorization: Bearer $ORCA_CONSOLE_TOKEN"

{
  "events": [
    {
      "verdict": "deny",
      "surface": "response",
      "tool_name": "shell.exec",
      "reason": "destructive shell command",
      "policy_name": "agent-baseline",
      "rule_label": "block destructive shell",
      "model_name": "gpt-4o",
      "token_name": "prod-agent",
      "agent_run_id": "run_abc",
      "request_id": "req_…"
    }
  ],
  "total": 1
}
Konsola renderuje te same wiersze jako filtrowalną tabelę — rzadko trafiasz w trasę ręcznie. Konfiguruj filtry, wgłębiaj się w uruchomienie i eksportuj z widoku zdarzeń; curl powyżej jest tylko po to, by pokazać kształt.
$ORCA_CONSOLE_TOKEN to twój token sesji / dostępu, nie klucz relay sk-orca-…. Trasy /api/workspace/firewall/* są uwierzytelniane konsolą i bramkowane rolą; tylko ruch /v1/* używa klucza relay.

​
4. Koreluj po uruchomieniu i sesji

Powód, dla którego każde zdarzenie niesie agent_run_id i conversation_id, to byś mógł przestać patrzeć na wywołania w izolacji i zacząć pytać, co ten agent zrobił przez całe swoje uruchomienie:
FiltrPytanie, na które odpowiada
run_id=<run>Każdy werdykt w jednym uruchomieniu agenta — pełny ślad akcji.
session_id=<conv>Każdy werdykt w wielo-turowej konwersacji.
verdict=deny,pending_approvalWidok „co zostało zatrzymane lub wstrzymane” w jednym zapytaniu.
surface=egressTylko decyzje o wychodzącym celu — soczewka eksfiltracji.
Lista zdarzeń przyjmuje też since / until (sekundy uniksowe) oraz limit / skip do stronicowania. Dla zwiniętego widoku — jeden wiersz na uruchomienie lub sesję z rozbiciem per werdykt, odrębnymi narzędziami i modelami oraz pierwszym/ostatnim zaobserwowaniem — konsola odczytuje GET /api/workspace/firewall/events/aggregate?group_by=run (lub group_by=session), a drzewo trace agenta odczytuje /trace/by-run. Oba są Developer+, tak samo jak surowy strumień.
Z szuflady logu żądań możesz obrócić w drugim kierunku: GET /api/workspace/firewall/events/by-request/:request_id zwraca każde zdarzenie firewalla wychwycone pod pojedynczym żądaniem — przydatne, gdy jedno żądanie uruchomiło kilka reguł na różnych powierzchniach.

​
5. Retencja i wymazanie

Zdarzenia firewalla niosą własny horyzont retencji — domyślnie 30 dni, zaciskany po stronie serwera do twardego maksimum 365 dni. Każde zdarzenie jest zapisywane z wygaśnięciem i postarzane automatycznie indeksem TTL; nic w strumieniu nie żyje poza twoim ustawieniem retencji. Żądanie prawa do wymazania kaskaduje też tutaj: usunięcie użytkownika rozpoczyna 30-dniowy okres karencji, po którym jego PII jest wyczyszczane, a jego zdarzenia firewalla są usuwane obok logów żądań i dopasowań guardrail tego samego zakresu.

​
Dokąd dalej

Werdykty

Co każdy werdykt w strumieniu faktycznie zrobił z wywołaniem.

Tryb cienia

Odczytaj strumień w trybie „byłoby”, zanim wyegzekwujesz.

Etapy i powierzchnie

Cztery powierzchnie, które nazywa pole surface.

Referencja firewalla

Pełna referencja polityki, reguł i API.
Dla zagrożeń, które te logi pomagają wychwytywać na gorącym uczynku, zobacz eksfiltrację danych i niebezpieczne wywołania narzędzi. Jak firewall łączy się z prześwietlaniem tekstu promptu/odpowiedzi, zobacz firewall + guardrails.