Zum Hauptinhalt springen
Ein Tool zu benennen und zu verweigern ist grob: Es killt das Tool für jeden Aufruf. Meistens ist das Tool in Ordnung und eine Form des Aufrufs ist das Problem — shell.exec ist in Ordnung, bis der Befehl rm -rf lautet, db.query ist in Ordnung, bis es prod trifft. Genau diese Unterscheidung drückt eine Argument-Klausel aus: ein jsonpath-Tool-Argument-Prädikat, das auf die Werte matcht, die ein Agent übergibt, sodass das Verdikt nur auf dem gefährlichen Aufruf feuert und den Rest in Ruhe lässt. Diese Seite ist ein Kochbuch — eine Handvoll Copy-Paste-args_match_json-Rezepte für die häufigsten Fälle. Für die vollständige Klausel-Grammatik, die Operator-Tabelle und die Fail-closed-Semantik siehe Argumente validieren und die Regel-Schema-Referenz.

​
1. Wie eine jsonpath-Tool-Argument-Klausel funktioniert

Das args_match_json einer Regel ist ein JSON-kodierter String, der eine Menge von Klauseln trägt, allesamt UND-verknüpft. Der dekodierte Wert ist ein Objekt, {"clauses": [ … ]}, wobei jede Klausel ein { path, op, value }-Tripel ist:
  • path — eine kleine JSONPath-Teilmenge über dem Argument-Objekt des Tools: $.command, $.foo.bar, $.items[0] oder $ für das gesamte Objekt. Keine Wildcards, Filter, Slices oder rekursiver Abstieg.
  • op — einer aus einer geschlossenen Menge: eq, contains, regex, in, cidr_match, gt, lt.
  • value — das Literal, mit dem verglichen wird (ein String, eine Zahl, ein Bool oder — für in — ein JSON-Array).
Eine Klausel wird mit dem tool_name_glob der Regel UND-verknüpft: Die Regel feuert nur, wenn der Tool-Name matcht und jede Klausel hält. Lassen Sie args_match_json ganz weg (oder lassen Sie es ein leeres "{}"), und die Regel matcht allein auf dem Glob.
Klauseln failen closed — die Regel, nicht der Request. Wenn ein Pfad nicht auflöst, die Argumente fehlerhaft sind oder ein Wert den falschen Typ hat, wertet die Klausel zu false aus, und die Regel feuert einfach nicht — der Aufruf fällt auf die nächste Regel oder das Default-Verdikt durch. Eine kaputte Klausel verweigert nie automatisch. Schreiben Sie Ihre harte Rückfalllinie als einfaches Glob-deny, nicht als Klausel, auf deren bestimmtes Failen Sie sich verlassen.

​
2. Rezept: einen destruktiven Befehl blockieren

Der kanonische Fall. shell.exec im Allgemeinen erlauben, es nur dann verweigern, wenn der Befehl destruktiv aussieht. Eine regex-Klausel auf $.command erledigt das: 
{
  "label": "block destructive shell commands",
  "tool_name_glob": "*.exec",
  "verdict": "deny",
  "args_match_json": "{\"clauses\":[{\"path\":\"$.command\",\"op\":\"regex\",\"value\":\"rm -rf|mkfs|dd if=\"}]}"
}
Regexes sind Go-RE2 — lineare Zeit, keine Backreferences, kein katastrophales Backtracking — sodass sie sicher auf jedem Tool-Call laufen können. Ein nicht-stringiges $.command (oder ein fehlendes) matcht nie, sodass ein fehlerhafter Aufruf durchfällt, statt fälschlich blockiert zu werden.
Bevorzugen Sie contains gegenüber regex, wenn Sie einen festen Teilstring matchen — es ist einfacher zu lesen und kann nicht von einem un-escapeten Metazeichen aus der Bahn geworfen werden. Greifen Sie zu regex nur, wenn Sie wirklich Alternation oder Anker brauchen.

