Zum Hauptinhalt springen
Wenn ein Agent gekapert wird — Prompt-Injection, ein vergiftetes Tool-Ergebnis, eine außer Kontrolle geratene Schleife — ist das, was er tatsächlich tun kann, durch genau eine Sache begrenzt: was sein API-Key tun durfte. Ein Schlüssel ohne Limits und ohne Policy verwandelt einen kompromittierten Agenten in einen workspace-weiten Vorfall. Diese Seite ist der Härtungs-Durchgang, den Sie gegen jeden Schlüssel ausführen, bevor er ausgeliefert wird, und erneut in einer Taktung danach. Sie ist bewusst kurz: eine Checkliste, ein durchgespieltes Beispiel, dann Links zur Tiefe für jedes Feld. Für das mentale Modell dahinter starten Sie mit Scope & Schlüssel; für die Feld-für-Feld-Referenz siehe die Schlüssel-Übersicht.

​
1. Die Least-Agency-Checkliste

Schicken Sie jeden Schlüssel — neu oder bestehend — durch diese sechs Tore im Schlüssel-Editor (/console/token). Eines davon zu setzen erfordert die Rolle Developer oder höher; die beiden Policy-Ebenen (§5–6) werden separat verfasst und hier gebunden.
Setzen Sie model_limits auf die exakte Liste, die dieser Agent braucht (und aktivieren Sie model_limits_enabled). Ein Aufruf an irgendein Modell außerhalb der Liste wird abgelehnt, bevor er das Gateway verlässt, sodass ein gekaperter Agent nicht zu einem teureren oder fähigeren Modell eskalieren kann. Prüfung: Ist die Liste so kurz, wie der Job erlaubt — idealerweise ein Modell? Tiefe: Modell-Limits.
Setzen Sie allow_ips auf die Quelladressen oder CIDR, von denen der Agent tatsächlich aufruft. Ein geleakter Schlüssel, der von irgendwo sonst präsentiert wird, wird auf der Auth-Ebene abgelehnt. Leer bedeutet, dass alle IPs erlaubt sind. Prüfung: Ist die Liste für einen Agenten mit festem Host oder geplanten Agenten nicht-leer und auf diesen Egress gefasst? Tiefe: IP-Allowlist.
Setzen Sie credit_limit_usd auf eine Obergrenze, die der Agent in seiner Lebenszeit nie überschreiten sollte. Das Gateway setzt es gegen die Ausgaben des Schlüssels durch. 0 bedeutet unbegrenzt — eine außer Kontrolle geratene Schleife kann Ihr ganzes Guthaben leeren. Prüfung: Ist das Cap ein echtes Budget, nicht 0? Tiefe: Kontingent, Cap & Ablauf.
Setzen Sie expired_time auf einen absoluten Ablauf — das Ende des Sprints, des Deployments oder des CI-Laufs. -1 bedeutet läuft nie ab. Ein kurzlebiger Schlüssel kann nicht als vergessene Angriffsfläche herumhängen. Prüfung: Hat ein ephemerer oder Auftragnehmer-Schlüssel einen echten Ablauf, nicht -1? Tiefe: Ablaufende Schlüssel.
Hängen Sie ein Guardrail via guardrail_id an, sodass der Text des Requests (und, wo unterstützt, der Antwort) auf PII, Secrets und Injection-Intent geprüft wird, bevor er das Modell erreicht. Prüfung: Hat ein Schlüssel, der sensible Prompts verarbeitet, ein gebundenes Guardrail oder erbt er einen Workspace-Default? Siehe §5.
Hängen Sie eine Firewall-Policy via firewall_policy_id an, sodass jeder Tool-Call, MCP-Dispatch und Egress, den dieser Schlüssel ausgibt, gegen eine Allowlist dessen ausgewertet wird, was der Agent legitim braucht. Prüfung: Hat ein Agent, der Tools aufruft, eine gebundene Firewall-Policy oder erbt er den Workspace-Default? Siehe §6.
Die Felder oben sind die einzigen kundenkonfigurierbaren Hebel auf einem Schlüssel — setzen Sie sie alle in der Konsole; nichts hier erfordert eine Änderung im Agenten-Code. Einen Schlüssel zurückzulesen zeigt ihn maskiert; der Klartext wird einmal bei der Erstellung gezeigt. Siehe Schlüsselmaskierung.

​
2. Was / wie oft / wo

Drei Fragen verwandeln die Checkliste aus einer einmaligen Pflicht in eine Haltung.

Was

Die sechs Tore oben, in Reihenfolge: model_limits → allow_ips → credit_limit_usd → expired_time → guardrail_id → firewall_policy_id.

Wie oft

Auf jedem Schlüssel bei der Erstellung und in einer wiederkehrenden Überprüfung — wenn sich der Scope eines Agenten ändert, wenn Sie einen Schlüssel rotieren und in einer festen Taktung für langlebige Schlüssel.

Wo

Im Konsolen-Schlüssel-Editor (/console/token), als Developer+. Die beiden Policies werden in ihren eigenen Konsolen verfasst, dann auf dem Schlüssel gebunden.

​
3. Ein konkreter Least-Agency-Schlüssel

