Passer au contenu principal
Une seule clé API peut atteindre chaque modèle auquel votre espace de travail a droit. C’est pratique pour une session de console et dangereux pour un agent à longue durée de vie : un agent victime d’injection de prompt détenant une clé non restreinte peut basculer discrètement de gpt-4o-mini vers le modèle le plus cher auquel vous avez accès, ou vers un modèle dont vous n’avez jamais approuvé le traitement des données. Le correctif est une allow-list de modèles par clé. Chaque clé porte un champ model_limits (gardé par model_limits_enabled). Quand il est activé, une requête vers tout modèle absent de la liste est rejetée à la passerelle — avant qu’un canal soit sélectionné et avant que quoi que ce soit ne parte vers un fournisseur.
C’est une contrainte sur l’objet clé. Elle se compose avec l’allow-list d’IP de la clé, le plafond de dépense, l’expiration, et le guardrail / la politique firewall attachés — chacun rétrécit la clé indépendamment.

​
1. Pourquoi restreindre l’accès aux modèles par clé API

Le choix du modèle est un levier d’agence. Une clé qui peut appeler n’importe quel modèle peut être orientée vers :
  • Explosions de coût — basculer vers un modèle premium multiplie la facture par token.
  • Dérive de capacité — une tâche scopée pour un petit modèle est routée vers un modèle frontière qui peut faire bien plus que ce que vous aviez prévu.
  • Dérive de conformité — envoyer du trafic vers une famille de modèles que vous n’avez pas validée pour une classe de données donnée.
Restreindre une clé aux un ou deux modèles dont un agent a réellement besoin ferme les trois d’un coup. C’est l’équivalent sur l’axe modèle de l’allow-listing d’outils du firewall — l’agent ne peut atteindre que ce que vous avez nommé, et rien d’autre.

​
2. Les deux champs

Les limites de modèles vivent sur la clé sous forme de paire :
ChampTypeSignification
model_limits_enabledboolInterrupteur maître. Quand false, la clé atteint chaque modèle que l’espace de travail autorise.
model_limitslistL’allow-list de noms de modèles. N’a de sens que lorsque model_limits_enabled est true.
Les deux champs sont indépendants, et la combinaison compte : model_limits_enabled = true avec une liste vide signifie que la clé ne peut atteindre aucun modèle — chaque requête est rejetée avec « This token has no access to any models. » N’activez l’interrupteur qu’une fois que vous avez nommé au moins un modèle.

​
3. Le définir sur une clé

Configurez les limites de modèles dans l’éditeur de clé de la console (/console/token), au même endroit que les autres contraintes de la clé. Créer ou modifier une clé requiert le rôle Developer ou supérieur.
  1. Ouvrez la clé (ou Créer une clé).
  2. Activez Limites de modèles.
  3. Choisissez les modèles que cette clé peut appeler — tapez pour filtrer les modèles disponibles de l’espace de travail.
  4. Enregistrez. Le changement prend effet à la prochaine requête de la clé — aucun redéploiement, aucune rotation de clé.
Un résumeur planifié qui ne devrait jamais toucher qu’un seul modèle bon marché se retrouve avec une allow-list d’exactement une entrée : 
model_limits_enabled: true
model_limits:         ["openai/gpt-4o-mini"]
À partir de ce point la clé est épinglée à gpt-4o-mini. Tout autre nom de modèle sur une requête de cette clé est rejeté — il n’y a aucun repli vers un modèle par défaut et aucune rétrogradation silencieuse.
Associez les limites de modèles à un plafond credit_limit_usd sur la même clé. La liste de modèles borne quel modèle une boucle emballée peut atteindre ; le plafond de dépense borne combien elle peut brûler avant que la clé cesse de fonctionner. Deux plafonds indépendants, tous deux appliqués à la passerelle. Voir Quota, plafond & expiration.

​
4. À quoi ressemble une requête rejetée

Lorsque model_limits_enabled est activé et qu’une requête nomme un modèle hors de la liste, la passerelle avorte la requête avec HTTP 403 et un corps d’erreur de forme OpenAI : 
{
  "error": {
    "message": "This token has no access to model claude-opus-4-8 (request id: 2024...abc)",
    "type": "orcarouter_api_error",
    "code": ""
  }
}
Propriétés clés du rejet :
La vérification s’exécute pendant que la passerelle choisit encore un canal — la requête n’atteint jamais un fournisseur amont, donc un modèle interdit ne coûte aucun token de modèle.
Avec l’interrupteur activé et une allow-list vide, le message est « This token has no access to any models » et chaque requête est rejetée. C’est la différence entre « restreindre à une liste » et « verrouiller la clé hors de l’inférence entièrement ».
Le nom de modèle de la requête est normalisé avant que la liste soit vérifiée, de sorte que les variantes liées (par ex. variantes thinking) se résolvent vers le même nom canonique que vous avez allow-listé. Listez le nom du modèle de base que la console vous montre.

​
5. Limites de modèles vs. droits de groupe

Deux choses différentes décident si une clé peut appeler un modèle. Ne les confondez pas :
CouchePortéeQuestion à laquelle elle répond
Droit d’espace de travailEspace de travailCe modèle est-il disponible pour l’espace de travail tout court ?
model_limitsClé uniqueParmi les modèles disponibles, lesquels CETTE clé peut-elle utiliser ?
model_limits ne fait jamais que rétrécir. Une clé ne peut pas utiliser les limites de modèles pour atteindre un modèle auquel l’espace de travail lui-même n’a pas droit — elle ne peut que tailler une allow-list plus petite dans ce qui est déjà permis. Pour accorder à une clé rien de plus mais strictement moins, c’est exactement à cela que sert ce champ.

​
6. Où cela s’inscrit dans la posture de moindre agence

Les limites de modèles sont une ligne de la recette de clé par agent. La clé utile la plus étroite pour un agent autonome épingle tous ses axes d’un coup : Lorsqu’une telle clé est compromise via une injection de prompt, le rayon d’explosion est borné sur chaque axe — y compris sur quels modèles l’attaquant peut dépenser votre budget.
Les limites de modèles sont une contrainte d’identité sur la clé, pas une politique de contenu ni d’action. Elles n’inspectent pas les prompts (c’est le rôle des Guardrails) ni les appels d’outils (c’est le rôle du Firewall) — elles décident, en amont, quel modèle la clé est même autorisée à adresser.

​
7. Étapes suivantes

L'objet clé

Chaque champ qu’une clé porte — limites de modèles, liste d’IP, plafonds, expiration et attachements de politique — dans une seule référence.

Checklist de moindre agence

La recette complète de clé par agent : scopez chaque axe au minimum dont l’agent a besoin.

Portée, clés & politiques

Comment les clés, guardrails et politiques firewall se lient ensemble en une seule identité d’agent.

Lier des politiques à une clé

Attacher un guardrail et une politique firewall à la même clé.
Restreindre l’accès aux modèles par clé API est le contrôle d’agence le moins cher que vous puissiez appliquer : une allow-list, appliquée à la passerelle, qu’aucun agent compromis ne peut contourner par la parole.