Zum Hauptinhalt springen
Das Allow-Listing eines Tools beantwortet, welches Tool ein Agent aufrufen darf. Es kann nicht beantworten, mit welchen Argumenten. shell.exec ist in Ordnung für ls; es ist eine Katastrophe für rm -rf /. db.query ist in Ordnung gegen ein Replikat; gegen prod ist es ein Risiko. Der Unterschied lebt in den Argumenten, und eine Tool-Namen-Regel kann ihn nicht sehen. Die Argument-Klauseln der Firewall (args_match_json) schließen diese Lücke. Sie inspizieren die konkreten Argumente, die das Modell für einen Tool-Call gewählt hat, und entscheiden das Verdikt aus ihren Werten — sodass Sie ein Tool breit erlauben können, während Sie die eine gefährliche Form verweigern, die es annehmen kann. Diese Seite ist der fokussierte Leitfaden zum Verfassen dieser Klauseln; für das vollständige Regel-Vokabular siehe Firewall-Regeln, und für das Policy-Modell darum herum Firewall.
Argument-Werte existieren erst, sobald das Modell gewählt hat, wie ein Tool aufzurufen ist, daher gehören Argument-Klauseln auf die Stages response und mcp (Stages). Auf inbound — wo der Agent nur Tool-Definitionen anbietet — gibt es keine Argumente zur Aufrufzeit, die geprüft werden könnten.

​
1. Wann Tool-Call-Argumente zu validieren sind

Greifen Sie zu einer Argument-Klausel, wann immer ein Tool im Allgemeinen sicher, aber in einer bestimmten Form gefährlich ist:

Destruktive Befehle

shell.exec erlauben, aber verweigern, wenn der Befehl auf rm -rf, mkfs oder dd if= matcht.

Produktions-Blast-Radius

db.query erlauben, aber verweigern (oder zur Freigabe zurückhalten), wenn das Verbindungsziel prod ist.

Interne Ziele

Ein Fetch-Tool erlauben, aber verweigern, wenn sein url/ip-Argument in einen RFC-1918-Bereich oder die Cloud-Metadaten-IP fällt.

Überdimensionierte Operationen

Ein Bulk-Tool erlauben, aber verweigern, wenn ein limit- oder count-Argument eine numerische Obergrenze überschreitet.
Die Regel matcht weiterhin zuerst auf den Tool-Namen; die Klauseln verengen sie von welches Tool zu welcher Aufruf.

​
2. Die Form eines Klauselsatzes

args_match_json ist ein JSON-kodierter String, dessen dekodierter Wert ein Objekt ist, das eine Liste von clauses hält. Jede Klausel ist ein { path, op, value }-Tripel, und alle Klauseln sind UND-verknüpft — die Regel feuert nur, wenn jede Klausel wahr ist. Dekodiert sieht der Wert so aus: 
{
  "clauses": [
    { "path": "$.command",    "op": "regex",      "value": "rm -rf|drop table" },
    { "path": "$.connection", "op": "in",         "value": ["prod", "replica"] },
    { "path": "$.ip",         "op": "cidr_match", "value": "10.0.0.0/8" }
  ]
}
In einem Regel-Body trägt das Feld dieses JSON als einen einzelnen escapeten String — z. B. "args_match_json": "{\"clauses\":[{\"path\":\"$.command\",\"op\":\"regex\",\"value\":\"rm -rf\"}]}". Ein leeres oder fehlendes args_match_json ist leer-wahr — die Regel matcht allein auf ihrem Tool-Namen-Glob, genau wie es eine reine Namensregel tut.

​
3. Operatoren

Sieben Operatoren bilden das geschlossene Vokabular. Die Konsole validiert den Operator und seine Wertform, wenn Sie speichern, sodass eine fehlerhafte Klausel niemals persistiert wird.
OperatorMatcht, wenn
eqSkalare Gleichheit (Zahlen werden numerisch verglichen; eine Typabweichung ist kein Match).
containsTeilstring — beide Operanden müssen Strings sein.
regexEin Go-RE2-Muster matcht den String-Wert (lineare Zeit, keine Backreferences).
inDer Wert ist ein Element des gegebenen JSON-Arrays.
cidr_matchDie String-IP fällt in das gegebene CIDR.
gt / ltNumerisch größer-als / kleiner-als (Strings werden nicht koerziert).

​
4. Pfad-Syntax

Der path einer Klausel ist eine kleine JSONPath-Teilmenge über dem Argument-Objekt des Tools:
Liest ein Top-Level- oder verschachteltes Objektfeld nach Namen.
Indiziert in ein Array, optional weiter in die Felder des Elements.
Matcht gegen den gesamten Argument-Blob (nützlich mit contains oder regex für einen groben Scan).
Es gibt keine Wildcards, Filter, Slices oder rekursiven Abstieg — die Grammatik ist bewusst klein gehalten, damit das Matching auf dem heißen Pfad lineare Zeit behält und vorhersehbar bleibt.

​
5. Ein durchgearbeitetes Beispiel

Sie lassen Ihre Agenten shell.exec frei ausführen, aber ein rekursives Force-Delete sollte die Shell nie erreichen. Verfassen Sie eine response-Stage-Regel, die shell.exec nur dann verweigert, wenn das Befehlsargument destruktiv aussieht.
1

