Zum Hauptinhalt springen
Sie haben ein Guardrail und eine Firewall-Policy für Ihren Workspace verfasst. Jetzt möchten Sie, dass dieser eine Schlüssel — der, den Ihr Finanz-Agent verwendet — eine strengere Content-Policy und eine engere Tool-Allowlist ausführt als der Rest des Workspaces. Genau das tun die beiden Bindungsfelder auf einem Schlüssel: Binden Sie ein Guardrail und eine Firewall-Policy an einen einzelnen Schlüssel, und jeder Request, den dieser Schlüssel stellt, wird von exakt diesen Policies geprüft und durchgesetzt — keine Änderung im Agenten-Code, kein Redeploy. Diese Seite behandelt die beiden Felder, wie sie zur Request-Zeit aufgelöst werden, und die eine Auflösungsregel, die die Leute erwischt: Eine deaktivierte Firewall-Bindung verhält sich anders als eine deaktivierte Guardrail-Bindung.

​
1. Die Pro-Schlüssel-Sicherheits-Policy: zwei Felder auf einem Schlüssel

Ein Guardrail prüft den Text, der durch ein Modell fließt (PII, Secrets, Jailbreaks). Eine Firewall-Policy steuert die Tool-Calls, die ein Agent ausgibt (welche Tools, welche MCP-Server, welche Hosts). Beide sind workspace-bezogene, benannte Policies — einmal verfasst, über den Workspace hinweg geteilt — und ein Schlüssel opt-in auf eine bestimmte über zwei Felder:
FeldBindetSetzt in der Konsole
guardrail_idDas Guardrail, das die Prompts und Antworten dieses Schlüssels prüft.Developer+
firewall_policy_idDie Firewall-Policy, die die Tool-Calls dieses Schlüssels auswertet.Developer+
Beide werden im Schlüssel-Editor unter /console/token gesetzt. Eines von beiden zu setzen ist eine Developer+-Aktion — die Policies selbst werden ebenfalls Developer+ verfasst (siehe Scope & Schlüssel).
Diese beiden Felder sind unabhängig. Ein Schlüssel kann ein Guardrail anhängen und keine Firewall-Policy, umgekehrt, beides oder keines — jede Ebene löst für sich selbst auf. Ein Feld ungesetzt zu lassen (0) ist nicht dasselbe wie die Durchsetzung auszuschalten; siehe §3.

​
2. Ein konkretes Beispiel

Angenommen, Ihr Workspace-Default-Guardrail markiert PII, lässt sie aber durch, und die Default-Firewall-Policy auditiert jeden Tool-Call. Das ist für die meisten Agenten in Ordnung — aber Ihr Finanz-Agent verarbeitet Kunden-SSNs und sollte niemals ein Shell-Tool aufrufen. Verfassen Sie ein strengeres finance-guardrail (blockiert PII rundheraus) und eine finance-firewall (allowlistet nur die drei Tools, die es braucht), binden Sie dann beide an den Schlüssel dieses Agenten: 
# Über die KONSOLE konfigurieren (UserAuth — Ihre Session), nicht über einen Relay-Schlüssel.
# Dies ist der Schlüssel-Update-Aufruf, den der Editor unter /console/token macht.
PUT /api/token
{
  "id": 4127,
  "name": "finance-agent",
  "guardrail_id": 12,          // finance-guardrail (PII = block)
  "firewall_policy_id": 8      // finance-firewall (3-Tool-Allowlist)
}
Vom nächsten Request an wird der Traffic dieses Schlüssels von Guardrail 12 geprüft und seine Tool-Calls von Policy 8 ausgewertet — während jeder andere Schlüssel im Workspace weiterhin die Workspace-Defaults ausführt. Der Code des Agenten selbst ändert sich nie; er ruft weiterhin https://api.orcarouter.ai/v1/... mit seinem sk-orca-…-Schlüssel genau wie zuvor auf.
Dies ist das Least-Agency-Muster: ein eng gefasster Schlüssel pro Agent, jeder an die Policies gebunden, die sein Job tatsächlich braucht. Wenn dieser Agent kompromittiert wird, ist der Blast-Radius das, wozu sein Schlüssel autorisiert war — nichts darüber hinaus. Siehe die Least-Agency-Checkliste.

​
3. Auflösung: die Regel, die die Leute erwischt

Für jeden Request löst das Gateway das aktive Guardrail und die aktive Firewall-Policy unabhängig auf. Die Reihenfolge sieht für beide gleich aus — Bindung zuerst, Workspace-Default als Zweites — aber sie divergieren in einem Fall.

