Passer au contenu principal
Lorsqu’un agent est compromis — injection de prompt, résultat d’outil empoisonné, boucle emballée — les dégâts qu’il peut causer sont bornés par exactement une chose : ce que sa clé API avait le droit de faire. Une clé d’espace de travail partagée par tous les appelants transforme un seul agent compromis en un incident à l’échelle de l’espace de travail. Une clé à portée étroite transforme la même compromission en un événement contenu et auditable. C’est le hub de la section clés. Il couvre le modèle d’identité à moindre agence et les champs qui scopent une clé, puis renvoie vers les pages dédiées à chacun.

​
1. Pourquoi des clés API à portée limitée pour les agents LLM

Une clé API généraliste est une credential au porteur : quiconque la détient peut appeler n’importe quel modèle, depuis n’importe où, pour n’importe quel montant, sans aucune politique attachée. C’est l’opposé de ce dont un agent autonome a besoin. Sur OrcaRouter, une clé API n’est pas qu’une credential — c’est une déclaration de portée. Chaque clé porte ses propres contraintes (quels modèles, quelles IPs, combien de dépenses, quand elle expire) et pointe vers le guardrail et la politique firewall qui gouvernent son trafic. Modifier la politique vers laquelle pointe une clé prend effet à la requête suivante, sans redéploiement et sans changement de code d’agent. Le principe est la moindre agence : donnez à chaque agent l’identité la plus étroite qui lui permette encore de faire son travail, et rien de plus. Une clé, un agent, un objectif.
La façon la plus rapide d’intérioriser le modèle : lisez Portée & clés pour la hiérarchie espace de travail → politique → clé, puis travaillez la checklist de moindre agence sur une clé réelle.

​
2. Ce que porte une clé à portée limitée

Chaque clé est un ensemble de limites plus deux attachements de politique. Chaque champ est documenté sur sa propre page — les liens spoke ci-dessous mènent à la profondeur.

Limites de modèles

model_limits restreint une clé à une liste nommée de modèles. Un appel hors de la liste est rejeté avant de quitter la passerelle — l’agent ne peut pas basculer vers un modèle plus cher ou plus capable.

Allow-list d'IP

allow_ips épingle une clé à des adresses source spécifiques. Une clé fuitée présentée depuis ailleurs est rejetée à la couche d’authentification.

Quota, plafond & expiration

credit_limit_usd plafonne la dépense à vie (0 = illimité) ; expired_time fixe une expiration absolue (-1 = jamais).

Environnements

environment est une étiquette libre (prod, staging, dev) pour organiser les clés et filtrer les logs.

Lier des politiques

guardrail_id et firewall_policy_id attachent une politique de contenu et une politique d’appels d’outils à la clé. Aucun attachement retombe sur le défaut de l’espace de travail.

L'objet token

La référence complète champ par champ d’une clé, y compris remain_quota / used_quota et is_firewall_gateway.
Borné vs non borné. Une clé avec credit_limit_usd: 0 et expired_time: -1 n’a aucun plafond de dépense et n’expire jamais — pratique, mais le pire rayon d’explosion si elle fuite. Voir illimité vs borné pour savoir quand chacun est approprié.

​
3. Une clé concrète à moindre agence

Un agent planifié qui résume les tickets de support avec un seul modèle bon marché et tourne depuis un seul hôte n’a presque besoin d’aucune agence. Une clé bien scopée pour lui :
ChampValeurPourquoi
model_limitsun modèle de résuméne peut pas escalader vers un modèle frontière
allow_ipsle CIDR d’egress du planificateurune clé fuitée est inutile ailleurs
credit_limit_usdun plafond hebdomadaireune boucle emballée ne peut pas vider le solde
expired_timefin du déploiementexpire automatiquement, ne peut pas s’attarder
guardrail_idun guardrail de masquage de PIIle texte de la requête est filtré
firewall_policy_idn’autorise que les outils dont il a besoinaucun appel d’outil surprise
Si cet agent est détourné, il ne peut toujours appeler qu’un seul modèle, seulement depuis une seule plage d’IP, seulement jusqu’à son plafond, et seulement les outils que sa politique firewall permet. Le reste de l’espace de travail est intact — et la piste d’audit montre exactement ce qu’il était autorisé à faire.
Renseignez chaque champ dans l’éditeur de clé de la console (/console/token). Créer ou modifier des clés requiert le rôle Developer ou supérieur.

​
4. Lier les deux plans de politique

Les deux attachements sont les champs les plus puissants d’une clé, et ils se résolvent différemment lorsqu’une politique attachée est désactivée :
Filtre le texte de la requête et de la réponse (PII, secrets, injection de prompt) contre un guardrail ordonné et à portée d’espace de travail. Résolution : un guardrail_id explicite et activé s’applique ; un désactivé est l’interrupteur d’arrêt — il ne retombe pas sur le défaut de l’espace de travail. Sans attachement, le guardrail par défaut de l’espace de travail s’applique, sinon rien.
Gouverne les actions qu’un agent entreprend — appels d’outils, dispatchs MCP, egress — contre une politique firewall à portée d’espace de travail. La résolution diffère des guardrails : une politique firewall attachée mais désactivée retombe sur le défaut de l’espace de travail, elle ne coupe pas l’application.
Un token à portée de passerelle est frappé uniquement pour les routes Firewall MCP et evaluate-hook (/api/v1/firewall/*), jamais pour l’inférence. Une clé ordinaire reçoit un 403 là. Activer ce flag, et lire le plaintext de la clé de passerelle, requiert Admin+.
L’ordre de résolution complet — attachement de clé → défaut de l’espace de travail → aucun — vit sur Portée & clés et Lier des politiques.

​
5. La section clés

Gérer les clés

Créer, modifier et révoquer des clés dans la console.

Rotation

Renouveler une clé sans interruption.

Clés expirantes

Clés à courte durée de vie pour les agents éphémères et les exécutions CI.

Masquage des clés

Les clés sont masquées à l’affichage ; le plaintext est montré une fois à la création.

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.

​
6. Où les clés se situent dans la pile de contrôle

Une clé à portée limitée est la première couche de défense — elle décide qui est l’appelant et ce qu’il peut atteindre avant qu’aucune politique ne s’exécute. Les Guardrails et le Firewall sont les couches suivantes.

Sécuriser les agents IA

Pourquoi l’identité de l’agent est le fondement de la pile de contrôle.

Guardrails vs Firewall

Les deux plans de politique auxquels une clé peut se lier.

Agence excessive

La menace que les clés à moindre agence sont conçues pour contenir.
Une clé sans model_limits, sans allow_ips, sans credit_limit_usd, sans expiration et sans attachement de politique a une agence maximale. Si elle fuite, le détenteur obtient l’intégralité de votre espace de travail. Scopez chaque clé de production avant de la livrer — commencez par le référentiel secure-agents.
La portée est le fondement : plus chaque clé est étroite, plus le rayon d’explosion est petit si l’un des agents est compromis — et plus clair est le relevé de ce que chaque agent était autorisé à faire.