Ein geplanter Agent, der Support-Tickets mit einem billigen Modell, von einem Host, zusammenfasst, braucht fast keine Agency. Ein voll gehärteter Schlüssel:
FeldWertWarum
model_limitsein Summarization-Modellkann nicht zu einem Frontier-Modell eskalieren
allow_ipsdas Egress-CIDR des Schedulersein geleakter Schlüssel ist anderswo nutzlos
credit_limit_usdeine wöchentliche Obergrenzeeine außer Kontrolle geratene Schleife kann das Guthaben nicht leeren
expired_timeEnde des Deploymentsläuft automatisch ab, kann nicht herumhängen
guardrail_idein PII-maskierendes Guardrailder Request-Text wird geprüft
firewall_policy_idallowlistet nur seine Toolskeine überraschenden Tool-Calls
Wenn dieser Agent gekapert wird, kann er immer noch nur ein Modell aufrufen, nur aus einem IP-Bereich, nur bis zu seinem Cap und nur die Tools, die seine Firewall-Policy erlaubt. Der Rest des Workspaces bleibt unberührt — und der Firewall-Audit-Trail zeigt genau, wozu er autorisiert war.
Ein Schlüssel ohne model_limits, ohne allow_ips, credit_limit_usd: 0, expired_time: -1 und ohne Policy-Bindung hat maximale Agency. Wenn er leakt, bekommt der Inhaber Ihren vollen Workspace. Behandeln Sie diese Kombination als Erkenntnis, nicht als Default — siehe unbegrenzt vs. begrenzt.

​
4. Der /v1-Relay-Aufruf vs. die Konsole

Die Checkliste wird in der Konsole mit Ihrer Session (einem Developer+-Benutzer) konfiguriert. Ihr Agent fasst diese Konfigurationsrouten nie an — er präsentiert seinen scoped Relay-Schlüssel (sk-orca-…) auf den /v1/*-Inferenz-Aufrufen, und die Limits und gebundenen Policies oben werden auf jedem davon durchgesetzt. 
# Der Runtime-Aufruf des Agenten — der Relay-Schlüssel, gefasst durch die Checkliste oben.
curl https://api.orcarouter.ai/v1/chat/completions \
  -H "Authorization: Bearer sk-orca-..." \
  -H "Content-Type: application/json" \
  -d '{
    "model": "openai/gpt-4o-mini",
    "messages": [{"role": "user", "content": "Summarize this ticket..."}]
  }'
Wenn die model_limits des Schlüssels openai/gpt-4o-mini nicht enthalten, wird dieser Aufruf abgelehnt, bevor er das Gateway verlässt. Wenn die IP des Aufrufers nicht in allow_ips ist, wird er auf der Auth-Ebene abgelehnt. Der Agenten-Code bleibt gleich; der Schlüssel entscheidet den Blast-Radius.

​
5. Tor 5 — das gebundene Guardrail

guardrail_id bindet eine workspace-bezogene, geordnete Content-Policy an den Schlüssel. Die Auflösung ist das explizite Guardrail des Schlüssels (wenn es existiert und aktiviert ist), sonst der Workspace-Default, sonst keines.
Guardrails sind ein strikter Aus-Schalter, wenn deaktiviert: Eine deaktivierte oder gelöschte guardrail_id bedeutet, dass der Schlüssel kein Guardrail bekommt — er fällt nicht auf den Workspace-Default zurück. Das ist das Gegenteil der Firewall-Ebene (§6), also verifizieren Sie, dass das gebundene Guardrail aktiviert ist, nicht nur angehängt.
Die Regeln eines Guardrails laufen vor dem Modell (Input-Stage) und, wo unterstützt, auf der Antwort (Output-Stage), mit den Aktionen block, mask oder flag. Das PII Shield-Preset zum Beispiel maskiert PII im Request, bevor er je das Modell erreicht. Verfassen und hängen Sie Guardrails als Developer+ an — siehe Guardrails und Policies binden.

​
6. Tor 6 — die gebundene Firewall-Policy + Gateway-Scope

firewall_policy_id bindet eine workspace-bezogene Tool-Call-Policy. Sie steuert die Aktionen, die ein Agent vornimmt — angebotene Tools, modell-ausgegebene tool_calls, MCP-Dispatches und ausgehender Egress — gegen eine geordnete Regelliste, deren Verdikte allow, audit, deny, sanitize, pending_approval oder cap_cost sind.
Die Firewall-Ebene löst anders auf als Guardrails: Eine deaktivierte gebundene Firewall-Policy fällt auf den Workspace-Default zurück, sie schaltet die Durchsetzung nicht aus. Eine Policy zu binden und sie zu deaktivieren setzt den Schlüssel also auf den Workspace-Default zurück — er geht nie still ungeschützt.
Der schnellste Weg, beide Ebenen auf einmal zu setzen, ist eine Autonomie-Stufe — ein einzelner Schalter, der die Firewall- und Guardrail-Haltung Ihres Workspaces atomar konfiguriert (tight / balanced / permissive), mit Ein-Klick-Undo. Siehe Firewall §8.
is_firewall_gateway ist eine separate Art von Schlüssel — nur für die Firewall-MCP- und Evaluate-Hook-Routen (/api/v1/firewall/*) geprägt, nie für Inferenz. Ein regulärer Schlüssel bekommt auf diesen Routen 403, und ein Gateway-Schlüssel auf dem Inferenz-Pfad ist überfasst. Das Flag zu aktivieren und den Klartext eines Gateway-Schlüssels zu lesen, erfordert Admin+. Ein Schlüssel, ein Zweck.

​
7. Nach der Checkliste

Secure-Agents-Baseline

Die empfohlene Ausgangshaltung — ein Autonomie-Schalter, dann von echtem Traffic aus tunen.

Policies binden

Wie guardrail_id und firewall_policy_id anhängen und auflösen.

Übermäßige Agency

Die Bedrohung, die diese Checkliste einzudämmen gebaut ist.

Geleakter Schlüssel

Was zu tun ist in dem Moment, in dem ein scoped Key exponiert wird.
Je enger jeder Schlüssel, desto kleiner der Blast-Radius, wenn irgendein Agent kompromittiert wird — und desto klarer der Datensatz dessen, wozu jeder Agent autorisiert war. Führen Sie die Least-Agency-Checkliste auf jedem Schlüssel aus, und führen Sie sie weiter aus.