Passer au contenu principal
Une clé sans restriction de source est une pure credential au porteur : quiconque détient la chaîne peut la présenter depuis n’importe où. Le champ allow_ips transforme une clé en une clé API à allow-list d’IP — elle ne fonctionne que lorsqu’elle est présentée depuis une adresse source que vous avez listée. Une clé fuitée rejouée depuis la machine d’un attaquant, un proxy résidentiel, ou un runner CI compromis est rejetée avant de toucher un modèle. C’est la moitié liaison-de-source de la moindre agence : model_limits plafonne quels modèles une clé peut atteindre, et allow_ips plafonne depuis où la clé peut être présentée.

​
1. Ce que fait allow_ips

allow_ips contient une liste d’adresses source ou de plages CIDR. À chaque requête, OrcaRouter compare l’IP source de l’appelant à cette liste :
  • Correspondance → la requête poursuit vers les vérifications de limite de modèle, de quota et de politique.
  • Aucune correspondance → la requête est rejetée à la couche d’authentification avec HTTP 403 (access_denied), avant tout appel à un modèle amont.
  • Liste vide → aucune restriction ; la clé est acceptée depuis n’importe quelle adresse.
La vérification est la première barrière qu’une clé franchit, aux côtés de la validité de la clé — elle s’exécute avant les guardrails, avant le firewall, avant le métrage. Une source non listée n’atteint jamais vos politiques ni votre solde.
Un allow_ips vide signifie toutes les IPs autorisées, pas aucune. Le laisser vide est le défaut non restreint — épinglez la clé pour que le champ fasse quoi que ce soit.

​
2. Formats acceptés

Chaque entrée est une seule IP ou une plage CIDR. Mélangez les deux librement ; listez une entrée par ligne.

Adresse unique

203.0.113.7 — exactement un hôte. Idéal pour un serveur à IP fixe ou une passerelle NAT avec une adresse d’egress stable.

Plage CIDR

203.0.113.0/24 — un bloc entier. Idéal pour un sous-réseau cloud, un pool VPN, ou un groupe d’autoscaling derrière un seul CIDR d’egress.
Une IP nue correspond à cette seule adresse ; un CIDR correspond à chaque adresse du bloc. Les littéraux IPv4 comme IPv6 se parsent.
Épinglez à la plage la plus étroite qui couvre encore chaque appelant légitime. Un hôte (/32) est plus serré qu’un /24 ; un /24 est plus serré que « n’importe où ». Chaque bit que vous abandonnez élargit l’ensemble des endroits où une clé fuitée fonctionne encore.

​
3. Le définir dans la console

Définissez allow_ips dans l’éditeur de clé à /console/token. Créer ou modifier une clé requiert le rôle Developer ou supérieur.
  1. Ouvrez Console → Clés API et créez ou modifiez une clé.
  2. Dans l’éditeur de clé, entrez vos adresses de confiance dans le champ Allow-list d’IP — une IP ou un CIDR par ligne.
  3. Enregistrez. La restriction s’applique à la prochaine requête que cette clé effectue — aucun redéploiement, aucun changement de code d’agent.
Vérifiez la vraie adresse source que la passerelle voit avant de verrouiller une clé. Si votre agent se trouve derrière un NAT, un load balancer, ou un proxy d’egress, l’adresse qu’OrcaRouter observe est ce saut d’egress — pas l’IP privée de l’agent. Allow-listez l’adresse d’egress, et testez depuis l’environnement déployé avant de livrer.

​
4. Un exemple concret : un agent planifié

Un job planifié qui résume des tickets ne tourne que depuis un seul sous-réseau cloud. Épinglez sa clé à ce sous-réseau pour que la credential soit inutile ailleurs.
ChampValeurEffet
allow_ips203.0.113.0/24seul le bloc d’egress du planificateur peut présenter cette clé
model_limitsun modèle de résuméne peut pas escalader vers un modèle frontière
credit_limit_usdun plafond hebdomadaireune boucle emballée ne peut pas vider le solde
L’appel de relais lui-même est inchangé — il utilise toujours la clé sk-orca-… comme token au porteur : 
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..."}]
  }'
Présenté depuis l’intérieur de 203.0.113.0/24, l’appel poursuit. Rejouez exactement la même requête depuis toute autre adresse et la passerelle renvoie : 
{
  "error": {
    "message": "您的 IP 不在令牌允许访问的列表中 (request id: ...)",
    "type": "orcarouter_api_error",
    "code": "access_denied"
  }
}
Le modèle n’est jamais appelé, aucun quota n’est dépensé, et le rejet est journalisé.
allow_ips est configuré entièrement via l’éditeur de clé de la console — une action Developer-ou-supérieur sur votre session d’espace de travail. Il n’y a aucun self-service via clé de relais pour cela : une clé ne peut pas élargir sa propre allow-list de source.

​
5. Ce qu’une allow-list d’IP contient et ne contient pas

Une clé API à allow-list d’IP borne où une clé fonctionne — une tranche du rayon d’explosion. Elle se compose avec les autres champs de portée plutôt que de les remplacer.
Une credential exfiltrée depuis des logs, un commit git, ou un laptop piraté est un poids mort à moins que l’attaquant puisse aussi originer du trafic depuis votre plage allow-listée. C’est le rôle principal du champ — voir clé fuitée pour la réponse à incident complète.
Si la compromission est un hôte allow-listé — une dépendance empoisonnée tournant sur votre propre serveur — la vérification d’IP source passe. Associez allow_ips à model_limits, un plafond de dépense, et une politique firewall pour qu’une compromission de source de confiance reste bornée.
Un épinglage d’IP ne rend pas une clé à courte durée de vie. Combinez-le avec une expiration absolue et un calendrier de rotation pour qu’une clé cesse à la fois de fonctionner depuis de nouveaux endroits et cesse de fonctionner à terme.

​
6. Notes opérationnelles

Si vos appelants n’ont pas d’adresse source stable (serverless avec egress tournant, clients mobiles, réseaux de bureau larges), un épinglage d’IP est le mauvais contrôle — vous bloqueriez du trafic réel ou élargiriez la plage jusqu’à ce qu’elle n’ait plus de sens. Appuyez-vous plutôt sur model_limits, les plafonds de dépense, l’expiration, et les attachements de politique.
Modifier allow_ips prend effet à la requête suivante — il n’y a aucun délai de propagation à attendre. Lorsque vous ajoutez une région ou migrez un sous-réseau, mettez la clé à jour d’abord, confirmez que la nouvelle plage fonctionne, puis retirez l’ancienne.
allow_ips vit sur la clé individuelle, de sorte que chaque agent peut avoir sa propre liaison de source. Une clé de planificateur peut épingler à un sous-réseau de batch tandis qu’une clé interactive autorise une plage de bureau plus large — les deux dans le même espace de travail.

​
7. Étapes suivantes

L'objet token

Chaque champ d’une clé, y compris allow_ips, dans une seule référence.

Limites de modèles

Plafonner quels modèles une clé peut atteindre — l’autre moitié de la liaison source + portée.

Clé fuitée

Que faire dès l’instant où une clé est exposée.

Checklist de moindre agence

Faites passer chaque clé par la même passe de durcissement.
Une allow-list d’IP est la coupe de rayon d’explosion la moins chère que vous puissiez faire : un champ, aucun changement de code, et une clé fuitée cesse de fonctionner depuis partout où elle n’était pas censée tourner. Associez-la au reste du modèle de clé à portée limitée pour une défense en profondeur.