Zum Hauptinhalt springen
Eine Firewall-Policy ist eine geordnete Liste von Regeln, und eine Regel ist nur ein kleiner Beutel von Feldern: welche Tool-Calls sie matcht, auf welcher Surface, und was damit zu tun ist. Wenn Sie eine Regel lesen müssen, die jemand anderes geschrieben hat — oder präzise über eine nachdenken, die Sie bauen — wollen Sie die Feldliste an einem Ort. Das ist diese Seite. Sie verfassen Regeln im Konsolen-Regeleditor (Writes erfordern Developer+); der Editor schreibt die strukturierten Felder unten. Diese Seite ist die Feldebenen-Karte; die tiefe Matching-Engine lebt in Firewall-Regeln.

​
1. Das Firewall-Regel-Schema auf einen Blick

Jede Regel trägt dieselben Felder. Nur verdict ist immer erforderlich — alles andere engt ein, was die Regel matcht, oder konfiguriert das gewählte Verdikt, und ein abwesender Matcher ist vakuös wahr.
FeldZweck
priorityAuswertungsreihenfolge — niedrigere läuft zuerst.
verdictDie Aktion, wenn die Regel matcht (erforderlich).
stageDie Surface, auf die zu scopen ist; leer = alle.
tool_name_globGlob auf dem Tool-Namen.
args_match_jsonJSONPath-Argument-Prädikat, als JSON-kodierter String.
egress_jsonHost- / CIDR-Allow-Deny-Liste (Egress-Regeln), als JSON-kodierter String.
sanitize_jsonRedaktions-Config (wenn verdict = sanitize), als JSON-kodierter String.
cap_cost_centsRun-Kosten-Obergrenze in USD-Cent (wenn verdict = cap_cost).
sequence_jsonGeordnetes mehrstufiges Ketten-Prädikat (Sequenzregeln), als JSON-kodierter String.
label / notesMenschlicher Name und Rationale — in Events gezeigt, von der Engine ignoriert.
Eine Regel feuert, wenn alle ihre deklarierten Matcher zugleich halten — die Stage matcht (oder ist leer), das Tool-Glob matcht, die Argument-Klauseln matchen (oder sind abwesend) und der Egress-Scope matcht (nur Egress-Regeln). Die Engine durchläuft Regeln in Prioritätsreihenfolge und der erste Treffer gewinnt; wenn nichts matcht, gilt das default_verdict der Policy.

​
2. priority — Auswertungsreihenfolge

Eine ganzzahlige Ordinalzahl. Niedrigere läuft zuerst; zwei Regeln mit derselben Priorität brechen den Gleichstand über die Regel-ID (Einfügereihenfolge). Setzen Sie Ihre spezifischen Carve-outs über Ihre breiten Catch-alls — ein allow für ein vertrauenswürdiges Tool auf Priorität 10 schlägt ein deny * auf Priorität 100.
Lassen Sie Lücken (10, 20, 30), sodass Sie später eine neue Regel zwischen zwei bestehende einschieben können, ohne die ganze Policy neu zu nummerieren. Siehe Regel-Priorität für die Ordnungsstrategie.

​
3. verdict — die Aktion

Das eine erforderliche Feld. Wenn eine Regel matcht, entscheidet ihr Verdikt, was mit dem Aufruf passiert:
VerdiktEffekt
allowDen Aufruf durchlassen, geloggt.
auditErlauben und zur Überprüfung aufzeichnen — das übliche default_verdict.
denyDen Aufruf blockieren.
sanitizeGematchte Teilstrings aus den Tool-Argumenten redigieren, dann weiterleiten.
pending_approvalDen Aufruf für einen menschlichen Prüfer zurückhalten.
cap_costVerweigern, sobald die akkumulierten Ausgaben eines Agentenlaufs eine Obergrenze überschreiten.
Ein deny gibt HTTP 400 firewall_blocked auf der inbound-Surface zurück, oder einen Tool-Fehler auf der mcp-Surface. Ein zurückgehaltener Aufruf gibt HTTP 400 firewall_approval_pending mit einer ID zurück, auf die der Agent pollt. Im Shadow-Mode wird jedes durchsetzende Verdikt auf audit herabgestuft und der Grund wird [shadow] would … vorangestellt. Siehe Verdikte für die vollständige Tabelle und die Block-Formen.

​
4. stage — die Enforcement-Surface