​
Guardrail-Auflösung

Die guardrail_id des Schlüssels zeigt auf ein Guardrail, das existiert und aktiviert ist. Dieses Guardrail prüft den Request.
Das Deaktivieren des gebundenen Guardrails ist ein Aus-Schalter. Der Schlüssel bekommt kein Content-Screening — er fällt nicht auf den Workspace-Default zurück. Das ist beabsichtigt: Ein Guardrail anzuhängen und es zu deaktivieren ist die Art, wie Sie das Screening für diesen Schlüssel ausschalten.
Keine guardrail_id auf dem Schlüssel. Das aktivierte Default-Guardrail des Workspaces gilt, sofern eines gesetzt ist.
Keine Bindung und kein Workspace-Default → der Request passiert ohne Content-Screening.

​
Firewall-Auflösung

Die firewall_policy_id des Schlüssels zeigt auf eine Policy, die existiert und aktiviert ist. Diese Policy wertet die Tool-Calls des Schlüssels aus.
Hier ist der Unterschied. Eine deaktivierte Firewall-Bindung fällt auf die Default-Firewall-Policy des Workspaces zurück — sie schaltet die Durchsetzung nicht aus. Das Deaktivieren einer Firewall-Bindung setzt den Schlüssel auf den Workspace-Default zurück; es lässt den Schlüssel nicht ungeschützt.
Keine firewall_policy_id auf dem Schlüssel → die aktivierte Default-Firewall-Policy des Workspaces gilt.
Das Deaktivieren einer gebundenen Policy ist nicht symmetrisch. Eine deaktivierte Guardrail-Bindung bedeutet kein Guardrail für diesen Schlüssel. Eine deaktivierte Firewall-Bindung bedeutet Rückfall auf den Workspace-Default. Wenn Sie wollen, dass ein Schlüssel echt keine Firewall-Durchsetzung ausführt, kommen Sie dort nicht hin, indem Sie seine Bindung deaktivieren — stellen Sie sicher, dass keine Default-Firewall-Policy für den Workspace gesetzt ist (oder fassen Sie den Schlüssel so, dass er keine gesteuerten Tool-Calls ausgibt).
Höchstens ein Guardrail und eine Firewall-Policy pro Workspace können zu jedem Zeitpunkt der Default sein; das Promoten eines neuen Defaults degradiert den alten in derselben Transaktion, sodass Sie nie versehentlich zwei haben können.

​
4. Wie ein Block aussieht

Wenn eine gebundene Policy einen Request ablehnt, sieht der Aufrufer einen strukturierten Fehler — der Agent kann reagieren, statt abzustürzen:
EbeneFehlercodeHTTPKosten
Guardrailguardrail_blocked400Keine — ein Input-Block feuert vor der Abrechnung; ein Output-Block erstattet zurück. Als skip-retry markiert.
Firewall (inbound)firewall_blocked400Ein inbound-Block feuert vor dem Modellaufruf, also keine Modell-Tokens. Skip-retry.
Firewall (zurückgehalten)firewall_approval_pending400Für menschliche Freigabe zurückgehalten; der Agent pollt und reicht erneut ein, sobald genehmigt.
Beide Fehler-Bodys sind OpenAI-förmig und benennen die Policy und den Grund, sodass Ihr Agent auf den Code verzweigen kann. Siehe die ausführlichen Referenzen für den vollständigen Event-Datensatz und wie Matches geloggt werden.

​
5. Wohin als Nächstes

Scope & Schlüssel

Das vollständige Drei-Ebenen-Modell — Workspace, Policy, Schlüssel — und jedes Feld, das ein Schlüssel trägt.

Das Token-Objekt

Jedes Feld auf einem Schlüssel: model_limits, allow_ips, credit_limit_usd, expired_time und die beiden Policy-Bindungen.

Guardrails

Verfassen Sie die Content-Policy, die Sie via guardrail_id binden — Regeln, PII-Entitäten, Aktionen und Presets.

Firewall

Verfassen Sie die Tool-Call-Policy, die Sie via firewall_policy_id binden — Verdikte, Surfaces und Autonomie-Stufen.
Möchten Sie Ihre gesamte Workspace-Haltung in einem Zug setzen, statt Schlüssel einzeln zu binden? Eine Autonomie-Stufe schreibt beide Ebenen — Guardrails und Firewall — auf einmal. Hängen Sie dann strengere Policies an die wenigen Schlüssel an, die weiter gehen müssen als der Workspace-Default. Siehe Guardrails vs. Firewall.