Zum Hauptinhalt springen
Eine Firewall-Policy entscheidet eine Sache über jeden Tool-Call, den Ihr Agent macht: ein Verdikt. Entweder matcht eine Regel und erzeugt ein Verdikt, oder keine Regel matcht und das Default-Verdikt der Policy übernimmt. Diese Seite behandelt beides — was jedes Firewall-Verdikt tut, wie cap_cost aufgelöst wird und warum audit der Default ist, von dem Sie starten. Wo Verdikte in der Regel-Grammatik leben, siehe Firewall-Regeln; zum Wählen eines Default-Verdikts beim Erstellen einer Policy siehe Erstellen & anhängen.

​
1. Die sechs Regel-Verdikte

Eine Regel erzeugt genau eines von sechs Verdikten. Verfassen Sie sie im Konsolen-Regel-Editor; die Engine durchläuft die Regeln in Prioritätsreihenfolge und der erste Treffer gewinnt.
Der Aufruf läuft unangetastet durch. Er landet trotzdem im Events-Feed als allow, sodass Sie einen Audit-Trail behalten, ohne irgendetwas zu blockieren. Verwenden Sie es als expliziten Permit in einer Default-Deny-Policy.
Identisches Traffic-Ergebnis wie allow, aber der Aufruf wird als etwas geflaggt, das Sie beobachten wollten. Dies ist auch der Wert, auf dem das Default-Verdikt out of the box landet — alles beobachten, nichts blockieren, bis Sie bereit sind durchzusetzen.
Der Aufruf erreicht das Tool nie. Auf der inbound-Surface gibt das Relay HTTP 400 mit dem Fehlercode firewall_blocked zurück, der das Tool und den Grund benennt; auf der mcp-Surface kommt es als Tool-Fehler zurück, sodass das Modell reagieren kann. Siehe wie ein Block aussieht.
Redigiert gematchte Teilstrings aus den Tool-Call-Argumenten (ein Secret oder PII, das der Agent in ein command- oder body-Feld gesetzt hat) und leitet den bereinigten Aufruf weiter. Es redigiert nur Argumente — nie den Inhalt, den ein Tool zurückgibt. Auf der inbound-Surface gibt es noch keine Aufruf-Argumente, also eskaliert sanitize zu einem deny. Siehe Antworten bereinigen.
Verwandelt den Aufruf in eine Out-of-band-Prüfung. Das Relay gibt HTTP 400 mit dem Code firewall_approval_pending und einer Approval-ID zurück; der Aufruf erreicht das Tool nicht. Ein Prüfer löst es in der Konsole oder über einen Webhook-Callback auf, und der Agent reicht mit einem einmal nutzbaren Approval-Header erneut ein. Siehe Freigaben.
Ein Kosten-Schutzschalter — als Regel verfasst, aber zur Auswertungszeit zu allow oder deny aufgelöst. Siehe §3 und Kosten begrenzen.
Shadow-Mode flacht die Durchsetzung ab. Im Shadow-Mode wird jedes durchsetzende Verdikt (deny, sanitize, pending_approval und ein cap_cost, das zu deny aufgelöst wurde) auf audit herabgestuft und dem Grund wird [shadow] would … vorangestellt. Rollen Sie eine durchsetzende Policy auf diese Weise aus und beobachten Sie den Events-Feed, bevor Sie sie live schalten.

​
2. Das Default-Verdikt

Das Default-Verdikt (default_verdict auf der Policy) ist, was die Policy tut, wenn keine Regel auf einen Tool-Call matcht. Es ist der Boden Ihrer Haltung, und anders als ein Regel-Verdikt akzeptiert es nur drei Werte:
default_verdictWenn keine Regel matcht…
audit (Default)Den Aufruf erlauben, aber aufzeichnen. Der sichere Ausgangspunkt.
allowErlauben und loggen, kein Überprüfungs-Datensatz.
denyAlles blockieren, was eine Regel nicht explizit erlaubt — eine Default-Deny-Haltung.
Eine neue Policy hat standardmäßig audit: Sie beobachtet jeden Tool-Call und blockiert nichts, bis Sie durchsetzende Regeln hinzufügen. Die drei Nur-Regel-Verdikte — sanitize, pending_approval und cap_cost — können nicht ein Default sein; ein Default-Verdikt ist ein pauschaler Fallback, und diese Verdikte ergeben nur auf einen spezifischen Match gescoped Sinn.
deny als Default-Verdikt ist Default-Deny: Jeder Tool-Call, den Ihre Regeln nicht explizit allow, wird blockiert. Mächtig für einen abgeriegelten Agenten, aber es wird Aufrufe stoppen, die Sie zu allow-listen vergessen haben. Paaren Sie es mit expliziten Allow-Regeln (Tool-Allow-Listing) und rollen Sie es zuerst unter Shadow-Mode aus.

