Zum Hauptinhalt springen
Ein KI-Agent generiert nicht nur Text — er handelt. Er ruft shell.exec auf, fragt eine Datenbank ab, holt eine URL, dispatcht einen Tool-Call durch einen MCP-Server. Jedes davon ist eine Aktion mit realen Konsequenzen, die Guardrails auf Prompt-Ebene nicht sehen können. Die Agent-Firewall ist die Aktionsebene, die sie steuert: eine workspace-bezogene, benannte Policy, die das Gateway bei jedem Tool-Call auswertet, bevor er das Tool erreicht. Diese Seite ist der Hub für den Firewall-Abschnitt — das Policy-Modell, die Verdikte, die Surfaces und wie eine Policy sich an einen Key anhängt. Jede Speiche geht tiefer, und die vollständige Engine-Referenz lebt in Firewall und Firewall-Regeln.

​
1. Was die Agent-Firewall tut

Sie verfassen eine Policy einmal in Ihrer Workspace-Konsole, hängen einen API-Key daran (oder setzen einen als Workspace-Default), und von da an wird jeder Tool-Call, den dieser Key ausgibt, am Gateway gegen die Policy geprüft. Kein Redeploy, keine Änderung im Agenten-Code — Ihr Agent gibt Tool-Calls weiterhin genau wie zuvor aus, und das Bearbeiten der Policy wirkt sich beim nächsten Aufruf auf jeden daran gebundenen Key aus. Eine Policy ist eine geordnete Liste von Regeln. Jede Regel entscheidet, auf welche Tool-Calls sie zutrifft und was damit zu tun ist. Die Engine durchläuft die Regeln in Prioritätsreihenfolge, erster Treffer gewinnt, und fällt auf das Default-Verdikt der Policy zurück, wenn nichts matcht.
Die Erkennung erfolgt am Gateway, bei der ersten Nutzung — nicht zur Installationszeit. Ein Tool, ein MCP-Server oder ein Skill, das ein Agent selbst installiert, wird das erste Mal abgefangen, wenn sein Aufruf das Gateway überquert. Das ist der eine Engpass, der jeden Anbieter, jeden Agenten und jeden Tool-Call sieht, ganz gleich, wie die Fähigkeit dorthin gelangt ist.

​
2. Ein konkretes Beispiel

Angenommen, Sie wollen destruktive Shell-Befehle blockieren, aber alles andere unter Audit durchlassen. In der Konsole erstellen Sie eine Policy mit default_verdict = audit und einer Regel: 
{
  "label": "block rm -rf",
  "tool_name_glob": "*.exec",
  "args_match_json": "{\"clauses\":[{\"path\":\"$.command\",\"op\":\"regex\",\"value\":\"rm -rf|drop table\"}]}",
  "verdict": "deny"
}
args_match_json ist ein JSON-kodierter String (das Gateway validiert ihn beim Speichern gegen das Klausel-Schema): path ist ein JSONPath in die Argumente des Aufrufs, op ist einer von eq, contains, regex, in, cidr_match, gt, lt. Hängen Sie einen Key an die Policy an (setzen Sie firewall_policy_id auf dem Key). Wenn ein Agent nun shell.exec mit command: "rm -rf /" ausgibt, gibt das Gateway HTTP 400 mit dem Fehlercode firewall_blocked und einem Grund zurück, der das Tool benennt — und der Aufruf erreicht die Shell nie. Jeder andere Tool-Call wird erlaubt und zur Überprüfung aufgezeichnet.
Rollen Sie eine neue Policy zuerst unter Shadow-Mode aus: Sie wertet aus und loggt genau so, wie sie es in Produktion täte, aber jedes durchsetzende Verdikt wird auf audit herabgestuft und dem Grund wird [shadow] would … vorangestellt. Beobachten Sie den Events-Feed, schalten Sie dann den Shadow-Mode aus, um durchzusetzen.

​
3. Policy, Regeln und Auflösung

