Zum Hauptinhalt springen
Jede Firewall-Regel beginnt damit, die Frage zu beantworten auf welche Tool-Calls treffe ich zu? Die erste Hälfte dieser Antwort ist ein Tool-Namen-Glob — das tool_name_glob-Feld auf einer Regel. Es ist eine bewusst kleine, case-sensitive Grammatik (keine Regex, kein Backtracking), sodass eine Regel sich genauso liest, wie Sie einen Tool-Namen aus dem Discovered-Tools-Tab tippen würden, und das Matching auf dem heißen Relay-Pfad linear in der Zeit bleibt. Diese Seite ist die fokussierte Grammatik-Referenz für dieses eine Feld. Wo ein Glob innerhalb einer vollständigen Regel sitzt — die Surface, Argument-Klauseln, Egress-Listen, das Verdikt — siehe Regel-Schema und die tiefe Engine-Referenz in Firewall-Regeln.

​
1. Warum ein Tool-Namen-Glob statt Regex

Tools sind konventionell namespaced als server.tool oder category.action (shell.exec, db.query, community.http_fetch). Ein Glob lässt eine Regel eine ganze Familie fangen — shell.* für jedes Shell-Verb, *.delete für ein Verb über Server hinweg — ohne die Foot-Guns einer Regex auf einem Pfad, der bei jedem Tool-Call läuft.
Die Grammatik ist absichtlich winzig. Das Matching ist case-sensitive — MCP-Tool-Namen sind konventionell lowercase-mit-Punkten, sodass eine Case-Faltung einen Autor überraschen würde, der einen Namen direkt aus der Discovered-Tools-Ansicht kopiert und einfügt. Es gibt kein katastrophales Backtracking, weil keine Regex-Engine dahintersteht; jedes Muster unten ist eine Handvoll String-Operationen.

​
2. Die fünf Muster-Formen

Ein Tool-Namen-Glob ist genau eine dieser Formen. Alles, was nicht in die Wildcard-Formen passt, wird als Literal, exakter Match behandelt.
MusterFormMatcht
"" oder *beliebigJeden Tool-Call.
foo.*Präfixfoo.bar, foo.exec — nicht das bloße foo.
*.execSuffixshell.exec, db.exec, und das bloße exec.
*.shell.*Infixlocal.shell.exec, byo.shell.run.
shell.execexaktNur den Literal-String shell.exec.
Lesen Sie die nächsten Abschnitte für die eine Kante in jeder Form, über die Leute stolpern.

​
3. Präfix — foo.*

Matcht jedes Tool, dessen Name mit foo. beginnt und mindestens ein weiteres Zeichen nach dem Punkt hat.

Matcht

shell.exec, shell.run, shell.rm für das Muster shell.*

Matcht nicht

das bloße shell (das Präfix erfordert den nachgestellten Punkt und etwas danach)
Verwenden Sie einen Präfix-Glob, um einen ganzen Server oder eine ganze Kategorie auf einmal zu steuern — ein shell.*-Deny deckt jedes Shell-Verb ab, das ein Server später hinzufügen könnte.

​
4. Suffix — *.exec

Matcht jedes Tool, dessen Name mit .exec endet, an einem Punkt verankert — und matcht auch das bloße, nicht-namespaced Verb exec für sich.
Der Bloßes-Verb-Match ist gewollt. Provider-native Function-Calls und MCP-Server, die nicht namespacen, exponieren ein Tool unter seinem bloßen Verb (nur exec, nicht shell.exec). Eine *.exec-Regel deckt beide Formen ab, sodass ein nicht-namespacendes Tool nicht stillschweigend verfehlt wird.
Das Suffix bleibt verankert — es matcht kein partielles Wort:
Mustershell.execbloßes execshell.execute
*.execmatchtmatchtkein Match
*.execute wäre für shell.execute nötig; das Suffix feuert nur an einer Punkt-Grenze oder am Anfang des Strings, nie mitten im Wort.

​
5. Infix — *.shell.*

