Zum Hauptinhalt springen
Wenn Ihre Firewall-Policy einen Tool-Call beurteilt, schreibt sie eine Zeile. Der Events-Feed ist dieses laufende Log: ein Datensatz pro Auswertung, der das Verdikt, die Surface, auf der es feuerte, das Tool, den Grund und den Run/die Session trägt, zu dem/der es gehörte. So beantworten Sie die einzige Frage, die zählt, nachdem Sie eine Policy ausgeliefert haben — hat die Firewall tatsächlich das getan, was ich denke, auf den Aufrufen, auf denen ich denke, dass sie es getan hat? Dies ist Ihre KI-Firewall-Logs-Surface. Jedes allow, jedes deny, jedes zurückgehaltene Approval, jedes Shadow-Mode-„Would-have” landet hier, filterbar und zurück zum Agentenlauf korreliert, der es erzeugt hat.
Der Events-Feed ist Developer+ zum Lesen. Jede Zeile reserviert ein begrenztes args_summary-Feld für einen Tool-Call-Argument-Snapshot, sodass die Surface über den für Member lesbaren sitzt (Einstellungen, Policies, Discovered Tools, der Anomalie-Feed). Konfigurieren Sie all das aus der Konsole — das sind session-authentifizierte Routen, keine Relay-Aufrufe.

​
1. Was im Events-Feed landet

Jede Auswertung, die die Engine ausführt, wird aufgezeichnet — nicht nur die Blocks. Ein allow und ein audit hinterlassen eine Zeile genauso wie ein deny, sodass der Feed eine vollständige Spur ist, kein Ausnahme-Log. Das Verdikt auf einer Zeile ist dasjenige, das der Agent tatsächlich gesehen hat:
VerdiktBedeutet
allow / auditDurchgelassen; audit flaggt es als etwas, das Sie beobachten wollten.
denyBlockiert — firewall_blocked (HTTP 400) inbound, Tool-Fehler auf mcp.
sanitizeWeitergeleitet mit gematchten Teilstrings, redigiert aus den Argumenten des Aufrufs.
pending_approvalFür einen Menschen zurückgehalten; die Zeile markiert, dass der Aufruf gegatet wurde.
observeKeine Policy matchte — eine Observe-Mode-Abdeckungslücke.
Sie werden nie ein literales cap_cost im Feed sehen. Eine Cap-Cost-Regel löst zur Auswertungszeit auf ein konkretes allow oder deny auf, und das ist es, was geloggt wird — das Verdikt, das der Run tatsächlich erlebt hat.
Im Shadow-Mode werden die durchsetzenden Verdikte auf audit herabgestuft und der Grund wird [shadow] would … vorangestellt, sodass der Feed Ihnen genau zeigt, was eine Policy blockiert hätte, bevor Sie sie scharf schalten.

​
2. Was jedes Event aufzeichnet

Ein einzelnes Event ist ein denormalisierter Snapshot — genug, um die Entscheidung zu rekonstruieren, ohne auf irgendetwas zurück-joinen zu müssen:
verdict, surface (inbound / response / mcp / egress), tool_name und ein menschlicher reason („destructive shell command”, „egress to 169.254.169.254 denied”). Wenn die matchende Regel ein Label hatte, benennen policy_name und rule_label die exakte Regel, die feuerte — sodass die Zeile direkt auf die Zeile zeigt, die Sie geschrieben haben.
request_id joint das Event zum Request-Log; conversation_id gruppiert eine Multi-Turn-Session; agent_run_id (mit step_id / parent_step_id) bindet es an einen vollen Agentenlauf und den LLM-Aufruf, der das Tool angefordert hat. Diese sind es, die den Feed zu einem Trace machen, nicht zu einer flachen Liste — siehe §4.
token_name, model_name und die Aufrufer-ip — der Key, das Modell und die Herkunft hinter dem Aufruf. skill_name benennt den besitzenden Skill, wenn der Aufruf einem zuzuordnen war, und quarantine flaggt einen Skill-Quarantäne-Hold.
args_summary ist das begrenzte Tool-Call-Argument-Snapshot-Feld (der Grund, warum diese Surface Developer+ ist). Auf einem egress-Event zeichnet egress_host das ausgehende Ziel auf, das beurteilt wurde.
args_summary ist begrenzt — die rohen Argumentbytes werden nie wörtlich in den Feed geschrieben, und der Retry-Loop-Gruppierungs-Hash, der die Anomalieerkennung untermauert, ist server-only: er wird nie in der API ausgeliefert.

