Zum Hauptinhalt springen
Eine Firewall-Policy ist eine geordnete Liste von Regeln. Diese Seite ist die vollständige Referenz dafür, was eine Regel ausdrücken kann — die Matching-Sprache, die Verdikte und wie die Engine sie auswertet. Regeln werden im Regel-Editor der Konsole verfasst, der strukturierte JSON-Match-Objekte schreibt. Alles Folgende beschreibt dieses Vokabular, sodass Sie eine Regel präzise lesen, durchdenken und verifizieren können — ganz gleich, ob Sie sie in der UI bauen oder über die API posten.

​
1. Anatomie einer Regel

FeldTypBedeutung
priorityintNiedriger läuft zuerst. Gleichstände werden über die Regel-ID gebrochen.
labelstringMenschlicher Name, in Events und Audit angezeigt.
stageenumDie Surface — inbound / response / mcp / egress. Leer = alle Surfaces.
tool_name_globstringGlob auf den Tool-Namen.
skill_name_globstringOptionaler Glob auf den besitzenden Skill. AND-verknüpft mit dem Tool-Glob; leer = beliebiger Skill.
verdictenumDie Aktion — siehe §7.
args_matchobjectOptionales Argument-Prädikat.
sanitizeobjectRedaktions-Konfiguration, verwendet bei verdict = sanitize. Siehe §5.
egressobjectHost-/CIDR-Allow-/Deny-Liste, verwendet bei stage = egress. Siehe §6.
cap_cost_centsintRun-Kosten-Obergrenze, verwendet bei verdict = cap_cost.
sequenceobjectGeordneter mehrstufiger Match, reaktiv durchgesetzt. Siehe §8.
notesstringBegründung des Autors; von der Engine ignoriert.
Eine Regel matcht einen Tool-Call, wenn alle ihrer deklarierten Bedingungen zutreffen: die Stage matcht (oder ist leer), der Tool-Glob matcht, der Skill-Glob matcht (oder ist leer), die Argument-Klauseln matchen (oder fehlen) und der Egress-Scope matcht (nur Egress-Regeln). Die Engine durchläuft die Regeln in Prioritätsreihenfolge, und der erste Treffer gewinnt.

​
2. Tool-Namen-Glob

Eine bewusst kleine, Groß-/Kleinschreibung beachtende Grammatik — keine Regex-Überraschungen, lineare Zeit, sicher auf dem heißen Relay-Pfad:
MusterMatcht
"" oder *Jedes Tool.
foo.*Präfix — foo.bar, foo.exec (nicht das blanke foo).
*.execSuffix — shell.exec, db.exec (nicht das blanke exec).
*.shell.*Infix — local.shell.exec (braucht ≥1 Zeichen auf jeder Seite).
alles andereExakter String-Match (einschließlich foo.*.bar).
Tools werden konventionell als server.tool oder category.action namespaced, sodass shell.* eine ganze Familie erfasst und *.delete ein Verb über Server hinweg erfasst.

​
3. Skill-Namen-Glob

Dieselbe Glob-Grammatik, gematcht gegen den besitzenden Skill des Tool-Calls (z. B. community.*, builtin.send). Sie wird mit tool_name_glob AND-verknüpft, also: 
tool_name_glob:  http.fetch
skill_name_glob: community.*
matcht http.fetch nur dann, wenn es einem community.*-Skill gehört — vertrauen Sie demselben Tool aus einem eingebauten Skill, gaten Sie es aus einem Community-Skill. Ein leerer Skill-Glob matcht jeden Owner. Wie ein Tool-Call einem Skill zugeordnet wird, ist in Skills behandelt.

​
4. Argument-Klauseln

Tool-Namen-Matching beantwortet welches Tool; Argument-Klauseln beantworten mit welchen Argumenten — der Unterschied zwischen „shell.exec blockieren” und „shell.exec nur dann blockieren, wenn das Kommando rm -rf ist”. args_match ist ein Satz von Klauseln, alle miteinander AND-verknüpft: 
{
  "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" }
  ]
}
Ein leeres / fehlendes args_match ist vakuös wahr — die Regel matcht allein auf dem Glob.

​
Operatoren