Pinnt die Regel auf eine der Surfaces der Firewall. Lassen Sie es leer, und die Regel gilt für alle Surfaces:
Die Tools, die ein Agent dem Modell auf dem Request anbietet. Blockieren Sie ein gefährliches Tool, bevor das Modell es überhaupt wählen kann.
Die tool_calls, die das Modell in seiner Antwort ausgibt.
Ein tools/call, der durch das Firewall-MCP-Gateway geroutet wird.
Ein ausgehender Host / IP / CIDR, den ein Tool erreicht — die SSRF- und Datenexfiltrations-Surface.
Einige Verdikt-+-Stage-Paarungen werden beim Speichern abgewiesen, weil das Verdikt dort nicht feuern kann: cap_cost ist eine Pre-Dispatch-Run-Kosten-Obergrenze, inert auf response und egress; pending_approval hält je nur auf inbound, sodass ein expliziter response/egress-Pin abgewiesen wird. Der Editor verbirgt diese Kombinationen; die API weist sie ab. Siehe Stages.

​
5. tool_name_glob — welches Tool

Ein kleines, case-sensitives Glob auf dem Tool-Namen — shell.* für eine ganze Familie, *.delete für ein Verb über Server hinweg, http_fetch für ein exaktes Tool. Leer oder * matcht jedes Tool. Ein optionales Skill-Namen-Glob (dieselbe Grammatik) UND-verknüpft eine zweite Bedingung auf dem besitzenden Skill, sodass Sie ein Tool von einem eingebauten Skill vertrauen und es von einem Community-Skill gaten können. Die vollständige Grammatik — Präfix, Suffix, Infix, exakt und die Kanten, die Leute stolpern lassen — ist ihre eigene Referenz: Glob-Muster-Syntax.

​
6. args_match_json — mit welchen Argumenten

Das Glob beantwortet welches Tool; args_match_json beantwortet mit welchen Argumenten — der Unterschied zwischen „shell.exec blockieren” und „shell.exec nur blockieren, wenn der Befehl rm -rf ist”. Sein Wert ist ein JSON-kodierter String, der einen Satz von JSONPath-Klauseln trägt, alle UND-verknüpft. Dekodiert sieht das Klauselobjekt 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 Request-Body trägt das Feld dieses Objekt als escapten String, z. B. "args_match_json": "{\"clauses\":[{\"path\":\"$.command\",\"op\":\"regex\",\"value\":\"rm -rf\"}]}". Operatoren sind eq, contains, regex, in, cidr_match, gt und lt. Ein abwesendes args_match_json ist vakuös wahr — die Regel matcht auf das Glob allein. Die vollständige Prädikatsprache, Pfadsyntax und das Fail-closed-Verhalten einer kaputten Klausel sind in Argumente validieren und dem Argument-Kochbuch.

​
7. egress_json — welche Ziele

Verwendet auf der egress-Surface: ein JSON-kodierter String, der eine Host- / CIDR-Allow-und-Deny-Liste trägt, gematcht gegen ein ausgehendes Ziel, das ein Tool erreicht. Dekodiert sieht das Objekt so aus: 
{
  "deny":  ["169.254.169.254", "10.0.0.0/8"],
  "allow": ["api.openai.com"]
}
Einträge matchen als CIDR, als IP-Literal oder als case-insensitiver Hostname. Die Polarität folgt dem Verdikt — mit einem durchsetzenden Verdikt definiert die deny-Liste, was blockiert wird, und allow schnitzt Ausnahmen heraus.
Das Baseline-Firewall-Template liefert eine Egress-Deny-Regel mit einer fertigen SSRF- / Cloud-Metadata-Denylist (die Metadata-IP 169.254.169.254, RFC-1918-Bereiche, Loopback, Link-local und metadata.google.internal), sodass Sie diese nicht handverfassen müssen. Fügen Sie Ihre eigenen Ziele obendrauf für alles andere hinzu, das Sie gaten wollen. Siehe Egress-Kontrolle für das vollständige Rezept und Datenexfiltration dafür, warum es zählt.

​
8. sanitize_json — Argumente redigieren

Verwendet, wenn verdict = sanitize: ein JSON-kodierter String, der benennt, welche Presets / Custom-Regexes gematchte Teilstrings aus den Tool-Argumenten redigieren, bevor der bereinigte Aufruf weitergeleitet wird — nützlich, um ein Secret oder einen PII-Wert zu strippen, den ein Agent in ein Argument fallen ließ, ohne die ganze Aktion zu blockieren. Dekodiert sieht das Objekt so aus: 
{ "presets": ["email", "ssn_us"], "custom": ["foo-\\d+"] }
Sanitize redigiert nur Argumente — nie den Inhalt, den ein Tool zurückgibt. Eine Sanitize-Regel muss mindestens ein Preset oder Custom-Muster benennen (ein leerer Sanitizer wird abgewiesen). Auf der inbound-Surface gibt es keine Aufruf-Argumente zum Redigieren, sodass ein Sanitize-Verdikt dort zu einem Deny eskaliert.
Siehe Antworten bereinigen für die Preset-Bibliothek und Redaktionsformen.