Eine Policy ist workspace-bezogen und benannt, mit enabled, is_default, einem default_verdict (allow / audit / deny, Default audit) und einem shadow_mode-Flag. Eine Regel ist eine Prüfung darin — siehe Eine Policy erstellen und Regel-Schema. Für jeden Tool-Call löst das Gateway die aktive Policy in dieser Reihenfolge auf:
  1. Key-Bindung — die firewall_policy_id des aufrufenden Keys, sofern diese Policy existiert und aktiviert ist.
  2. Workspace-Default — andernfalls die aktivierte is_default-Policy.
Eine deaktivierte angehängte Firewall-Policy fällt auf den Workspace-Default zurück — das unterscheidet sich von Guardrails, wo eine deaktivierte Bindung auf keine aufgelöst wird. Der Aus-Schalter an der Firewall eines Keys bedeutet „verwende den Default”, nicht „keine Durchsetzung”. Siehe Policies verwalten.
Wenn überhaupt keine Policy aufgelöst wird, hängt das Verhalten von der Workspace-Einstellung firewall_observe_mode ab: mit Observe-Mode an wird der Aufruf erlaubt, aber als Abdeckungs-Lücke geloggt (er taucht in Discovered Tools auf); mit ihm aus wird der Aufruf stillschweigend erlaubt.

​
4. Verdikte

Eine Regel — oder der Default — erzeugt eines von:
VerdiktWas es tut
allowDurchlassen, geloggt.
auditErlauben + zur Überprüfung aufzeichnen. Der übliche Default.
denyBlockieren. HTTP 400 firewall_blocked auf inbound; Tool-Fehler auf MCP.
sanitizeGematchte Teilstrings aus den Tool-Argumenten redigieren und weiterleiten.
pending_approvalFür einen Menschen zurückhalten; HTTP 400 firewall_approval_pending.
cap_costAblehnen, sobald die Ausgaben des Runs eine Pro-Regel-Obergrenze überschreiten.
Ein sanitize-Verdikt redigiert nur die Aufruf-Argumente — nie den Inhalt, den ein Tool zurückgibt. Auf der inbound-Surface, wo es noch keine Aufruf-Argumente gibt, eskaliert sanitize zu einem Block. Siehe Verdikte und Antworten bereinigen.

​
5. Die vier Enforcement-Surfaces

Jeder Tool-Call wird gegen genau eine Surface ausgewertet — pinnen Sie eine Regel mit dem stage-Feld auf eine, oder lassen Sie es leer, damit sie auf alle zutrifft.

inbound

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.

response

Die tool_calls, die das Modell in seiner Antwort ausgibt.

mcp

Ein tools/call, der durch das MCP-Gateway dispatcht wird. Siehe MCP-Server.

egress

Ein ausgehender Host / IP / CIDR, den ein Tool erreicht — die SSRF- und Datenexfiltrations-Surface.

​
6. Matching

Regeln drücken aus, welche Tool-Calls sie abfangen, mit einem kleinen, deterministischen Vokabular, das auf dem heißen Pfad sicher ist:
Ein case-sensitiver Glob auf den Tool-Namen (shell.*, *.delete), optional UND-verknüpft mit einem Glob auf den besitzenden Skill. Siehe Glob-Syntax und Tool-Allow-Listing.
JSONPath-Prädikate über die Argumente des Aufrufs mit den Operatoren eq, contains, regex, in, cidr_match, gt, lt — der Unterschied zwischen „blockiere shell.exec” und „blockiere es nur, wenn der Befehl rm -rf ist”. Klauseln failen closed (die Regel, nicht der Request). Siehe Argumente validieren.
Host- / IP- / CIDR-Allow- und Deny-Listen auf der egress-Surface. Sie können Ihre eigene Deny-Regel für Cloud-Metadata- oder RFC-1918-Bereiche verfassen. Siehe Egress-Steuerung.
Eine sequence-Regel matcht eine geordnete Kette von Aufrufen über ein Fenster (reaktiv durchgesetzt); eine cap_cost-Regel lehnt ab, sobald die kumulierten Ausgaben eines Agentenlaufs eine Cent-Obergrenze überschreiten. Siehe Sequenzregeln und Kosten begrenzen.

