Zum Hauptinhalt springen
Eine Firewall-Regel matcht einen Tool-Call auf zwei Achsen: welches Tool (ein tool_name_glob) und welche Argumente (args_match-Klauseln über JSONPath-Felder). Diese Seite ist die präzise Grammatik für beide — was ein Pattern matcht, was nicht, und wie jeder Operator Typen erzwingt — sodass sich eine Regel, die Sie in der Konsole verfassen, exakt so verhält, wie Sie sie hier lesen. Der Schlagzeilen-Anwendungsfall: Verwandeln Sie ein stumpfes „block shell.exec” in ein chirurgisches „block shell.exec nur wenn der Befehl wie rm -rf aussieht”. Der Glob wählt die Tool-Familie; die Argument-Operatoren wählen den gefährlichen Aufruf darin.
Dies ist die Syntaxreferenz. Wo diese Klauseln auf einer Regel leben, die Regelreihenfolge und Verdikte, siehe die Firewall-Regeln- Tiefenreferenz. Für die Regelfelder selbst siehe den Firewall-Überblick.

​
1. Wo diese Syntax gilt

Beide Formen werden auf einer Firewall-Regel verfasst, in der Konsole unter /console/firewall (Schreibvorgänge erfordern Developer+). Sie rufen den Matcher nie direkt auf — das Gateway wertet ihn bei jedem Tool-Call gegen die aufgelöste Policy aus. Eine Regel matcht, wenn ihre Surface, ihr tool_name_glob, ihr optionaler Skill-Glob und ihre args_match-Klauseln alle matchen; erster Treffer gewinnt.
Eine Regel mit keinen args_match-Klauseln matcht allein auf dem Tool-Namen-Glob. Fügen Sie Argument-Klauseln nur hinzu, wenn der Tool-Name nicht spezifisch genug ist.

​
2. Tool-Namen-Glob-Grammatik

Das tool_name_glob ist eine bewusst kleine, vorhersehbare Grammatik — kein vollständiges Regex. Patterns werden case-sensitiv gematcht (MCP-Tool-Namen sind konventionell lowercase-mit-Punkten, sodass ein Case-Fold Sie überraschen würde, wenn Sie einen Namen aus dem Discovered-tools-Tab kopieren).
Ein leeres Pattern oder ein blankes * matcht alle Tools. Verwenden Sie es auf einer Catch-all-Regel oder verlassen Sie sich stattdessen auf das default_verdict der Policy.
shell.* matcht shell.exec, shell.read, shell.write. Es matcht nicht das blanke shell (der Punkt ist erforderlich — ein Präfix-Glob deckt nur namespaced Kinder ab).
*.exec matcht das namespaced shell.exec und das blanke, un-namespaced exec (anbieter-native Function-Calls und nicht-namespacing MCP-Server exponieren Tools unter dem blanken Verb, sodass eine Suffix-Regel beide Formen abdeckt). Das Suffix bleibt an einem Punkt oder dem String-Anfang verankert, sodass *.exec nicht shell.execute matcht.
*.shell.* matcht jede <server>.shell.<verb>-Form — local.shell.exec, byo.shell.run. Es erfordert mindestens ein Zeichen auf jeder Seite des Infix, sodass *.shell.* nicht das blanke shell oder .shell. allein matcht. Nur die symmetrische *.X.*-Form wird als Infix behandelt; ein gemischtes Pattern wie foo.*.bar fällt auf Exact-Match durch.
Jedes Pattern, das keine der vier Wildcard-Formen oben ist (einschließlich eines wörtlichen Tool-Namens oder einer fehlerhaften Kombination wie foo.*.bar), wird als exakter, case-sensitiver String verglichen.
Es gibt kein ?-Einzelzeichen-Wildcard, keine Zeichenklassen und kein Mid-Token-* (z. B. sh*l.exec). Ein Pattern, das keine der vier unterstützten Formen ist, wird wörtlich gematcht — sh*l.exec matcht nur ein Tool, das wörtlich sh*l.exec heißt. Verfassen Sie mit den Formen oben, nicht aus Regex-Muskelgedächtnis.

​
3. JSONPath-Argument-Klauseln

args_match ist ein Satz von Klauseln, jede ein {path, op, value}-Tripel. Der path ist ein JSONPath in das Argument-Objekt des Tool-Calls; op ist einer von sieben Operatoren; value ist, womit verglichen wird. Alle Klauseln in einer Regel sind AND-verknüpft — jede Klausel muss matchen, damit die Regel feuert. 
{
  "clauses": [
    {"path": "$.command", "op": "regex", "value": "rm -rf|drop table"},
    {"path": "$.connection", "op": "in", "value": ["prod", "replica"]}
  ]
}

​
Unterstützte JSONPath-Teilmenge

FormMatcht
$.fooEinen Top-Level-Key.
$.foo.barEinen verschachtelten Key.
$.foo[0]Ein Array-Element nach Index.
$.arr[1].kIndex dann Key (Kombinationen der obigen).
Das ist die ganze Teilmenge. Es gibt keine Wildcards ($.*), Filter ($.foo[?(...)]), Slices ($.foo[0:2]) oder rekursiven Abstieg ($..foo).
Fail-closed auf dem Pfad. Wenn der Pfad einer Klausel zu nichts auflöst — der Key fehlt, die Argumente sind kein gültiges JSON oder der Wert hat den falschen Typ für den Operator — wertet diese Klausel zu false aus, die Regel feuert nicht und die Auswertung fällt zur nächsten Regel oder dem Policy-Default durch. Ein fehlerhaftes Argument lehnt nie automatisch ab und lässt die Engine nie abstürzen.