​
9. cap_cost_cents — eine Ausgaben-Obergrenze

Verwendet, wenn verdict = cap_cost: eine Pro-Regel-Run-Kosten-Obergrenze, eine Ganzzahl in USD-Cent. Wenn die Regel matcht, wird der Aufruf verweigert, sobald die akkumulierten Ausgaben des Agentenlaufs die Obergrenze überschreiten — ein Schutzschalter für eine außer Kontrolle geratene Schleife, der in Events auf allow oder deny auflöst. Die Obergrenze muss explizit und nicht-negativ sein, und die Regel kann nicht auf response oder egress gepinnt werden (wo das Verdikt inert ist). Volles Verhalten in Kosten begrenzen.

​
10. Eine vollständige Regel

Die Felder zusammensetzend — shell.exec verweigern, aber nur wenn der Befehl destruktiv aussieht, gescopt auf die modellausgegebenen Tool-Calls: 
{
  "priority": 10,
  "label": "block destructive shell",
  "stage": "response",
  "tool_name_glob": "shell.exec",
  "args_match_json": "{\"clauses\":[{\"path\":\"$.command\",\"op\":\"regex\",\"value\":\"rm -rf|mkfs|:\\\\(\\\\)\\\\{\"}]}",
  "verdict": "deny",
  "notes": "fork bombs and recursive deletes only — plain shell.exec audits"
}
Die Stage matcht die Response-Surface, das Glob picks shell.exec, die einzelne Klausel engt auf einen destruktiven Befehl ein, und das Verdikt verweigert. Jedes shell.exec, dessen Befehl den Regex nicht matcht, fällt durch zur nächsten Regel oder zum Policy-Default. Hängen Sie einen Key an die Policy (firewall_policy_id auf dem Key) und sie ist beim nächsten Aufruf aktiv — kein Redeploy.
Bestätigen Sie, dass eine Regel auf genau dem feuert, was Sie erwarten, bevor Sie sich darauf verlassen: Regeln testen dry-runnt eine Policy gegen einen Beispiel-Tool-Call und gibt das Verdikt, die gematchte Regel und den Grund zurück, ohne irgendetwas zu dispatchen.

​
11. Wie die Felder sich kombinieren

Ein verdict. Alles andere ist optional: eine leere stage matcht alle Surfaces, ein leeres tool_name_glob (oder *) matcht jedes Tool, und ein abwesendes args_match_json matcht jegliche Argumente. Ein bloßes { "verdict": "audit" } ist ein gültiger Catch-all.
Sie ANDen. Eine Regel feuert nur, wenn ihre Stage, ihr Tool-Glob, ihr Skill-Glob, ihre Argument-Klauseln und ihr Egress-Scope alle halten. Um OR auszudrücken, schreiben Sie separate Regeln.
sanitize_json wird nur für das sanitize-Verdikt gelesen; cap_cost_cents nur für cap_cost; egress_json nur auf der egress-Surface. Die Konsole validiert diese Paarungen beim Speichern, sodass eine Regel, die ein Verhalten anzeigt, es aber nie durchsetzen kann, nicht persistiert werden kann.
Die niedrigere priority gewinnt (Gleichstände über die Regel-ID gebrochen) — erster Treffer gewinnt, und die Auswertung stoppt dort. Siehe Regel-Priorität.

​
Verwandtes

Eine Policy erstellen

Verfassen Sie Ihre erste Policy und hängen Sie einen Key an.

Glob-Syntax

Die vollständige Tool-Namen-Glob-Grammatik.

Verdikte

Jedes Verdikt und wie ein Block aussieht.

Argumente validieren

JSONPath-Argument-Klauseln im Detail.

Policies verwalten

Policies bearbeiten, versionieren und reverten.

Firewall-Regeln

Die vollständige Matching-Engine-Referenz.
Neu in der Aktionsebene? Starten Sie beim Firewall-Überblick, oder sehen Sie, wie sie sich mit Text-Screening paart in Guardrails vs. Firewall.