Matcht jeden Tool-Namen, der .shell. als Infix enthält, mit mindestens einem Zeichen auf jeder Seite. So deckt eine Regel ein Verb ab, wo immer ein BYO-MCP-Server es zufällig namespaced. 
{
  "label": "gate every shell tool, any server",
  "tool_name_glob": "*.shell.*",
  "verdict": "deny"
}
Diese Regel matcht local.shell.exec, byo.shell.run und jede andere <server>.shell.<verb>-Form. Sie matcht nicht das bloße shell oder ein bloßes .shell. mit nichts drumherum — das Zeichen-auf-jeder-Seite-Erfordernis hält den Infix ehrlich.
Die Infix-Form ist nur die symmetrische *.X.*-Form. Ein Muster mit einem Stern in der Mitte — foo.*.bar — ist kein Infix-Glob; es fällt durch zu einem exakten String-Match (es matcht nur ein Tool, das wörtlich foo.*.bar heißt, das nicht existieren wird). Um „beginnt mit foo., endet mit .bar” zu matchen, brauchen Sie zwei Regeln oder eine Argument-Klausel, nicht einen Glob.

​
6. Exakt — shell.exec

Alles, was keine der obigen Wildcard-Formen ist, ist ein Literal-String-Match. shell.exec matcht shell.exec und nichts sonst. Das ist die richtige Wahl, wenn Sie ein spezifisches Tool benennen wollen — paaren Sie es mit einer Argument-Klausel, um weiter einzugrenzen („blockiere shell.exec nur, wenn der Befehl rm -rf ist”).

​
7. Ein konkretes Beispiel

Angenommen, Sie wollen jedes destruktive Shell-Verb ablehnen, ungeachtet dessen, wie ein MCP-Server es namespaced, während Sie alles andere auditieren lassen. Im Konsolen-Regel-Editor (Schreibvorgänge erfordern Developer+) ist die Match-Hälfte der Regel ein einzelner Infix-Glob: 
{
  "label": "deny shell across servers",
  "stage": "response",
  "tool_name_glob": "*.shell.*",
  "verdict": "deny"
}
Hängen Sie einen Key an die Policy an (firewall_policy_id auf dem Key), und die Regel fängt nun local.shell.exec, byo.shell.run und acme.shell.rm — drei Server, ein Glob. Wollen Sie bestätigen, dass sie auf das feuert, was Sie erwarten, bevor Sie sich darauf verlassen? Verwenden Sie Regeln testen — es gibt das Verdikt, die gematchte Regel und den Grund zurück, ohne irgendetwas zu dispatchen.
Ein Glob grenzt ein, welches Tool. Um mit welchen Argumenten einzugrenzen, UND-verknüpfen Sie eine Argument-Klausel auf dieselbe Regel; um ein Tool nur zu steuern, wenn ein bestimmter Skill es besitzt, fügen Sie einen Skill-Namen-Glob hinzu (dieselbe Grammatik, gematcht gegen den besitzenden Skill). Beide sind in Firewall-Regeln behandelt.

​
8. Schnellreferenz

Ja. *.exec matcht shell.exec, db.exec und das bloße, nicht-namespaced exec. Präfix-Globs (foo.*) matchen nicht den bloßen Namespace foo — nur Namen mit etwas nach dem Punkt.
Nein. Die einzige Wildcard-in-der-Mitte-Form, die die Engine versteht, ist der symmetrische Infix *.X.*. foo.*.bar fällt durch zu einem exakten Literal-Match. Verwenden Sie stattdessen zwei Regeln oder eine Argument-Klausel.
Ja. Shell.Exec und shell.exec sind verschiedene Tools. Kopieren Sie Namen wörtlich aus dem Discovered-Tools-Tab.
Jede Form, die keine der fünf obigen ist, wird als exakter Match behandelt — sie matcht einfach keinen echten Tool-Namen, sodass die Regel nie feuert, statt etwas Unerwartetes zu matchen. Die Konsole validiert Regeln beim Speichern.

​
Verwandt

Tool-Allow-Listing

Verwenden Sie Globs, um ein bekanntes Set zu erlauben und den Rest abzulehnen.

Argumente validieren

UND-verknüpfen Sie eine JSONPath-Argument-Klausel auf einen Glob.

Regel-Schema

Jedes Feld einer Regel, an einem Ort.
Für die vollständige Matching-Sprache — Verdikte, Surfaces, Egress-Listen und Sequenzen — siehe Firewall-Regeln. Neu auf der Ebene? Starten Sie beim Firewall-Überblick.