​
3. Ein konkretes Beispiel

Ihr Agent gab einen shell.exec-Aufruf mit rm -rf /data aus, eine deny-Regel fing ihn ab, und Sie wollen diese eine Entscheidung sehen. Filtern Sie den Feed nach Verdikt und Tool: 
# 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
}
Die Konsole rendert dieselben Zeilen als filterbare Tabelle — Sie treffen die Route selten von Hand. Konfigurieren Sie Filter, drillen Sie in einen Run und exportieren Sie aus der Events-Ansicht; das curl oben dient nur dazu, die Form zu zeigen.
$ORCA_CONSOLE_TOKEN ist Ihr Session-/Access-Token, kein sk-orca-…-Relay-Key. Die /api/workspace/firewall/*-Routen sind konsolen-authentifiziert und rollengesteuert; nur /v1/*-Traffic nutzt einen Relay-Key.

​
4. Nach Run und Session korrelieren

Der Grund, warum jedes Event agent_run_id und conversation_id trägt, ist, dass Sie aufhören können, Aufrufe isoliert zu betrachten, und anfangen zu fragen was hat dieser Agent über seinen ganzen Run getan:
FilterFrage, die er beantwortet
run_id=<run>Jedes Verdikt in einem Agentenlauf — die volle Aktionsspur.
session_id=<conv>Jedes Verdikt über eine Multi-Turn-Konversation.
verdict=deny,pending_approvalDie „was wurde gestoppt oder zurückgehalten”-Ansicht in einer Abfrage.
surface=egressNur Ausgehende-Ziel-Entscheidungen — die Exfiltrations-Linse.
Die Events-Liste akzeptiert auch since / until (Unix-Sekunden) und limit / skip für Paging. Für die aufgerollte Ansicht — eine Zeile pro Run oder Session mit einer Pro-Verdikt-Aufschlüsselung, distinkten Tools und Modellen und first/last-seen — liest die Konsole GET /api/workspace/firewall/events/aggregate?group_by=run (oder group_by=session), und der Agent-Trace-Baum liest /trace/by-run. Beide sind Developer+, gleich wie der rohe Feed.
Aus der Request-Log-Schublade können Sie in die andere Richtung pivotieren: GET /api/workspace/firewall/events/by-request/:request_id gibt jedes Firewall-Event zurück, das unter einem einzelnen Request erfasst wurde — praktisch, wenn ein Request mehrere Regeln über Surfaces hinweg auslöste.

​
5. Aufbewahrung und Löschung

Firewall-Events tragen ihren eigenen Aufbewahrungshorizont — ein 30-Tage-Default, server-geklemmt auf ein 365-Tage-Hartmaximum. Jedes Event wird mit einem Ablauf geschrieben und automatisch durch einen TTL-Index ausgealtert; nichts im Feed lebt über Ihre Aufbewahrungseinstellung hinaus. Eine Right-to-Erasure-Anfrage kaskadiert auch hierher: das Löschen eines Nutzers startet eine 30-Tage-Gnaden­frist, nach der seine PII gescrubbt wird und seine Firewall-Events neben den Request-Logs und Guardrail-Matches desselben Scopes gelöscht werden.

​
Wohin als Nächstes

Verdikte

Was jedes Verdikt im Feed tatsächlich mit dem Aufruf gemacht hat.

Shadow-Mode

Lesen Sie den Feed im „Would-have”-Modus, bevor Sie durchsetzen.

Stages & Surfaces

Die vier Surfaces, die das surface-Feld benennt.

Firewall-Referenz

Die vollständige Policy-, Regel- und API-Referenz.
Für die Bedrohungen, die diese Logs Ihnen helfen, auf frischer Tat zu fangen, siehe Datenexfiltration und gefährliche Tool-Calls. Dafür, wie sich die Firewall mit Prompt-/Response-Text-Screening paart, siehe Firewall + Guardrails.