Zum Hauptinhalt springen
Ein Schlüssel ohne Quellbeschränkung ist eine reine Bearer-Anmeldeinformation: Wer auch immer den String hält, kann ihn von überall präsentieren. Das allow_ips-Feld verwandelt einen Schlüssel in einen IP-Whitelist-API-Key — er funktioniert nur, wenn er von einer Quelladresse präsentiert wird, die Sie gelistet haben. Ein geleakter Schlüssel, der von der Kiste eines Angreifers, einem Residential-Proxy oder einem kompromittierten CI-Runner abgespielt wird, wird abgelehnt, bevor er ein Modell berührt. Dies ist die Quell-Bindungs-Hälfte von Least Agency: model_limits begrenzt, welche Modelle ein Schlüssel erreichen darf, und allow_ips begrenzt, von wo der Schlüssel präsentiert werden darf.

​
1. Was allow_ips tut

allow_ips hält eine Liste von Quelladressen oder CIDR-Bereichen. Bei jedem Request vergleicht OrcaRouter die Quell-IP des Aufrufers mit dieser Liste:
  • Match → der Request fährt fort zu Modell-Limit-, Kontingent- und Policy-Prüfungen.
  • Kein Match → der Request wird auf der Auth-Ebene mit HTTP 403 (access_denied) abgelehnt, vor jedem Upstream-Modellaufruf.
  • Leere Liste → keine Beschränkung; der Schlüssel wird von jeder Adresse akzeptiert.
Die Prüfung ist das erste Tor, das ein Schlüssel passiert, neben der Schlüsselgültigkeit — sie läuft vor Guardrails, vor der Firewall, vor der Abrechnung. Eine ungelistete Quelle erreicht nie Ihre Policies oder Ihr Guthaben.
Eine leere allow_ips bedeutet alle IPs erlaubt, nicht keine. Es leer zu lassen ist der unbeschränkte Default — pinnen Sie den Schlüssel fest, damit das Feld irgendetwas tut.

​
2. Akzeptierte Formate

Jeder Eintrag ist eine einzelne IP oder ein CIDR-Bereich. Mischen Sie beides frei; listen Sie einen Eintrag pro Zeile.

Einzelne Adresse

203.0.113.7 — genau ein Host. Am besten für einen Server mit fester IP oder ein NAT-Gateway mit einer stabilen Egress-Adresse.

CIDR-Bereich

203.0.113.0/24 — ein ganzer Block. Am besten für ein Cloud-Subnetz, einen VPN-Pool oder eine Autoscaling-Gruppe hinter einem Egress-CIDR.
Eine nackte IP matcht diese eine Adresse; ein CIDR matcht jede Adresse im Block. Sowohl IPv4- als auch IPv6-Literale parsen.
Pinnen Sie auf den engsten Bereich, der noch jeden legitimen Aufrufer abdeckt. Ein Host (/32) ist enger als ein /24; ein /24 ist enger als „überall”. Jedes Bit, das Sie fallen lassen, verbreitert die Menge der Orte, an denen ein geleakter Schlüssel noch funktioniert.

​
3. In der Konsole setzen

Setzen Sie allow_ips im Schlüssel-Editor unter /console/token. Das Erstellen oder Bearbeiten eines Schlüssels erfordert die Rolle Developer oder höher.
  1. Öffnen Sie Konsole → API-Keys und erstellen oder bearbeiten Sie einen Schlüssel.
  2. Geben Sie im Schlüssel-Editor Ihre vertrauenswürdigen Adressen im Feld IP-Allowlist ein — eine IP oder CIDR pro Zeile.
  3. Speichern. Die Beschränkung gilt beim nächsten Request, den der Schlüssel stellt — kein Redeploy, keine Änderung im Agenten-Code.
Verifizieren Sie die echte Quelladresse, die das Gateway sieht, bevor Sie einen Schlüssel zusperren. Wenn Ihr Agent hinter einem NAT, einem Load Balancer oder einem Egress-Proxy sitzt, ist die Adresse, die OrcaRouter beobachtet, dieser Egress-Hop — nicht die private IP des Agenten. Allowlisten Sie die Egress-Adresse und testen Sie aus der deployten Umgebung, bevor Sie ausliefern.

​
4. Ein konkretes Beispiel: ein geplanter Agent

