Zum Hauptinhalt springen
Statische Firewall-Regeln fangen die Aufrufe ab, die Sie zu benennen wussten. Sie können den Aufruf nicht abfangen, der einzeln erlaubt, aber in der Summe falsch ist — 200 db.query-Aufrufe um 3 Uhr morgens am Sonntag, ein Agent, der in einer engen Schleife auf ein fehlschlagendes Tool einhämmert, ein Tool-zu-Tool-Sprung, den dieser Workspace noch nie zuvor gemacht hat. Jeder Aufruf besteht jede Regel; das Muster ist das Problem. Die Firewall-Anomalieerkennung ist die Verhaltensebene. Das Gateway lernt die normale Tool-Nutzungsform Ihres Workspaces und bewertet die Live-Aktivität dagegen, wobei es die Abweichungen auf einem Feed sichtbar macht, den jedes Member lesen kann. So bemerken Sie einen kompromittierten Agenten oder eine außer Kontrolle geratene Schleife, ohne vorab eine Regel für eine Form geschrieben zu haben, die Sie nie gesehen hätten. Diese Seite ist das fokussierte Landing für diesen firewall anomaly detection-Feed; der Firewall-Überblick ist die Tiefenreferenz.
Der Anomalie-Feed ist Erkennung, keine Durchsetzung. Er sagt Ihnen, was abweicht — er blockiert nicht. Wenn ein Muster real ist, verwandeln Sie es in eine Regel oder ein ratenbegrenztes Verdikt, sodass das nächste Vorkommnis inline gestoppt wird. Das Lesen des Feeds ist für jedes Member offen; eine Erkenntnis in Policy zu verwandeln ist Developer+.

​
1. Was die Firewall-Anomalieerkennung flaggt

Vier Signalarten, jede an einen anderen Fehlermodus gebunden:
Pro-Tool-Aufrufvolumen, bewertet gegen eine gelernte Hour-of-week-Baseline. Ein Tool feuert rate_spike, wenn seine Anzahl eine absolute Untergrenze überschreitet und relativ zur Baseline für diese Stunde hoch läuft, oder wenn sein Z-Score den Schwellenwert überschreitet. Das Keying auf Hour-of-week (nicht Hour-of-day) bedeutet, dass Dienstag-14:00 mit vergangenen Dienstag-14:00 verglichen wird, sodass legitimer Werktags-Spitzentraffic nicht als Spike gelesen wird, während dasselbe Volumen um 3 Uhr morgens am Sonntag es tut.
Derselbe Hour-of-week-Vergleich, angewendet auf akkumulierte Kosten statt auf die Aufrufanzahl. Ein Tool, dessen Ausgaben weit über seiner gelernten Kostennorm laufen, taucht als burn_spike auf — das Frühwarnsignal für einen Agenten, der teuer ist, bevor er destruktiv wird.
Eine (conversation, tool, arguments)-Gruppe, die sich innerhalb eines kurzen Fensters viele Male wiederholt — ein Agent, der denselben fehlschlagenden Tool-Call erneut ausstellt, statt sich zu erholen. Langsames, legitimes Polling löst es nicht aus; das Signal ist eine enge Schleife.
Ein aufeinanderfolgender tool_a → tool_b-Übergang, für den dieser Workspace keine gelernte Baseline hat. Das erste Mal, dass ein Agent etwa crm.read → http.fetch geht, ist diese Kante neu — genau die Art von Schritt, den eine Datenexfiltrations-Kette nimmt.
Die Anomalieerkennung ergänzt Sequenzregeln. Eine Sequenzregel matcht eine Kette, die Sie im Voraus definiert haben; novel_path flaggt einen Übergang, den Sie nicht definiert haben — so entdecken Sie die Ketten, für die es sich lohnt, eine Sequenzregel zu schreiben.

​
2. Die 14-Tage-Baseline

Der Detektor ist kein fester Schwellenwert — er ist eine gelernte Norm. Für jeden (tool, hour-of-week)-Bucket hält das Gateway eine gleitende erwartete Aufrufanzahl und Kosten, aus einem 14-Tage-Rückblick aufgefüllt (etwa zwei Vorkommnisse jedes Hour-of-week-Buckets — genug, um einen einzelnen abweichenden Tag zu glätten, ohne die Wochenform zu verlieren). novel_path nutzt die parallele Übergangs-Baseline: die gelernte Vorkommnisanzahl für jede tool_a → tool_b-Kante in dieser Hour-of-week. Ein brandneuer Workspace hat noch keine Baseline. Das ist in Ordnung: ohne gelernte Norm fallen die Volumen-Detektoren auf eine absolute Untergrenze zurück, sodass eine offensichtliche Flut auch am Tag eins noch abgefangen wird, während sich die Pro-Stunde-Normen füllen.
SignalWoraus es lernt
rate_spike / burn_spikePro-(tool, hour-of-week)-Anzahl und -Kosten, 14-Tage gleitend.
novel_pathPro-(tool_a → tool_b, hour-of-week)-Übergangsanzahl.
retry_loopKeine Baseline — ein gefensterter Wiederholungs-Schwellenwert auf (conversation, tool, args).
Der Feed meldet nur Tool-Namen, redigierte Token-IDs und Zähler. Eine rohe API-Key-ID erscheint nie — jedes Element trägt einen Einweg-Digest des aufrufenden Tokens, sodass Sie zwei Anomalien voneinander unterscheiden können, ohne dass der Feed je den Key dahinter leakt.

