Zum Hauptinhalt springen
Eine Firewall-Regel feuert an einem bestimmten Punkt im Lebenszyklus eines Tool-Calls. Dieser Punkt ist ihre Stage — eine von vier Enforcement-Surfaces, von denen jede einen anderen Ausschnitt des Aufrufs sieht. Pinnen Sie eine Regel auf die falsche Stage, sieht sie die falschen Daten: Eine Egress-Allowlist auf der inbound-Surface hat kein Ziel zu prüfen; eine Argument-Klausel auf inbound hat noch keine Aufruf-Argumente. Diese Seite ist der fokussierte Leitfaden zu den vier Agent-Firewall-Stages: was jede Surface beobachtet, wann eine Regel sie anvisieren sollte und der eine konkrete Weg, wie dieselbe Absicht an verschiedenen Stages ausgedrückt wird. Für das vollständige Regel-Vokabular siehe Firewall-Regeln; für das Policy-Modell darum herum Firewall.

​
1. Die vier Stages auf einen Blick

Jede Auswertung wird mit genau einer Stage gestempelt. Eine Regel ohne Stage ("") trifft auf alle zu; eine auf eine Stage gepinnte Regel feuert nur dort.
StageWas die Surface sieht
inboundTools, die der Agent auf dem Request anbietet
responsetool_calls, die das Modell in seiner Antwort ausgibt
mcpEin tools/call, der durch das MCP-Gateway dispatcht wird
egressEin ausgehender Host / IP / CIDR, den ein Tool erreicht
Die Stage-Namen sind stabile Enum-Werte — Sie setzen sie wörtlich im Stage-Feld des Regel-Editors oder als stage-Eigenschaft, wenn Sie über die API verfassen.
Die Stage steuert, welche Daten im Scope sind, nicht, wie streng das Verdikt ist. Ein deny ist ein deny auf jeder Stage; was sich ändert, ist, ob die Regel die Argumente, den Tool-Namen oder das Ziel hat, auf das sie matchen muss.

​
2. inbound — die Tools, die ein Agent anbietet

Die früheste Surface. Bevor das Modell je läuft, sendet Ihr Agent eine Liste von Tool-Definitionen, deren Aufruf er dem Modell zu erlauben bereit ist. Die inbound-Stage sieht diesen angebotenen Toolset und kann ein gefährliches Tool blockieren, bevor das Modell es überhaupt wählen kann. An dieser Stage gibt es keine Aufruf-Argumente — das Modell hat noch nicht entschieden, wie es irgendetwas aufruft — also matchen inbound-Regeln auf den Tool-Namen (und optional seinen besitzenden Skill), nicht auf args_match_json.
Ein sanitize-Verdikt auf inbound hat nichts zu redigieren (es existieren noch keine Argumente), also eskaliert es zu einem Block. Verfassen Sie Inbound-Regeln als explizites allow / deny und sparen Sie sich sanitize für die Ausführungs-Stages auf.
Ein abgelehnter Aufruf hier gibt HTTP 400 mit dem Code firewall_blocked zurück, benannt nach Tool und Grund und als skip-retry markiert.

​
3. response — die Tool-Calls, die das Modell ausgibt

Sobald das Modell antwortet, kann es einen oder mehrere tool_calls ausgeben — konkrete Aufrufe mit realen Argumenten. Die response-Stage sieht diese, also gehören argumentebene Regeln hierhin: nicht „blockiere shell.exec”, sondern „blockiere shell.exec nur, wenn der Befehl rm -rf ist”. 
{
  "stage": "response",
  "tool_name_glob": "shell.exec",
  "verdict": "deny",
  "args_match_json": "{\"clauses\":[{\"path\":\"$.command\",\"op\":\"regex\",\"value\":\"rm -rf|mkfs|dd if=\"}]}"
}
Weil die vom Modell gewählten Argumente vorhanden sind, funktioniert sanitize hier — es redigiert gematchte Teilstrings aus den Argumenten des Aufrufs und leitet den bereinigten Aufruf weiter. (Sanitize redigiert nur die Tool-Call-Argumente; es berührt nie den Inhalt, den ein Tool zurückgibt.)

​
4. mcp — durch das Gateway dispatchte Aufrufe