​
3. Rezept: ein Tool gegen eine benannte Umgebung verweigern

db.query laufen lassen, aber nur gegen sichere Verbindungen — es verweigern, wenn das Ziel prod oder ein replica ist. Der in-Operator matcht den aufgelösten Wert gegen ein beliebiges Element eines JSON-Arrays: 
{
  "label": "no agent queries against prod",
  "tool_name_glob": "db.query",
  "verdict": "deny",
  "args_match_json": "{\"clauses\":[{\"path\":\"$.connection\",\"op\":\"in\",\"value\":[\"prod\",\"replica\"]}]}"
}
Der in-Wert muss ein JSON-Array sein — ein Nicht-Array wird abgelehnt, wenn Sie die Regel speichern. Elemente vergleichen sich mit skalarer Gleichheit, sodass Zahlen und Strings jeweils ihren eigenen Typ matchen.

​
4. Rezept: ein Ziel mit privater IP oder Metadaten verweigern

Wenn ein Tool eine Ziel-IP als Argument nimmt, testet cidr_match, ob sie in ein CIDR fällt — die SSRF-Form von „ein Agent, der 10.x oder die Cloud-Metadaten-Adresse abruft”: 
{
  "label": "deny tool calls aimed at RFC-1918",
  "tool_name_glob": "*",
  "verdict": "deny",
  "args_match_json": "{\"clauses\":[{\"path\":\"$.target_ip\",\"op\":\"cidr_match\",\"value\":\"10.0.0.0/8\"}]}"
}
Der Argument-Wert muss als IP-Literal parsen, das im CIDR liegt; ein Hostname oder ein Nicht-IP-String matcht nie.
cidr_match inspiziert nur einen Wert, der bereits in den Tool-Argumenten steht. Um das Ziel zu steuern, das ein Tool tatsächlich auf der Netzwerkebene erreicht — Host/CIDR-Allow- und Deny-Listen — verwenden Sie stattdessen eine dedizierte Egress-Regel auf der egress-Surface. Die beiden sind komplementär: Argument-Inspektion auf dem Weg hinein, Egress-Kontrolle auf dem Weg hinaus.

​
5. Rezept: ein numerisches Argument deckeln

gt und lt vergleichen Zahlen. Verwenden Sie sie, um eine absurde Batch-Größe, ein überdimensioniertes Limit oder einen außer Kontrolle geratenen Zähler abzulehnen — hier: ein Bulk-Delete verweigern, das auf mehr als 100 Zeilen abzielt: 
{
  "label": "block large bulk deletes",
  "tool_name_glob": "*.bulk_delete",
  "verdict": "deny",
  "args_match_json": "{\"clauses\":[{\"path\":\"$.count\",\"op\":\"gt\",\"value\":100}]}"
}
Beide Seiten müssen Zahlen sein — ein numerisch aussehender String wie "500" ist eine Typabweichung und matcht nicht, sodass die Regel nicht auf einem stringig-typisierten Argument feuert. Halten Sie das Argument numerisch, oder normalisieren Sie es, bevor das Tool es sieht.

​
6. Rezept: Klauseln kombinieren (UND)

Alle Klauseln in einer Regel sind UND-verknüpft, sodass Sie ein Verdikt auf einen sehr spezifischen Aufruf verengen können — zum Beispiel shell.exec nur dann verweigern, wenn es ein destruktiver Befehl ist und er auf einen prod-Host gerichtet ist: 
{
  "label": "destructive shell on a prod host",
  "tool_name_glob": "*.exec",
  "verdict": "deny",
  "args_match_json": "{\"clauses\":[{\"path\":\"$.command\",\"op\":\"regex\",\"value\":\"rm -rf|drop table\"},{\"path\":\"$.host\",\"op\":\"in\",\"value\":[\"db-prod-1\",\"db-prod-2\"]}]}"
}
Brauchen Sie stattdessen ein ODER? Es gibt kein ODER innerhalb eines einzelnen args_match_json — verfassen Sie zwei Regeln (oder zwei Globs) mit unterschiedlichen Prioritäten. Die Engine durchläuft Regeln in Prioritätsreihenfolge, und der erste Treffer gewinnt, also stellen Sie die engen Regeln voran. Siehe Regel-Priorität.

