Zum Hauptinhalt springen
Ein einzelner API-Key kann jedes Modell erreichen, zu dem Ihr Workspace berechtigt ist. Das ist praktisch für eine Konsolen-Session und gefährlich für einen langlebigen Agenten: Ein prompt-injizierter Agent, der einen unbeschränkten Schlüssel hält, kann leise von gpt-4o-mini zum teuersten Modell wechseln, auf das Sie Zugriff haben, oder zu einem, dessen Datenverarbeitung Sie nie genehmigt haben. Die Abhilfe ist eine Pro-Schlüssel-Modell-Allowlist. Jeder Schlüssel trägt ein model_limits-Feld (gesteuert durch model_limits_enabled). Wenn es an ist, wird ein Request für irgendein Modell, das nicht auf der Liste steht, am Gateway abgelehnt — bevor ein Channel ausgewählt wird und bevor irgendetwas zu einem Anbieter abgeht.
Dies ist eine Beschränkung auf dem Schlüssel-Objekt. Es komponiert mit der IP-Allowlist, dem Ausgabenlimit, dem Ablauf und dem gebundenen Guardrail / der Firewall-Policy des Schlüssels — jedes verengt den Schlüssel unabhängig.

​
1. Warum den Modellzugriff pro API-Key beschränken

Die Modellwahl ist ein Agency-Hebel. Ein Schlüssel, der jedes Modell aufrufen kann, kann gesteuert werden in:
  • Kostenexplosionen — der Wechsel zu einem Premium-Modell vervielfacht die Rechnung pro Token.
  • Capability-Creep — eine für ein kleines Modell zugeschnittene Aufgabe wird an ein Frontier-Modell geroutet, das weit mehr kann, als Sie beabsichtigt haben.
  • Compliance-Drift — das Senden von Traffic an eine Modellfamilie, die Sie für eine gegebene Datenklasse nicht freigegeben haben.
Einen Schlüssel auf die ein oder zwei Modelle zu beschränken, die ein Agent tatsächlich braucht, schließt alle drei auf einmal. Es ist das Modell-Achsen-Äquivalent zum Allowlisting von Tools durch die Firewall — der Agent kann nur erreichen, was Sie benannt haben, und nichts sonst.

​
2. Die zwei Felder

Modell-Limits leben auf dem Schlüssel als ein Paar:
FeldTypBedeutung
model_limits_enabledboolHauptschalter. Wenn false, erreicht der Schlüssel jedes Modell, das der Workspace erlaubt.
model_limitslistDie Allowlist der Modellnamen. Nur bedeutsam, wenn model_limits_enabled true ist.
Die zwei Felder sind unabhängig, und die Kombination zählt: model_limits_enabled = true mit einer leeren Liste bedeutet, dass der Schlüssel keine Modelle erreichen kann — jeder Request wird mit „This token has no access to any models.” abgelehnt. Schalten Sie den Schalter erst ein, wenn Sie mindestens ein Modell benannt haben.

​
3. Auf einem Schlüssel setzen

Konfigurieren Sie Modell-Limits im Konsolen-Schlüssel-Editor (/console/token), an demselben Ort, an dem Sie die anderen Beschränkungen des Schlüssels setzen. Das Erstellen oder Bearbeiten eines Schlüssels erfordert die Rolle Developer oder höher.
  1. Öffnen Sie den Schlüssel (oder Schlüssel erstellen).
  2. Aktivieren Sie Modell-Limits.
  3. Wählen Sie die Modelle, die dieser Schlüssel aufrufen darf — tippen Sie, um die verfügbaren Modelle des Workspaces zu filtern.
  4. Speichern. Die Änderung wird beim nächsten Request des Schlüssels wirksam — kein Redeploy, keine Schlüsselrotation.
Ein geplanter Summarizer, der nur jemals ein billiges Modell anfassen sollte, endet mit einer Allowlist von genau einem Eintrag: 
model_limits_enabled: true
model_limits:         ["openai/gpt-4o-mini"]
Ab diesem Punkt ist der Schlüssel auf gpt-4o-mini festgepinnt. Jeder andere Modellname in einem Request von diesem Schlüssel wird abgelehnt — es gibt keinen Fallback auf ein Default-Modell und kein stilles Downgrade.
Kombinieren Sie Modell-Limits mit einem credit_limit_usd-Cap auf demselben Schlüssel. Die Modellliste begrenzt, welches Modell eine außer Kontrolle geratene Schleife erreichen kann; das Ausgabenlimit begrenzt, wie viel sie verbrennen kann, bevor der Schlüssel aufhört zu funktionieren. Zwei unabhängige Obergrenzen, beide am Gateway durchgesetzt. Siehe Kontingent-Cap & Ablauf.