​
7. Menschliche Freigabe, Autonomie und Anomalien

  • Human-in-the-loop. Ein pending_approval-Verdikt hält den Aufruf zurück und gibt seine Approval-ID zurück. Ein Prüfer löst es in der Konsole (Developer+) oder über einen HMAC-signierten Webhook-Callback auf; der Agent pollt und reicht mit einem einmal nutzbaren X-OrcaRouter-Firewall-Approval-Header erneut ein. Siehe Freigaben und Approval-Webhook.
  • Autonomie-Stufen. Ein Schalter setzt Ihre gesamte Haltung: tight (Default-Deny + destruktive Shell ablehnen + abruf-förmige Tools ablehnen (http_fetch/web_search/fetch_url/request, der SSRF-Vektor) + PII Shield + Secrets Blocker durchgesetzt), balanced (Default audit, destruktive Shell ablehnen, PII Shield nur auditieren) oder permissive (nur beobachten). Jede schreibt echte, editierbare Policy- und Guardrail-Zeilen, mit Ein-Klick-Undo aus dem Audit-Snapshot.
  • Anomalieerkennung. Über statische Regeln hinaus bewertet die Firewall die Tool-Nutzung gegen eine gelernte Hour-of-week-Baseline (14 Tage) und flaggt Raten-/Kosten-Spikes, retry_loop und novel_path auf einem Member-lesbaren Feed, den Sie bis zu 7 Tage snoozen können.

​
8. Wo die Firewall hineinpasst

Die Firewall ist das Aktionsebenen-Pendant zweier benachbarter Ebenen:
EbeneSteuertWann Sie dazu greifen
GuardrailsPrompt- & Response-TextPII, Secrets, Jailbreaks, Injection-Absicht
Agent-FirewallTool-AktionenWelche Tools, MCP-Calls, Hosts und Kosten
ComplianceNachweise & FrameworksSOC-2- / HIPAA- / EU-AI-Act-Bereitschaft
Sowohl die Inhalts- als auch die Aktionsebene können auf eine einzige Anfrage zutreffen, und eine Autonomie-Stufe konfiguriert sie zusammen. Siehe Guardrails vs. Firewall und den Control-Stack.

​
9. Anhängen und Verbinden

Eine Policy bindet sich via firewall_policy_id an einen Key (in der Konsole konfiguriert; die Bindung lebt am Key im Gateway). Zwei Wege, auf denen ein Tool-Call die Engine erreicht, beide einen firewall-gateway-scoped Key erfordernd (is_firewall_gateway = true) — ein regulärer Relay-Key erhält auf diesen Routen 403:
  • MCP-Gateway — richten Sie Ihren MCP-Client auf den vereinheitlichten Endpunkt ANY /api/v1/firewall/mcp; jeder tools/call wird inline ausgewertet. Siehe MCP-Server.
  • Evaluate-Hook — rufen Sie POST /api/v1/firewall/evaluate (oder /evaluate_plan für einen mehrstufigen Plan) aus Ihrer eigenen Agenten-Schleife auf, bevor Sie dispatchen, und handeln Sie nach dem Verdikt.
Alle Konsolen-Konfiguration läuft unter Ihrer Session über /api/workspace/firewall/*. Lesezugriffe auf Policies, Einstellungen, Discovered Tools, den schreibgeschützten Autonomie-Simulator und den Anomalie-Feed sind für jedes Workspace-Mitglied offen; die Dry-Run-Test-Sandbox, das Events-/Runs-Log und alle Schreibvorgänge erfordern Developer+. Siehe Gateway-Keys und Regeln testen.

​
10. Bedrohungen, die diese Ebene adressiert

Gefährliche Tool-Calls

Destruktive Shell, DB-Drops und riskante Verben per Glob + Args ablehnen.

Datenexfiltration

Egress-Listen und Read-then-Export-Sequenzregeln.

MCP-Tool-Poisoning

Pro-Aufruf-Auswertung auf der mcp-Surface vor dem Dispatch.

Übermäßige Handlungsmacht

Freigaben, Kosten-Caps und Default-Deny-Haltung.

​
Nächste Schritte

Eine Policy erstellen

Verfassen Sie Ihre erste Policy und Regel.

Verdikte

Was jedes Verdikt auf der Leitung tut.

Events-Log

Lesen Sie, was die Firewall entschieden hat und warum.