Wenn ein Agent ein Tool über OrcaRouters MCP-Gateway erreicht, wird jeder tools/call auf der mcp-Stage ausgewertet, bevor er an den registrierten Server dispatcht wird. Dies ist die Surface, die Model-Context-Protocol-Traffic steuert — dasselbe Glob- / Argument- / Verdikt-Vokabular wie response, angewandt auf MCP-Dispatch. Ein Block hier taucht als Tool-Fehler (firewall deny: <reason>) statt als Transportfehler auf, sodass das Modell die Ablehnung sieht und reagieren kann — ein anderes Tool wählen, den Nutzer fragen oder anhalten.
Die mcp-Stage paart sich mit Pro-Server-Governance: Jeder registrierte MCP-Server hat seine eigene Health-Probe und verschlüsselte Credentials, und durch ihn geladene Skills tragen ein Risk-Band und einen Enforcement-Mode. Siehe Firewall-MCP und Firewall-Skills.

​
5. egress — das ausgehende Ziel, das ein Tool erreicht

Die letzte Surface. Wenn ein Tool ein ausgehendes Netzwerkziel meldet, matcht die egress-Stage darauf — die SSRF- und Datenexfiltrations-Surface. Egress-Regeln matchen nicht auf ein Tool-Namen-Muster allein; sie matchen auf eine Host- / IP- / CIDR-Liste: 
{
  "stage": "egress",
  "verdict": "deny",
  "egress_json": "{\"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. Sie verfassen Host- und CIDR-Deny-Regeln selbst — der Cloud-Metadata-Endpunkt (169.254.169.254) und RFC-1918-Bereiche sind die kanonischen Dinge, die man ablehnt. Siehe Firewall-Regeln §6 für die Allow-/Deny-Polarität.
Kein Preset liefert CIDR-Regeln. Die SSRF-Haltung der tight-Autonomie-Stufe lehnt abruf-förmige Tool-Namen ab (z. B. http_fetch, web_search, fetch_url); ein zielbasiertes Egress-Deny ist etwas, das Sie für die Hosts und Bereiche verfassen, die Ihre Agenten niemals erreichen dürfen.

​
6. Die richtige Stage wählen

Dasselbe Sicherheitsziel hat oft eine beste Stage. Bringen Sie die Absicht mit der Surface in Einklang, die tatsächlich die Daten trägt, die Sie brauchen:
Wenn das Modell ein Tool niemals auch nur sehen soll, lehnen Sie es auf inbound ab. Der Block landet vor dem Modellaufruf, kostet also keine Modell-Tokens.
Argument-Klauseln brauchen die vom Modell gewählten Argumente, die nur auf response und mcp existieren. Lehnen Sie bei einem gefährlichen Argument ab, oder sanitize, um einen Secret- oder PII-Wert zu entfernen, den der Agent in ein Argument gesetzt hat.
Durch das MCP-Gateway geroutete Aufrufe werden auf mcp vor dem Dispatch ausgewertet — der Engpass für die Tools jedes registrierten Servers.
Zielbasierte Regeln — die Cloud-Metadata-IP blockieren, ein CIDR ablehnen, Ihre genehmigten Hosts allow-listen — ergeben nur auf egress Sinn.
Eine Regel ohne Stage läuft auf allen vieren. Verwenden Sie sie für eine pauschale default_verdict-artige Regel oder ein Tool, das Sie überall, wo es auftaucht, ablehnen.

​
7. Stages und Shadow-Mode

Das shadow_mode-Flag einer Policy ist unabhängig von der Stage. Schalten Sie es ein, und jedes durchsetzende Verdikt — auf jeder Stage — wird auf audit herabgestuft und dem Grund wird [shadow] would … vorangestellt, sodass Sie bestätigen können, dass eine Regel auf der richtigen Surface feuert, bevor sie Live-Traffic verändert. Siehe Shadow-Mode und Enforcement-Modes.

​
8. Wo Stages ins größere Bild passen

Die vier Stages sind das Wo der Durchsetzung; der Rest des Modells ist das Was und Wer.

Verdikte

Was jede Stage tun kann, sobald sie matcht — erlauben, auditieren, ablehnen, bereinigen, zur Freigabe zurückhalten, Kosten begrenzen.

Tool-Allow-Listing

Verwenden Sie inbound, um den Toolset einzuschränken, den ein Agent anbietet.

Argumente validieren

Verfassen Sie response- / mcp-Argument-Klauseln, die ein Tool danach gaten, wie es aufgerufen wird.

Egress-Steuerung

Blockieren Sie ausgehende Ziele auf der egress-Surface — die Exfiltrationsgrenze.
Wie diese Surfaces auf dem Inspektionspfad sitzen, siehe Wie OrcaRouter inspiziert und die Notizen zur Enforcement-Pfad-Latenz. Für die Bedrohungen, die jede Stage adressiert, siehe Gefährliche Tool-Calls, Datenexfiltration und MCP-Tool-Poisoning.