​
4. Wie ein abgelehnter Request aussieht

Wenn model_limits_enabled an ist und ein Request ein Modell außerhalb der Liste benennt, bricht das Gateway den Request mit HTTP 403 und einem OpenAI-förmigen Fehler-Body ab: 
{
  "error": {
    "message": "This token has no access to model claude-opus-4-8 (request id: 2024...abc)",
    "type": "orcarouter_api_error",
    "code": ""
  }
}
Schlüsseleigenschaften der Ablehnung:
Die Prüfung läuft, während das Gateway noch einen Channel wählt — der Request erreicht nie einen Upstream-Anbieter, sodass ein verbotenes Modell keine Modell-Tokens kostet.
Mit eingeschaltetem Schalter und einer leeren Allowlist lautet die Nachricht „This token has no access to any models”, und jeder Request wird abgelehnt. Das ist der Unterschied zwischen „auf eine Liste beschränken” und „den Schlüssel vollständig aus der Inferenz aussperren.”
Der Modellname des Requests wird normalisiert, bevor die Liste geprüft wird, sodass verwandte Varianten (z. B. Thinking-Varianten) auf denselben kanonischen Namen auflösen, den Sie allowlistet haben. Listen Sie den Basis-Modellnamen, den die Konsole Ihnen anzeigt.

​
5. Modell-Limits vs. Gruppen-Berechtigungen

Zwei verschiedene Dinge entscheiden, ob ein Schlüssel ein Modell aufrufen kann. Verwechseln Sie sie nicht:
EbeneScopeFrage, die sie beantwortet
Workspace-BerechtigungWorkspaceIst dieses Modell dem Workspace überhaupt verfügbar?
model_limitsEinzelner SchlüsselWelches der verfügbaren Modelle darf DIESER Schlüssel verwenden?
model_limits verengt nur jemals. Ein Schlüssel kann Modell-Limits nicht nutzen, um ein Modell zu erreichen, zu dem der Workspace selbst nicht berechtigt ist — er kann nur eine kleinere Allowlist aus dem herausschneiden, was bereits erlaubt ist. Um einem Schlüssel nichts Zusätzliches, aber strikt weniger zu gewähren — genau dafür ist dieses Feld da.

​
6. Wo das in die Least-Agency-Haltung passt

Modell-Limits sind eine Zeile des Pro-Agent-Schlüsselrezepts. Der engste nützliche Schlüssel für einen autonomen Agenten pinnt alle seine Achsen auf einmal fest: Wenn solch ein Schlüssel via Prompt-Injection kompromittiert wird, ist der Blast-Radius auf jeder Achse begrenzt — einschließlich dessen, auf welche Modelle der Angreifer Ihr Budget verausgaben kann.
Modell-Limits sind eine Identitäts-Beschränkung auf dem Schlüssel, keine Content- oder Aktionspolicy. Sie inspizieren keine Prompts (das sind Guardrails) oder Tool-Calls (das ist die Firewall) — sie entscheiden vorab, welches Modell der Schlüssel überhaupt ansprechen darf.

​
7. Nächste Schritte

Das Schlüssel-Objekt

Jedes Feld, das ein Schlüssel trägt — Modell-Limits, IP-Liste, Caps, Ablauf und Policy-Bindungen — in einer Referenz.

Least-Agency-Checkliste

Das vollständige Pro-Agent-Schlüsselrezept: jede Achse auf das Minimum fassen, das der Agent braucht.

Scope, Schlüssel & Policies

Wie Schlüssel, Guardrails und Firewall-Policies zu einer Agenten-Identität zusammengebunden werden.

Policies an einen Schlüssel binden

Hängen Sie ein Guardrail und eine Firewall-Policy an denselben Schlüssel.
Den Modellzugriff pro API-Key zu beschränken ist die billigste Agency-Kontrolle, die Sie anwenden können: eine Allowlist, am Gateway durchgesetzt, um die sich kein kompromittierter Agent herumreden kann.