OperatorMatcht, wenn
eqSkalare Gleichheit (Zahlen numerisch verglichen; Typ-Mismatch → 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 den gegebenen CIDR.
gt / ltNumerisch größer-als / kleiner-als (Strings werden nicht koerziert).

​
Path-Syntax

Eine kleine JSONPath-Teilmenge über das Argument-Objekt des Tools:
  • $.foo, $.foo.bar — Feldzugriff
  • $.foo[0], $.arr[1].k — Array-Indexierung
  • $ — das gesamte Arguments-Objekt
Keine Wildcards, Filter, Slices oder rekursiver Abstieg.
Argument-Klauseln failen closed — die Regel, nicht der Request. Wenn ein Path nicht auflöst, die Argumente fehlerhaft sind oder eine Regex/CIDR ungültig ist, wertet die Klausel zu false aus und die Regel feuert einfach nicht — der Aufruf fällt zur nächsten Regel oder zum Default-Verdikt durch. Eine kaputte Klausel auto-denied nie und stürzt das Relay nie ab. Schreiben Sie Ihre „alles Gefährliche abfangen”-Regel als ein explizites deny mit eigenem Glob, statt sich darauf zu verlassen, dass eine Klausel auf eine bestimmte Weise failt.
Die Konsole validiert Klauseln beim Speichern strikt (unbekannte Operatoren, schlechte Paths, Nicht-Array-in-Werte, nicht-kompilierbare Regexes und ungültige CIDRs werden allesamt abgelehnt), sodass eine fehlerhafte Klausel gar nicht erst persistiert werden kann.

​
5. Sanitizer

Ein sanitize-Verdikt redigiert gematchte Teilstrings aus den Tool-Argumenten und leitet den bereinigten Aufruf weiter — nützlich, um Secrets oder PII zu entfernen, die ein Agent in ein Tool-Argument gesetzt hat, ohne die gesamte Aktion zu blockieren. 
{ "presets": ["email", "ssn_us"], "custom": ["foo-\\d+"] }
Preset-Treffer werden durch [redacted:<preset>] ersetzt; Custom-Regex-Treffer durch [redacted:custom]. Die eingebaute Preset-Bibliothek: aws_access_key, aws_secret_key, openai_key, anthropic_key, bearer_token, email, ssn_us, credit_card (mit einer Luhn-Prüfung). Eine Sanitize-Regel muss mindestens ein Preset oder Custom-Muster deklarieren — ein leerer Sanitizer wird beim Speichern abgelehnt. Auf der inbound-Surface gibt es keine Aufruf-Argumente zu redigieren, sodass ein Sanitize-Verdikt dort zu einem Block eskaliert.

​
6. Egress-Ziellisten

Eine egress-Regel (stage egress) matcht auf ein ausgehendes Ziel — die SSRF- und Exfiltrations-Surface: 
{
  "deny":  ["169.254.169.254", "10.0.0.0/8"],
  "allow": ["api.openai.com"]
}
Einträge matchen als CIDR, IP-Literal oder Groß-/Kleinschreibung-ignorierender Hostname; Hostnames werden best-effort aufgelöst und gegen IP-/CIDR-Einträge neu geprüft. Die Polarität folgt dem Verdikt: Bei einem allow-Verdikt definiert die allow-Liste, was im Scope ist, und deny schneidet Ausnahmen heraus; bei einem durchsetzenden Verdikt (deny) definiert die deny-Liste, was blockiert ist, und allow schneidet Ausnahmen heraus. 169.254.169.254 (der Cloud-Metadata-Endpunkt) und RFC-1918-Bereiche sind die kanonischen Dinge, die man denyen sollte — das block_ssrf_egress-Preset und die tight-Autonomie-Stufe liefern genau das.

​
7. Verdikte

VerdiktEffektNotizen
allowDurchlassen, geloggt.
auditErlauben + zur Überprüfung aufzeichnen.Das übliche default_verdict.
denyDen Aufruf blockieren.HTTP 400 auf inbound; Tool-Fehler auf mcp.
sanitizeArgs redigieren, weiterleiten.Braucht einen Sanitizer; eskaliert auf inbound zu deny.
pending_approvalFür einen Menschen zurückhalten.Erfordert den konfigurierten Approval-Store; abgelehnt auf response/egress.
cap_costAblehnen jenseits einer Ausgaben-Obergrenze.Braucht ein nicht-negatives cap_cost_cents; inert auf response/egress.
Im Shadow-Mode wird jedes durchsetzende Verdikt auf audit herabgestuft und dem Grund wird [shadow] would … vorangestellt.

​
8. Sequenzen

Manche Risiken sind nur über mehrere Aufrufe hinweg sichtbar — 50 CRM-Datensätze lesen, dann exportieren, dann einen externen Host erreichen. Eine sequence-Regel matcht eine geordnete Kette statt eines einzelnen Aufrufs: 
{
  "window_seconds": 600,
  "steps": [
    { "match": "crm.*",   "min_count": 3 },
    { "match": "*.export" },
    { "match": "*",       "egress": true }
  ]
}
Jeder Step ist ein Tool-Glob mit einem optionalen min_count (Default 1) und einem optionalen egress: true (der Step muss ein Egress-Aufruf sein). Steps müssen in Reihenfolge auftreten — Verschachtelung mit anderen Aufrufen ist in Ordnung — und die gesamte Kette muss innerhalb von window_seconds abschließen (0 = keine Grenze).
Sequenzen werden reaktiv von einem asynchronen Matcher durchgesetzt, nicht inline bei jedem Aufruf — eine Sequenz mit einem *-Step würde sonst jeden einzelnen Tool-Call matchen. Sie leuchten im Events-Feed auf und können Folgeaktionen auslösen, aber sie blockieren nicht den einzelnen Aufruf, der die Kette in Echtzeit abschließt.

​
9. Eingebaute Presets

Starten Sie von einem Preset statt von einer leeren Regel. Sie werden serverseitig verfasst, sodass die Konsole und diese Doku identisches Verhalten beschreiben:
PresetWas es tut
block_destructive_shellDenyt destruktive Shell-Kommandos (rm -rf, mkfs, dd, Fork-Bombs, …) über einen Satz von Deny-by-Glob-Regeln.
block_ssrf_egressAuditiert Egress zum Metadata-Endpunkt und zu RFC-1918-Bereichen.
block_secrets_in_argsErkennungsorientiert — flaggt Credentials, die in Tool-Argumenten auftauchen.
block_pii_in_tool_resultsErkennungsorientiert — bringt PII in Tool-Ergebnissen ans Licht.
Wenden Sie ein Preset als Keim an und bearbeiten Sie dann frei — ein Preset ist ein Ausgangspunkt, keine Sperre.

​
10. Auswertung, Limits & Sicherheit

  • Erster Treffer gewinnt. Regeln laufen in priority ASC, id ASC-Reihenfolge; die erste Regel, deren Bedingungen alle zutreffen, entscheidet das Verdikt. Keine Regel matcht → das default_verdict der Policy.
  • Deterministisch und ohne Abhängigkeiten. Glob- und Klausel-Matching sind reine String-/JSON-Operationen ohne Netzwerkaufruf, sicher bei jedem Tool-Call auszuführen. Regexes sind RE2 — lineare Zeit, kein katastrophales Backtracking.
  • Fail-closed-Klauseln. Eine Klausel, die nicht ausgewertet werden kann, lässt ihre Regel nicht feuern statt auto-zu-denyen (§4).
  • Strikte Validierung beim Speichern. Verdikt/Stage-Paarungen, Sanitizer-Nicht-Leere, cap_cost_cents-Vorhandensein, Klausel-Form und Ref-Auflösung werden alle beim Speichern geprüft — ungültige Regeln können nicht persistiert werden.
  • Auditiert. Jedes Erstellen/Aktualisieren/Löschen einer Regel schreibt eine Audit-Zeile, nachdem die Änderung committed ist; Regel-Blobs und Secrets werden nie in das Audit-Log geschrieben.

​
API-Referenz

Regeln leben unter einer Policy und sind workspace-bezogen; Schreiben erfordert Developer+.
Methode & PfadRolleZweck
POST /api/workspace/firewall/rulesDeveloper+Eine Regel erstellen.
PUT /api/workspace/firewall/rulesDeveloper+Eine Regel aktualisieren (ID im Body).
DELETE /api/workspace/firewall/rules/:idDeveloper+Eine Regel löschen.
GET /api/workspace/firewall/presetsMemberEingebaute Presets auflisten.
POST /api/workspace/firewall/testDeveloper+Eine Policy (Regeln inklusive) gegen einen Beispiel-Tool-Call dry-runnen.
Um eine Regel vorzuschauen, bevor Sie sich auf sie verlassen, verwenden Sie Test — es gibt das Verdikt, die gematchte Regel und den Grund zurück, ohne etwas zu dispatchen.

​
Siehe auch

Sie möchten tiefer in die Agentensicherheit einsteigen? Die Leitfäden Secure Your Agents (Zero Trust) ordnen dieses Feature in einen Zero-Trust-Workflow ein.

Eine Firewall-Policy aufbauen

Verfassen Sie Schritt für Schritt eine Zero-Trust-Policy und schatten Sie sie, bevor Sie sie durchsetzen.

Regel-Schema-Referenz

Jedes Regelfeld — Globs, Argument-Prädikate, Egress und Kostenobergrenzen.