​
3. cap_cost wird zu allow oder deny aufgelöst

cap_cost ist das eine Verdikt, das nicht das ist, was in Ihren Events auftaucht. Sie verfassen eine Regel mit einer cap_cost_cents-Obergrenze, aber zur Auswertungszeit löst die Engine sie zu einem konkreten allow oder deny auf, bevor das Event aufgezeichnet wird — sodass der Events-Feed nie ein wörtliches cap_cost-Verdikt trägt, nur das allow/deny, das der Agent tatsächlich gesehen hat. Die Obergrenze ist pro Agentenlauf: Die Engine vergleicht die kumulierten Ausgaben des Runs mit Ihrer Obergrenze.
  • Unter der Obergrenze → wird zu allow aufgelöst. (Intern wird dies als nicht-matchend behandelt, sodass die Auswertung zur nächsten Regel fortschreitet, statt cap_cost first-match als Grant gewinnen zu lassen.)
  • Über der Obergrenze → wird zu deny aufgelöst, mit einem Grund, der die Gesamtsumme des Runs gegen die Obergrenze benennt. Dies ist das terminale Schutzschalter-Ergebnis.
// Eine Regel, die einen Run bei 5,00 $ kumulierter Ausgaben begrenzt.
{
  "label": "run cost ceiling",
  "tool_name_glob": "*",
  "verdict": "cap_cost",
  "cap_cost_cents": 500
}
cap_cost feuert nur auf den Pre-Dispatch-Surfaces (inbound, mcp) — den Punkten, an denen das Blockieren eines Aufrufs die Ausgabe noch verhindert. Auf den Post-Dispatch-Surfaces response und egress ist es inert (es gibt nichts mehr zu stoppen), also überspringt die Engine es dort.

​
4. Wie ein Verdikt gewählt wird

Für jeden Tool-Call ist die Auflösung dieselbe, ganz gleich, welches Verdikt gewinnt:
Das Gateway wählt die am aufrufenden Key angehängte Policy (firewall_policy_id) oder den Workspace-Default — siehe Auflösung.
Regeln laufen in priority ASC-Reihenfolge. Die erste Regel, deren Surface, Tool-Glob, optionale Argument-Klauseln und optionaler Egress-Scope alle matchen, erzeugt das Verdikt.
Wenn keine Regel matcht, gilt das default_verdict der Policy — audit, sofern Sie es nicht geändert haben.
Wenn der Aufruf einem gesteuerten Skill gehört, erzwingt ein Skill im block-Mode ein deny und ein Skill im quarantine-Mode eskaliert alles unterhalb von deny zu pending_approval.

​
5. Kosten- und Retry-Verhalten eines deny

Ein Firewall-Verdikt auf der inbound-Surface feuert vor dem Upstream-Modellaufruf, sodass ein deny dort keine Modell-Tokens kostet. Der Fehler ist als skip-retry markiert — das erneute Ausführen desselben blockierten Aufrufs würde einfach wieder blockieren, also sagt das Gateway dem Client, ihn nicht zu wiederholen. Das unterscheidet sich von einem Guardrail-Block, der Prompt-/Response-Text (PII, Secrets) statt Tool-Aktionen screent und seinen eigenen guardrail_blocked-Fehler zurückgibt. Eine Anfrage kann durch beide Ebenen laufen.
Jedes Verdikt hinterlässt eine Spur. Jede Auswertung — allow, audit, deny, das aufgelöste cap_cost, die zurückgehaltene Freigabe — wird als Firewall-Event aufgezeichnet, filterbar nach Verdikt, Surface, Tool und Run. Der Events-Feed ist, wie Sie bestätigen, dass eine Policy die Verdikte erzeugt, die Sie erwarten. Siehe Events-Log und Analytics.

​
Wohin als Nächstes

Eine Policy erstellen & anhängen

Ein Default-Verdikt wählen und eine Policy an einen Key binden.

Kosten begrenzen

Eine Ausgaben-Obergrenze verfassen und wie sie pro Run aufgelöst wird.

Shadow-Mode

Jedes durchsetzende Verdikt auf audit herabstufen, während Sie die Wirkung messen.

Regel-Referenz

Die vollständige Matching-Sprache hinter einem Verdikt.
Für die Bedrohungen, die diese Verdikte stoppen sollen, siehe gefährliche Tool-Calls und übermäßige Handlungsmacht.