Zum Hauptinhalt springen
Sie haben einen Key, den Ihr Agent auf api.orcarouter.ai verwendet, und Sie möchten, dass jeder Tool-Call, den dieser Key macht, gesteuert wird — blockiert, auditiert, bereinigt oder zur Freigabe zurückgehalten — ohne Ihren Agenten-Code anzufassen. Das ist eine zweistufige Agent-Firewall-Einrichtung: Erstellen Sie eine Firewall-Policy einmal, richten Sie dann den Key darauf aus. Ab dem nächsten Aufruf wird jedes Tool, das der Key ausgibt, am Gateway gegen die Policy geprüft. Diese Seite ist der Erstellen-und-Anhängen-Pfad. Für das vollständige Policy-Modell (Surfaces, Verdikte, Auflösung) siehe den Firewall-Überblick; für die Regel-Grammatik siehe Firewall-Regeln.
Alle Policy- und Key-Konfiguration erfolgt in der Konsole (oder über die /api/workspace/firewall/*-Management-Routen, die Ihre Session bzw. Ihr Access-Token verwenden — nicht einen Relay-sk-orca-…-Key). Nur die /v1/*-Aufrufe Ihres Agenten verwenden den Relay-Key. Das Erstellen und Anhängen einer Policy ist eine Developer+-Aktion.

​
1. Agent-Firewall-Einrichtung auf einen Blick

Eine Firewall-Policy ist ein benanntes, workspace-bezogenes Objekt: eine geordnete Liste von Regeln plus ein Default-Verdikt für alles, was keine Regel matcht. Ein Key meldet sich über sein firewall_policy_id-Feld bei einer Policy an. Nichts anderes in Ihrem Stack ändert sich.

Die Policy erstellen

Benennen Sie sie, wählen Sie ein Default-Verdikt, fügen Sie Regeln hinzu — oder seeden Sie aus einer Autonomie-Stufe / einem Preset und editieren Sie.

Einen Key anhängen

Setzen Sie die firewall_policy_id des Keys auf die Policy, oder markieren Sie die Policy als Workspace-Default, sodass jeder nicht angehängte Key sie erbt.

​
2. Eine Policy in der Konsole erstellen

  1. Öffnen Sie Security → Firewall → Policies und wählen Sie New policy.
  2. Benennen Sie sie (workspace-eindeutig) und lassen Sie Enabled an.
  3. Wählen Sie ein Default-Verdikt — siehe §3.
  4. Fügen Sie Regeln im Regel-Editor hinzu, oder starten Sie leer und lassen Sie Discovered Tools später das Verfassen aus echtem Traffic treiben.
  5. Speichern. Die Policy existiert, steuert aber nichts, bis ein Key auf sie zeigt oder Sie sie zum Workspace-Default machen.
Sie möchten nicht zuerst von Hand Regeln verfassen? Wenden Sie eine Autonomie-Stufe an (balanced ist der empfohlene Start) — sie materialisiert echte, editierbare Policy- und Guardrail-Zeilen, die Sie dann tunen können. Oder starten Sie eine Regel aus einem eingebauten Preset und editieren Sie sie. So oder so landen Sie am selben Ort: einer benannten Policy, die Sie an einen Key anhängen.

​
3. Das Default-Verdikt wählen

Das Default-Verdikt ist, was die Policy tut, wenn keine Regel auf einen Tool-Call matcht. Es ist der Boden Ihrer Haltung. Es akzeptiert genau drei Werte:
default_verdictWenn keine Regel matcht…
audit (Default)Den Aufruf erlauben, aber aufzeichnen. Alles beobachten, nichts blockieren — der sichere Ausgangspunkt.
allowErlauben und loggen, kein Überprüfungs-Datensatz.
denyAlles blockieren, was eine Regel nicht explizit erlaubt — eine Default-Deny-Haltung, die Sie mit Allow-Regeln paaren.
deny ist Default-Deny: Jeder Tool-Call, den Ihre Regeln nicht explizit erlauben, wird blockiert. Mächtig, aber es wird Aufrufe stoppen, die Sie zu allow-listen vergessen haben. Rollen Sie eine Default-Deny-Policy zuerst unter Shadow-Mode aus und beobachten Sie den Events-Feed, bevor Sie sie durchsetzen.
Verdikte, die eine Regel erzeugen kann (allow, audit, deny, sanitize, pending_approval, cap_cost), werden in Verdikte behandelt — das Default-Verdikt ist auf die drei obigen beschränkt.

​
4. Die Policy an einen Key anhängen

Ein Key meldet sich über seine firewall_policy_id bei einer Policy an. In der Konsole:
  1. Öffnen Sie Keys, editieren Sie den Key, den Ihr Agent verwendet.
  2. Setzen Sie Firewall policy auf die Policy, die Sie erstellt haben (dies schreibt firewall_policy_id).
  3. Speichern. Der nächste Aufruf, den dieser Key macht, wird gesteuert.
Die Bindung lebt am Key, im Gateway — Ihr Agent sendet weiterhin dasselbe Authorization: Bearer sk-orca-… und denselben Request-Body. Es gibt keine Änderung am Tool-Calling-Code Ihres Agenten. 
# Der Relay-Aufruf Ihres Agenten ist unverändert. Die angehängte Policy wird
# am Gateway durchgesetzt, bevor ein Tool-Call in der Antwort dispatcht wird.
curl https://api.orcarouter.ai/v1/chat/completions \
  -H "Authorization: Bearer sk-orca-..." \
  -H "Content-Type: application/json" \
  -d '{
    "model": "gpt-4o",
    "messages": [{"role": "user", "content": "delete the staging table"}],
    "tools": [{"type": "function", "function": {"name": "db.query"}}]
  }'
Wenn eine Regel einen Tool-Call auf der inbound-Surface ablehnt, kommt dieser Aufruf als HTTP 400 mit dem Code firewall_blocked zurück, der das Tool und den Grund benennt — siehe wie ein Block aussieht.

​
5. Auflösung: angehängt → Workspace-Default

Für jeden Tool-Call löst das Gateway in dieser Reihenfolge auf, welche Policy gilt:
Wenn die firewall_policy_id des aufrufenden Keys auf eine Policy zeigt, die existiert und aktiviert ist, gilt diese Policy.
Andernfalls gilt die aktivierte is_default-Policy des Workspaces (sofern eine gesetzt ist). Höchstens eine Policy pro Workspace kann der Default sein; das Promoten eines neuen Defaults degradiert den alten in derselben Transaktion.
Keine Bindung und kein Default bedeutet keine Policy. Mit Observe-Mode an wird der Aufruf erlaubt und als Abdeckungslücke geloggt; mit ihm aus wird der Aufruf stillschweigend erlaubt.
Eine deaktivierte angehängte Policy fällt auf den Workspace-Default zurück — sie schaltet die Durchsetzung nicht ab. (Das unterscheidet sich von Guardrails, wo eine deaktivierte Bindung auf keine aufgelöst wird.) Um einen Key aus dem Firewall-Scope zu nehmen, lösen Sie ihn ab (setzen Sie firewall_policy_id auf 0), deaktivieren Sie nicht nur seine Policy.
Um eine Policy zum Default für jeden nicht angehängten Key zu machen, editieren Sie sie und setzen Sie sie als Workspace-Default, statt Keys einzeln anzuhängen — siehe Policies verwalten.

​
6. Verifizieren, dass es wirkt

Bevor Sie sich darauf verlassen, bestätigen Sie, dass die Policy so feuert, wie Sie es erwarten:
  • Testen Sie es — der Sandbox-Tab Test dry-runnt die Policy gegen einen Beispiel-Tool-Call und gibt das Verdikt, die gematchte Regel und den Grund zurück. Nichts wird dispatcht oder persistiert. Siehe Regeln testen.
  • Beobachten Sie den Events-Feed — sobald der Key Live-Traffic nimmt, zeigt Events jede Auswertung, filterbar nach Verdikt, Surface, Tool und Run.
Rollen Sie jede durchsetzende Policy zuerst hinter Shadow-Mode aus: Sie wertet aus und loggt genau so, wie sie es in Produktion täte, stuft aber jedes durchsetzende Verdikt auf audit herab und stellt dem Grund [shadow] would … voran. Schalten Sie den Shadow-Mode aus, sobald der Events-Feed zeigt, dass sie auf das feuert, was Sie erwarten, und auf nichts, was Sie nicht erwarten.

​
Wohin als Nächstes

Regeln verfassen

Die vollständige Matching-Sprache — Tool-Globs, Argument-Klauseln, Egress-Listen, Sanitizer.

Tool-Allow-Listing

Paaren Sie ein deny-Default-Verdikt mit expliziten Allow-Regeln.

Policies verwalten

Defaults, aktivieren/deaktivieren, Versionierung und Revert.

Warum Zero Trust

Warum das Steuern von Aktionen — nicht nur von Text — für Agenten zählt.
Für die Bedrohungen, die eine Policy stoppen soll, siehe gefährliche Tool-Calls und übermäßige Handlungsmacht.