​
3. Eine konkrete Lesart

Angenommen, ein Agent-Key beginnt zu loopen. Ziehen Sie den Feed in der Konsole unter Security → Firewall → Anomalies, oder lesen Sie ihn direkt — jedes Member kann das: 
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
  }
}
Ein retry_loop-Element trägt keine baseline oder z_score (diese Felder bleiben 0 — sie gehören zu den Volumen-/Kosten-Detektoren) und es trägt eine stabile opake id, sodass zwei distinkte Schleifen auf demselben Tool nicht in einer Zeile kollidieren. Ein rate_spike ist das Gegenteil: er meldet eine gelernte baseline und einen z_score und lässt id leer.
$ORCA_SESSION_TOKEN ist Ihr Konsolen-Session-/Access-Token — dieselbe Auth wie jede /api/workspace/firewall/*-Management-Route. Es ist kein Relay-sk-orca-…-Key (die sind nur für /v1/*-Modellaufrufe) und kein Firewall-Gateway-Key. Ein Relay-Key auf dieser Route wird abgewiesen.
Jedes Element benennt das Tool, das redigierte Token, wie viele Aufrufe gefeuert haben, den Z-Score (nur Volumen-/Kosten-Signale) und eine suggested_action (rate_limit, block_tool oder review). Von hier aus handeln Sie: legen Sie eine deny-Regel auf das Tool, validieren Sie seine Argumente, oder öffnen Sie das Events-Log, um genau zu sehen, was der Agent getan hat.

​
4. Den Feed snoozen

Ein bekannter Lasttest oder ein geplanter Backfill wird den Feed aufleuchten lassen. Statt dem Rauschen hinterherzujagen, snoozen Sie ihn — für bis zu 7 Tage: 
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}'
Während ein Snooze aktiv ist, gibt der Feed keine Elemente zurück und meldet snoozed_until; er räumt sich selbst auf, sobald die Deadline verstreicht. Die Obergrenze ist ein hartes Limit — ein vertippter oder feindseliger until-Wert weiter draußen wird geklemmt, sodass die Anomalieerkennung nicht unbegrenzt zum Schweigen gebracht werden kann. Das Posten eines vergangenen oder jetzigen until-Werts räumt einen bestehenden Snooze.
Das Lesen des Feeds ist eine Member-Aktion; das Snoozen ist Developer+ — das Stummschalten eines workspace-weiten Sicherheitssignals ist ein Write, kein Read.

​
5. RBAC auf einen Blick

Die Analytics-Surface teilt sich entlang der üblichen Read-/Act-Linie:
AktionRolle
Anomalie-Feed lesenMember
Einstellungen, Policies, Discovered Tools lesenMember
Den Feed snoozenDeveloper+
Events, Runs, Aggregate, TraceDeveloper+
Eine Regel aus einer Erkenntnis verfassenDeveloper+
Die leichteren Aggregate-Ansichten — Einstellungen, Policies und die Discovered-tools-Abdeckungskarte — sind ebenfalls Member-Reads; das zeilenweise Events- und Runs-Detail ist Developer+, weil es Pro-Aufruf-Argumentdaten trägt.

​
6. Vom Signal zur Policy

Der Feed ist der Anfang einer Schleife, nicht das Ende:
1

Das Muster erkennen

Ein novel_path oder rate_spike zeigt eine Form, die Sie nicht erwartet haben. Lesen Sie sie gegen das Events-Log, um zu bestätigen, dass sie real ist und keine Einmaligkeit.
2

Die Regel schreiben

Verwandeln Sie die Erkenntnis in Durchsetzung — einen Block, eine Argument-Klausel, eine Sequenzregel für die Kette, oder eine Kostenobergrenze für den Burn.
3

Sie sicher ausrollen

Landen Sie die Regel zuerst unter Shadow-Mode, sodass Sie ihren Wirkungsradius messen, bevor sie einen einzigen Aufruf blockiert, dann durchsetzen.

​
Wohin als Nächstes

Firewall-Überblick

Die vollständige Anomalieerkennungs-Referenz und der Rest der Policy-Ebene.

Events-Log

Drillen Sie von einer Anomalie zu den exakten Aufrufen dahinter.

Ein Tool blockieren

Verwandeln Sie eine Erkenntnis in eine durchsetzende Regel.

Enforcement-Modi

Wie Erkennung, Audit, Shadow und Durchsetzung zusammenpassen.
Für die Bedrohungen, die diese Signale aufdecken, siehe Datenexfiltration und übermäßige Handlungsmacht.