Ein geplanter Job, der Tickets zusammenfasst, läuft nur aus einem Cloud-Subnetz. Pinnen Sie seinen Schlüssel auf dieses Subnetz, sodass die Anmeldeinformation anderswo nutzlos ist.
FeldWertEffekt
allow_ips203.0.113.0/24nur der Egress-Block des Schedulers kann diesen Schlüssel präsentieren
model_limitsein Summarization-Modellkann nicht zu einem Frontier-Modell eskalieren
credit_limit_usdeine wöchentliche Obergrenzeeine außer Kontrolle geratene Schleife kann das Guthaben nicht leeren
Der Relay-Aufruf selbst ist unverändert — er verwendet weiterhin den sk-orca-…-Schlüssel als Bearer-Token: 
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..."}]
  }'
Aus dem Inneren von 203.0.113.0/24 präsentiert, fährt der Aufruf fort. Spielen Sie genau denselben Request von irgendeiner anderen Adresse ab, und das Gateway gibt zurück: 
{
  "error": {
    "message": "您的 IP 不在令牌允许访问的列表中 (request id: ...)",
    "type": "orcarouter_api_error",
    "code": "access_denied"
  }
}
Das Modell wird nie aufgerufen, kein Kontingent wird verausgabt, und die Ablehnung wird geloggt.
allow_ips wird vollständig über den Konsolen-Schlüssel-Editor konfiguriert — eine Developer-oder-höher-Aktion auf Ihrer Workspace-Session. Es gibt keinen Relay-Schlüssel-Selfservice dafür: Ein Schlüssel kann seine eigene Quell-Allowlist nicht erweitern.

​
5. Was eine IP-Allowlist enthält und was nicht

Ein IP-Whitelist-API-Key begrenzt, von wo ein Schlüssel funktioniert — ein Stück des Blast-Radius. Er komponiert mit den anderen Scope-Feldern, statt sie zu ersetzen.
Eine aus Logs, einem Git-Commit oder einem aufgebrochenen Laptop exfiltrierte Anmeldeinformation ist totes Gewicht, es sei denn, der Angreifer kann auch Traffer aus Ihrem allowlisteten Bereich erzeugen. Das ist die Kernaufgabe des Felds — siehe geleakter Schlüssel für die vollständige Incident-Response.
Wenn die Kompromittierung ein allowlisteter Host ist — eine vergiftete Abhängigkeit, die auf Ihrem eigenen Server läuft — passiert die Quell-IP-Prüfung. Kombinieren Sie allow_ips mit model_limits, einem Ausgabenlimit und einer Firewall-Policy, sodass eine Trusted-Source-Kompromittierung trotzdem begrenzt ist.
Ein IP-Pin macht einen Schlüssel nicht kurzlebig. Kombinieren Sie ihn mit einem absoluten Ablauf und einem Rotations-Zeitplan, sodass ein Schlüssel sowohl aufhört, von neuen Orten zu funktionieren, als auch irgendwann ganz aufhört zu funktionieren.

​
6. Betriebshinweise

Wenn Ihre Aufrufer keine stabile Quelladresse haben (serverless mit rotierendem Egress, mobile Clients, breite Büronetzwerke), ist ein IP-Pin die falsche Kontrolle — Sie würden entweder echten Traffic aussperren oder den Bereich so weit öffnen, dass er bedeutungslos ist. Stützen Sie sich stattdessen auf model_limits, Ausgabenlimits, Ablauf und Policy-Bindungen.
Das Bearbeiten von allow_ips wird beim nächsten Request wirksam — es gibt keine Propagierungsverzögerung, die abzuwarten wäre. Wenn Sie eine Region hinzufügen oder ein Subnetz migrieren, aktualisieren Sie zuerst den Schlüssel, bestätigen Sie, dass der neue Bereich funktioniert, und lassen Sie dann den alten fallen.
allow_ips lebt auf dem individuellen Schlüssel, sodass jeder Agent seine eigene Quellbindung haben kann. Ein Scheduler-Schlüssel kann auf ein Batch-Subnetz pinnen, während ein interaktiver Schlüssel einen breiteren Bürobereich erlaubt — beide im selben Workspace.

​
7. Nächste Schritte

Das Token-Objekt

Jedes Feld auf einem Schlüssel, einschließlich allow_ips, in einer Referenz.

Modell-Limits

Begrenzen Sie, welche Modelle ein Schlüssel erreichen darf — die andere Hälfte der Quell- + Scope-Bindung.

Geleakter Schlüssel

Was zu tun ist in dem Moment, in dem ein Schlüssel exponiert wird.

Least-Agency-Checkliste

Schicken Sie jeden Schlüssel durch denselben Härtungs-Durchgang.
Eine IP-Allowlist ist der billigste Blast-Radius-Schnitt, den Sie machen können: ein Feld, keine Code-Änderung, und ein geleakter Schlüssel hört auf zu funktionieren von überall, wo er nicht laufen sollte. Kombinieren Sie ihn mit dem Rest des Scoped-Key-Modells für Defense in Depth.