​
4. Argument-Operatoren

Sieben Operatoren, ein geschlossenes Set. Der Konsolen-Validator und die Live-Engine teilen sich exakt dasselbe Vokabular, sodass eine Klausel, die speichert, eine Klausel ist, die läuft.
OperatorVergleichtTypregeln
eqExakte Gleichheit.Typisiert: string↔string, bool↔bool oder number↔number. Gemischte Typen matchen nie.
containsTeilstring-Enthaltensein.Beide Seiten müssen Strings sein; alles andere ist ein Non-Match. Ein leerer Wert matcht jeden String.
regexEin RE2-Pattern (linear-zeit, keine Backreferences) gegen einen String.Wert und aufgelöstes Arg müssen beide Strings sein. Ein ungültiges Pattern deaktiviert die Klausel (matcht nie).
inMitgliedschaft — der Wert gleicht irgendeinem Element einer Liste.Wert muss ein JSON-Array sein; jedes Element vergleicht mit eq-Semantik.
cidr_matchDer aufgelöste Wert ist eine IP innerhalb des gegebenen Netzwerks.Wert ist ein CIDR-String (IPv4 oder IPv6, z. B. 10.0.0.0/8, fd00::/8); das Arg muss als IP parsen.
gtGrößer-als, numerisch.Beide Seiten müssen zu einer Zahl coercen. Ein numerisch aussehender String wird nicht coerced — es ist ein Typ-Mismatch (Non-Match).
ltKleiner-als, numerisch.Dieselbe numerisch-only Regel wie gt.
gt und lt sind strikt numerisch. Wenn ein Tool {"max_rows": "10000"} (einen String) sendet, feuert eine gt 5000-Klausel nicht — der String wird nie coerced. Vergleichen Sie Zahlen gegen Zahlen; verwenden Sie regex oder contains für string-förmige Werte.

​
5. Ein durchgearbeitetes Beispiel

Blockieren Sie einen destruktiven Datenbank-Export, aber nur, wenn er eine Produktionsverbindung über einen Private-Network-Host anvisiert: 
{
  "tool_name_glob": "db.*",
  "args_match": {
    "clauses": [
      {"path": "$.statement", "op": "regex", "value": "(?i)drop|truncate|delete from"},
      {"path": "$.connection.name", "op": "in", "value": ["prod", "prod-replica"]},
      {"path": "$.connection.host_ip", "op": "cidr_match", "value": "10.0.0.0/8"}
    ]
  }
}
Lesen Sie es von oben nach unten: Der Glob db.* scopt die Regel auf die Datenbank-Tool-Familie; die drei Klauseln AND-verknüpfen, sodass das Verdikt (ein deny, sagen wir) nur feuert, wenn das Statement destruktiv ist und die Verbindung eines von zwei benannten Prod-Zielen ist und ihr Host in den privaten 10.0.0.0/8-Bereich fällt. Eine db.query gegen eine Dev-Verbindung auf einer öffentlichen IP segelt unberührt an dieser Regel vorbei.
Beweisen Sie die Klausel, bevor Sie ihr vertrauen: Der Test-Tab auf einer Policy dry-runnt einen Beispiel-Tool-Call und zeigt die gematchte Regel und das Verdikt, persistiert nichts und dispatcht nichts. Siehe Firewall-Observability.

​
6. Egress-(Host- / CIDR-)Regeln

Der cidr_match-Operator oben matcht eine IP, die ein Tool in seinen Argumenten meldet. Das ist verschieden von einer Egress-Surface-Regel, die das ausgehende Ziel auswertet, das ein Tool tatsächlich erreicht, mit einer Host-/CIDR-Allow- oder Deny-Liste — die primäre SSRF- und Datenexfiltrations-Verteidigung. Egress-Regeln verwenden dieselbe CIDR-Notation, leben aber auf der egress-Surface; siehe Firewall-Regeln für das Egress-Listenformat.
Kein Preset liefert CIDR-Egress-Regeln für Sie — die tight-Autonomie-Stufe verweigert die üblichen fetch-förmigen Tool-Namen (http_fetch, fetch_url, web_search, request), nicht Netzwerkbereiche. Verfassen Sie Ihre eigene Host-/CIDR-Deny-Regel, wenn Sie Egress an bestimmte Ziele pinnen müssen.

​
7. Schnellreferenz

Glob-Formen

* alle · foo.* Präfix · *.exec Suffix (+ blankes Verb) · *.X.* Infix · alles andere exakt. Case-sensitiv.

JSONPath

$.foo · $.foo.bar · $.foo[0] · $.arr[1].k. Keine Wildcards, Filter, Slices oder rekursiver Abstieg.

String-Ops

eq (typisiert) · contains (Teilstring) · regex (RE2) · in (Listen-Mitgliedschaft).

Numerische & Netzwerk-Ops

gt / lt (nur numerisch, keine String-Coercion) · cidr_match (IPv4/IPv6 im Bereich).

​
Verwandt

Firewall-Regeln

Das vollständige Regelmodell — Surfaces, Reihenfolge, Sanitizer, Sequenzen und Egress-Listen.

Gefährliche Tool-Calls

Die Bedrohung, gegen die diese Klauseln verteidigen, und wie man eine Regel darauf scopt.

Verdikt-Glossar

Was allow, audit, deny, sanitize und der Rest tun, sobald eine Regel matcht.

Warum wurde das blockiert?

Verfolgen Sie einen spezifischen Block zurück zu der Regel und Klausel, die gefeuert hat.