Den Regel-Editor öffnen

Öffnen Sie in der Konsole die Firewall-Policy, die an den Key Ihres Agenten gebunden ist (oder den Workspace-Default), und fügen Sie eine Regel hinzu. Policies zu bearbeiten ist eine Developer+-Aktion — Members können Policies lesen, aber nicht schreiben.
2

Das Tool auf der response-Stage matchen

Setzen Sie die Stage auf response und das Tool-Glob auf shell.exec. Die response-Stage trägt die vom Modell gewählten Argumente, die die Klausel benötigt.
3

Die Argument-Klausel hinzufügen

Fügen Sie eine regex-Klausel auf $.command hinzu und setzen Sie dann das Verdikt auf deny:
{
  "stage": "response",
  "tool_name_glob": "shell.exec",
  "verdict": "deny",
  "args_match_json": "{\"clauses\":[{\"path\":\"$.command\",\"op\":\"regex\",\"value\":\"rm\\\\s+-rf|mkfs|dd\\\\s+if=\"}]}"
}
args_match_json ist ein JSON-kodierter String; sein dekodierter Wert ist das in §2 gezeigte Objekt { "clauses": [ … ] }.
4

Vor dem Verlassen darauf einen Dry-Run machen

Verwenden Sie den Test-Tab, um die Regel gegen einen Beispiel-shell.exec-Aufruf auszuwerten. Er gibt das Verdikt, die gematchte Regel und den Grund zurück — nichts wird dispatcht und nichts wird persistiert.
Jetzt fließt shell.exec mit "command": "ls -la" wie zuvor durch, während "command": "rm -rf /var" verweigert wird. Ein deny auf response lässt das Modell einen Tool-Fehler sehen und reagieren — ein anderes Tool wählen, den Nutzer fragen oder anhalten — statt abzustürzen.
Möchten Sie den Aufruf erlauben, aber einen geleakten Wert herausstreichen, statt ihn zu blockieren? Tauschen Sie das Verdikt auf sanitize. Sanitize redigiert nicht das, was die Klausel gematcht hat — es lässt einen separaten Redactor (benannte Presets wie openai_key, anthropic_key, ssn_us plus Ihre eigenen Custom-Regexes) über die Argument-Strings laufen, ersetzt jeden Treffer durch ein [redacted:…]-Token und leitet den bereinigten Aufruf weiter. Die args_match_json-Klausel entscheidet weiterhin, ob die Regel feuert; der Sanitizer entscheidet, was bereinigt wird. Siehe Argumente bereinigen. Sanitize redigiert nur Tool-Call-Argumente — niemals den Inhalt, den ein Tool zurückgibt.

​
6. Klauseln failen closed — die Regel, nicht der Request

Wenn eine Klausel nicht ausgewertet werden kann — der Pfad löst nicht auf, die Argumente sind fehlerhaft oder ein Regex / CIDR ist ungültig — wertet die Klausel zu false aus, und die Regel feuert einfach nicht. Der Aufruf fällt auf die nächste Regel oder das default_verdict der Policy durch. Eine kaputte Klausel verweigert nie automatisch und stört nie das Relay.
Weil eine Klausel, die nicht ausgewertet werden kann, ihre Regel nicht matchen lässt, verlassen Sie sich nie darauf, dass eine Klausel auf eine bestimmte Weise failt. Verfassen Sie Ihre „alles Gefährliche abfangen”-Regel als explizites deny mit eigenem Tool-Glob und verwenden Sie Argument-Klauseln, um eine Erlaubnis zu verengen — nicht als Ihre letzte Verteidigungslinie.

​
7. Klauseln mit dem Rest einer Regel kombinieren

Argument-Klauseln stapeln sich mit allem anderen, was eine Regel ausdrückt — sie sind eine UND-verknüpfte Bedingung unter mehreren:
Kombinieren mitEffekt
tool_name_globDie Klausel läuft erst, sobald der Tool-Name matcht — Name zuerst, Argumente danach.
skill_name_globDie Argumente desselben Tools nach besitzendem Skill unterschiedlich steuern (z. B. strenger auf community.*).
verdictKlauseln mit deny, sanitize, pending_approval oder cap_cost paaren, nicht nur mit deny.
Mehrere KlauselnAlle müssen halten — eine regex-Befehlsprüfung mit einer in-Umgebungsprüfung kombinieren, um ein deny eng zu scopen.
Für die präzise Verdikt-Semantik, die jede Paarung erzeugt, siehe Verdikte; für die Auflösung eines zurückgehaltenen Aufrufs siehe Freigaben.

​
8. Wo das hineinpasst

Firewall-Regeln

Die vollständige Regel-Referenz — Globs, Klauseln, Sanitizer, Egress und Sequenzen.

Argument-Kochbuch

Copy-Paste-args_match_json-Rezepte für die gängigen gefährlichen Formen.

Firewall-Stages

Warum Argument-Klauseln auf response und mcp leben, nicht auf inbound.

Tools blockieren

Ein Tool rundheraus verweigern, wenn kein Argument sicher ist.
Für das breitere Bild siehe Gefährliche Tool-Calls und Wie OrcaRouter inspiziert.