​
7. Das Verdikt für die gematchte Form wählen

Eine Klausel entscheidet, welche Aufrufe matchen; das verdict der Regel entscheidet, was passiert. deny ist der Kochbuch-Default, aber dieselbe Klausel kann ein sanfteres Verdikt tragen:
Wenn das gematchte Argument ein Secret oder PII statt einer gefährlichen Anweisung trägt, redigiert sanitize die gematchten Teilstrings aus den Tool-Argumenten und leitet den bereinigten Aufruf weiter. Es redigiert nur Argumente — niemals den Inhalt, den ein Tool zurückgibt. Siehe Antworten bereinigen.
Genau die riskante Form zur Überprüfung zurückhalten, statt sie rundheraus zu blockieren: Ein Prüfer genehmigt oder lehnt out-of-band ab, und der Agent reicht den genehmigten Aufruf einmal erneut ein. Siehe Freigaben.
Setzen Sie das Verdikt auf audit, um den gematchten Aufruf aufzuzeichnen, ohne zu blockieren, während Sie die Klausel tunen. Paaren Sie es mit dem Shadow-Mode, um ein deny gegen Live-Traffic zu messen, bevor es etwas verändert.

​
8. Die Klausel testen, bevor Sie sich auf sie verlassen

Der Test-Tab der Konsole macht einen Dry-Run einer Policy gegen einen Beispiel-Tool-Call und gibt das Verdikt, die gematchte Regel und den Grund zurück — nichts wird dispatcht, nichts wird persistiert. Fügen Sie ein realistisches Argument-Objekt ein und bestätigen Sie, dass die Klausel auf den Aufrufen feuert, die Sie meinen, und nur auf diesen, da eine Klausel, die einen Wert nicht auflösen kann, stillschweigend nicht feuert. Siehe Regeln testen.
Klauseln werden strikt beim Speichern validiert — unbekannte Operatoren, fehlerhafte Pfade, ein nicht-Array-in-Wert, ein nicht-kompilierbarer Regex und ungültige CIDRs werden allesamt abgelehnt, sodass eine fehlerhafte Klausel gar nicht erst persistiert werden kann.

​
9. Wer Argument-Klauseln verfassen kann

All dies läuft in der Konsole unter Ihrer Session (/api/workspace/firewall/*):
AktionRolle
Policies, Presets, Discovered Tools lesenMember
Regeln erstellen / bearbeiten / löschenDeveloper+
Test-Sandbox (Dry-Run einer Policy)Developer+
Events und Run-Aggregate lesenDeveloper+
Eine Argument-Klausel zu verfassen oder zu ändern ist ein Developer+-Write. Die Test-Sandbox ist ebenfalls Developer+ — sie kann gegen eine Entwurfs-Policy vorschauen, und ihr Verdikt-Trace exponiert Policy-Namen und Regel-Labels, sodass sie auf der Schreibseite der Linie sitzt, nicht auf der Leseseite.

​
Verwandt

Argumente validieren

Der Argument-Matching-Use-Case in voller Länge.

Tools blockieren

Ein ganzes Tool nach Namen verweigern — keine Klausel nötig.

Egress-Kontrolle

Ausgehende Host- / IP- / CIDR-Ziele steuern.

Regel-Schema

Jedes Feld, das eine Regel tragen kann.

Regel-Priorität

Erster Treffer gewinnt — eng vor breit ordnen.

Gefährliche Tool-Calls

Die Bedrohung, die diese Rezepte adressieren.