Zum Hauptinhalt springen
Ein einzelner Tool-Call kann vollkommen harmlos aussehen. Einen CRM-Datensatz lesen: erlaubt. Ein Export-Tool aufrufen: erlaubt. Einen externen Host treffen: erlaubt. Die Form des Laufs — fünfzig Reads, dann ein Export, dann Egress zu einem Host, den Sie noch nie gesehen haben, um 3 Uhr morgens an einem Sonntag — ist der Angriff. Pro-Aufruf-Verdikte beurteilen jeden Aufruf isoliert und sehen ihn nie. Diese Seite behandelt die zwei Firewall-Mechanismen, die einen Lauf über die Zeit beobachten statt einen Aufruf nach dem anderen: Sequenz-Regeln (eine geordnete Kette, die Sie verfassen) und verhaltensbasierte Anomalieerkennung (Abweichung vom gelernten Normal Ihres Workspaces). Zusammen sind sie das, womit Sie Agent-Angriffsketten-Verhalten erkennen, das keine einzelne Allow/Deny-Regel abfangen kann.
Alles hier wird in der Konsole konfiguriert (Security → Firewall), deren Management-Routen Ihre Session / Ihren Access-Token verwenden — nicht einen Relay-sk-orca-…-Key. Die /v1/*-Aufrufe Ihres Agenten ändern sich nicht.

​
1. Warum Pro-Aufruf-Regeln die Kette übersehen

Die Tool-Globs und Argument-Klauseln der Firewall sind per Design zustandslos und deterministisch — sie entscheiden einen Aufruf, schnell, auf dem heißen Pfad. Genau das wollen Sie für „blockiere shell.exec rm -rf”. Es ist genau falsch für eine langsam schwelende Exfiltration, bei der jeder einzelne Aufruf legal ist. Zwei komplementäre Werkzeuge füllen die Lücke:

Sequenz-Regeln

Eine Regel, die Sie verfassen und die eine geordnete Kette von Aufrufen innerhalb eines Zeitfensters matcht — „Bulk-Read → Export → Egress”. Sie benennen das Muster.

Anomalieerkennung

Die Firewall lernt die normale Tool-Nutzungsform jedes Workspaces und flaggt Abweichungen — Retry-Loops, nie zuvor gesehene Tool-Pfade und Volumen-/Kosten-Spikes. Keine Regel zu verfassen.

​
2. Sequenz-Regeln: die Angriffskette benennen

Eine sequence-Regel lebt innerhalb einer Firewall-Policy wie jede andere Regel, aber statt eines einzelnen tool_name_glob trägt sie eine geordnete Liste von Steps. Jeder Step ist ein Tool-Glob mit einem optionalen min_count und einem optionalen egress: true; die Steps müssen in Reihenfolge auftreten (Verzahnung mit unverwandten Aufrufen ist in Ordnung), und die ganze Kette muss innerhalb von window_seconds abgeschlossen sein. 
{
  "label": "bulk-read-then-exfil",
  "verdict": "audit",
  "sequence": {
    "window_seconds": 600,
    "steps": [
      { "match": "crm.*",   "min_count": 50 },
      { "match": "*.export" },
      { "match": "*", "egress": true }
    ]
  }
}
Dies feuert, wenn ein Agent 50+ crm.*-Datensätze liest, dann ein beliebiges *.export-Tool aufruft, dann einen beliebigen Egress-Aufruf macht — alles innerhalb von zehn Minuten. Jeder Aufruf für sich würde durchgehen; das Muster ist das Signal.
Eine Sequenz wird auf dem Aufruf ausgewertet, der sie abschließt. Die Inline-Regelschleife überspringt Ketten-Regeln (ein Aufruf kann keine mehrstufige Kette erfüllen); das Matching läuft, wenn ein Aufruf der finale Step einer Kette sein könnte, woraufhin die Firewall die jüngsten Events dieses Prinzipals zieht und die Kette testet. Das verdict, das Sie auf der Regel setzen, ist es, was dann mit dem abschließenden Aufruf passiert: audit zeichnet ihn auf und lässt ihn durch, pending_approval hält ihn für menschliche Überprüfung zurück, und deny blockiert ihn. Eine Kette kann also ihren finalen Aufruf in Echtzeit stoppen — wählen Sie das Verdikt passend. Verwenden Sie audit, wenn Sie nur erkennen und alarmieren wollen; verwenden Sie pending_approval oder deny (oder paaren Sie es mit einer Pro-Aufruf-deny- / Egress-Regel), wenn Sie einen harten Stopp brauchen.
Die vollständige sequence-Feld-Syntax — window_seconds: 0 für keine Zeitschranke, min_count-Defaults, Step-Ordnungssemantik — steht im Regel-Schema. Verfassen Sie Sequenz-Regeln im Regel-Editor der Konsole; das Speichern ist eine Developer+-Aktion.

​
3. Anomalieerkennung: Abweichung vom gelernten Normal

Wo Sequenz-Regeln fragen „ist dieses spezifische Muster passiert”, fragt die Anomalieerkennung „ist irgendetwas an diesem Lauf für diesen Workspace abnormal”. Sie braucht keine Regel — die Firewall baut eine Baseline aus Ihrem eigenen Traffic und bewertet Live-Aktivität dagegen. Vier Arten tauchen auf:
Pro-(Tool, Key)-Aufrufvolumen, bewertet gegen die gelernte Baseline für diese Hour-of-week. Eine Zeile taucht auf, wenn der Zähler einen absoluten Boden räumt und relativ zur Baseline hoch läuft, oder wenn sein z-Score die statistische Schwelle überquert. So sticht „100 db.query-Aufrufe um 3 Uhr morgens am Sonntag” heraus, obwohl ein Dienstag-14-Uhr-Burst derselben Größe es nicht täte.
Dieselbe Idee auf Ausgaben angewandt: ein Tool, das ein Vielfaches seiner gelernten Baseline-Kosten für diese Hour-of-week verbrennt. Die Denial-of-Wallet-Frühwarnung — paaren Sie sie mit einer cap_cost-Regel, um eine harte Obergrenze durchzusetzen.
Eine (conversation, tool, arguments)-Gruppe, die sich viele Male in einem engen Fenster wiederholt — ein Agent, der festhängt und dasselbe fehlschlagende Tool mit denselben Argumenten immer wieder aufruft, statt langsamen legitimen Pollings.
Ein tool_a → tool_b-Übergang, den dieser Workspace noch nie zuvor gemacht hat. Das erste Mal, dass ein Agent von read_file direkt zu http_fetch geht, leuchtet diese Kante auf, selbst wenn beide Tools einzeln erlaubt sind.

​
Die Hour-of-week-Baseline

Die Baseline ist ein 14-tägiger gleitender Durchschnitt, gebucketet nach Hour of week (weekday × 24 + hour), sodass Dienstag-14:00 spezifisch gegen die vergangene Dienstag-14:00-Historie verglichen wird — nicht ein flacher All-time-Mittelwert, der Ihren echten täglichen und wöchentlichen Rhythmus auswaschen würde. Ein brandneuer Workspace ohne gelernte Norm fängt trotzdem eine offensichtliche Flut über einen absoluten Boden ab, sodass Sie ab Tag eins geschützt sind.
Der Feed meldet Tool-Namen, redigierte Key-IDs, Zähler und einen z-Score — niemals rohes Key-Material. Jede Anomalie trägt eine vorgeschlagene Abhilfe (rate_limit, review oder block_tool), sodass der nächste Schritt ein Klick ist, keine Vermutung.

​
4. Ein konkreter Durchgang

Angenommen, ein kompromittierter Prompt treibt einen Ihrer Agenten in eine enge Fehlerschleife und sondiert dann einen Export-Pfad, den er nie berührt hat. Das sehen Sie — keine Regel im Voraus verfasst:
1

Der Agent verhält sich daneben

Injizierte Anweisungen drängen den Agenten dazu, ein fehlschlagendes db.query mit identischen Argumenten erneut zu versuchen, dann report.export gefolgt von einem ausgehenden Fetch aufzurufen — ein Pfad, den dieser Workspace nie gelaufen ist.
2

Den Anomalie-Feed öffnen

In Security → Firewall → Anomalies taucht der Lauf mit einem retry_loop auf db.query und einem novel_path auf der report.export → http_fetch-Kante auf. Den Feed zu lesen ist eine Member-Aktion — jeder im Team kann triagieren.
3

Im Events-Trace bestätigen

Klicken Sie durch zum Events-Log und zur Run-Analytics, um die genaue Aufrufsequenz zu sehen, korreliert mit dem Agentenlauf und der Konversation. Der Anomalie-Feed ist Member-lesbar, aber der Events-Log und der Run-Trace tragen Tool-Call-Provenienz und sind Developer+.
4

Den Befund in eine Regel umwandeln

Jetzt, da Sie die Kette gesehen haben, kodieren Sie sie: ein deny auf dem gefährlichen Export, eine Egress-Allow-List auf dem Fetch oder eine Sequenz-Regel, die das ganze Muster beim nächsten Mal auditiert. Anomalieerkennung findet das Unbekannte; eine Regel pinnt das Bekannte.
Wenn der Feed während Ihres Tunings rauschig ist — etwa ein legitimer Batch-Job, der jeden Sonntag wirklich spiked — snoozen Sie den Anomalie-Feed für bis zu 7 Tage, während Sie ermitteln. Snoozing ist eine Developer+-Aktion; das Fenster ist server-geklemmt, sodass die Erkennung immer von allein zurückkommt.

​
5. Sequenz-Regeln vs. Anomalieerkennung

Sie lösen benachbarte Probleme — wählen Sie das, das zu Ihrem Wissensstand passt:
Sequenz-RegelAnomalieerkennung
Sie verfassenDie exakte KetteNichts — sie lernt
FängtEin bekanntes mehrstufiges MusterDas Unbekannte / Abnormale
HandeltWendet das Verdikt der Regel auf den abschließenden Aufruf an (audit / pending_approval / deny)Taucht auf dem Feed auf
Ein reifer Workspace betreibt beide: Anomalieerkennung ist das Radar, das Ketten auftauchen lässt, die Sie nicht antizipiert haben — nur auftauchend, nie blockierend; Sequenz-Regeln sind, wie Sie die kodifizieren, die Sie haben, sodass sie gelabelt, verfolgt und (mit einem pending_approval- oder deny-Verdikt) in der Lage sind, den abschließenden Aufruf zu gaten. Für einen harten Stopp auf einem einzelnen Aufruf unabhängig von jeder Kette greifen Sie zu einem Pro-Aufruf-Verdikt.

​
6. RBAC & die Routen hinter dem Feed

Der Anomalie-Feed und die Sequenz-Regeln sitzen unter den Workspace-Firewall-Management-Routen — Ihr Session- / Access-Token, nie ein Relay-Key:
Methode & PfadRolleZweck
GET /api/workspace/firewall/anomaliesMemberDen Anomalie-Feed lesen (?window=).
POST /api/workspace/firewall/anomalies/snoozeDeveloper+Den Feed snoozen ({until}, auf 7 Tage geklemmt).
POST /api/workspace/firewall/rulesDeveloper+Eine Sequenz- (oder beliebige) Regel unter einer Policy erstellen.
POST /api/workspace/firewall/testDeveloper+Eine Policy gegen einen Beispielaufruf dry-runnen, bevor Sie sich darauf verlassen.
Lesezugriffe auf den Feed sind für jedes Member offen, sodass das ganze Team triagieren kann; Regeln zu verfassen und den Feed zu snoozen sind Developer+-Writes, konsistent mit dem Rest des Firewall-RBAC-Modells.

​
Wohin als Nächstes

Regel-Schema

Das vollständige sequence-Feld — Steps, min_count, window_seconds und jedes andere Regel-Feld.

Events-Log

Wo gematchte Sequenzen und Anomalien landen — filtern nach Run, Surface und Verdikt.

Kosten deckeln

Ein burn_spike-Signal in eine harte Pro-Lauf-Ausgabenobergrenze verwandeln.

Egress-Kontrolle

Den finalen Exfiltrations-Step einer Kette an der Netzwerkgrenze stoppen.
Für die Angreifer-Playbooks, die diese Mechanismen kontern, siehe Verkettete Angriffe, Datenexfiltration und Übermäßige Handlungsmacht. Für die tiefe Firewall-Referenz siehe Firewall-Regeln.