Passer au contenu principal
Lorsqu’un agent est détourné — injection de prompt, résultat d’outil empoisonné, boucle emballée — ce qu’il peut réellement faire est borné par exactement une chose : ce que sa clé API avait le droit de faire. Une clé sans limites et sans politique transforme un seul agent compromis en un incident à l’échelle de l’espace de travail. Cette page est la passe de durcissement que vous exécutez contre chaque clé avant de la livrer, et de nouveau selon une cadence après. Elle est délibérément courte : une checklist, un exemple travaillé, puis des liens vers la profondeur de chaque champ. Pour le modèle mental derrière elle, commencez par Portée & clés ; pour la référence champ par champ, voir la vue d’ensemble des clés.

​
1. La checklist de moindre agence

Faites passer chaque clé — nouvelle ou existante — par ces six barrières dans l’éditeur de clé (/console/token). Définir l’une d’elles requiert le rôle Developer ou supérieur ; les deux plans de politique (§5–6) sont rédigés séparément et liés ici.
Définissez model_limits à la liste exacte dont cet agent a besoin (et activez model_limits_enabled). Un appel à tout modèle hors de la liste est rejeté avant de quitter la passerelle, de sorte qu’un agent détourné ne peut pas escalader vers un modèle plus cher ou plus capable. Vérification : la liste est-elle aussi courte que le job le permet — idéalement un seul modèle ? Profondeur : Limites de modèles.
Définissez allow_ips aux adresses source ou CIDR depuis lesquels l’agent appelle réellement. Une clé fuitée présentée depuis ailleurs est rejetée à la couche d’authentification. Vide signifie que toutes les IPs sont autorisées. Vérification : pour un agent à hôte fixe ou planifié, la liste est-elle non vide et scopée à cet egress ? Profondeur : Allow-list d’IP.
Définissez credit_limit_usd à un plafond que l’agent ne devrait jamais franchir au cours de sa vie. La passerelle l’applique contre la dépense de la clé. 0 signifie illimité — une boucle emballée peut vider tout votre solde. Vérification : le plafond est-il un vrai budget, pas 0 ? Profondeur : Quota, plafond & expiration.
Définissez expired_time à une expiration absolue — la fin du sprint, du déploiement, ou de l’exécution CI. -1 signifie n’expire jamais. Une clé à courte durée de vie ne peut pas s’attarder comme surface d’attaque oubliée. Vérification : une clé éphémère ou de prestataire a-t-elle une vraie expiration, pas -1 ? Profondeur : Clés expirantes.
Attachez un guardrail via guardrail_id pour que le texte de la requête (et, là où c’est supporté, de la réponse) soit filtré pour la PII, les secrets, et l’intention d’injection avant qu’il n’atteigne le modèle. Vérification : une clé qui manipule des prompts sensibles a-t-elle un guardrail lié, ou hérite-t-elle d’un défaut d’espace de travail ? Voir §5.
Attachez une politique firewall via firewall_policy_id pour que chaque appel d’outil, dispatch MCP, et egress que cette clé émet soit évalué contre une allow-list de ce dont l’agent a légitimement besoin. Vérification : un agent qui appelle des outils a-t-il une politique firewall liée, ou hérite-t-il du défaut d’espace de travail ? Voir §6.
Les champs ci-dessus sont les seuls leviers configurables par le client sur une clé — définissez-les tous dans la console ; rien ici ne requiert un changement de code d’agent. Relire une clé la montre masquée ; le plaintext est montré une fois à la création. Voir Masquage des clés.

​
2. Quoi / à quelle fréquence / où

Trois questions transforment la checklist d’une corvée ponctuelle en une posture.

Quoi

Les six barrières ci-dessus, dans l’ordre : model_limits → allow_ips → credit_limit_usd → expired_time → guardrail_id → firewall_policy_id.

À quelle fréquence

Sur chaque clé à la création, et lors d’une revue récurrente — quand la portée d’un agent change, quand vous faites la rotation d’une clé, et à une cadence fixe pour les clés à longue durée de vie.

Où

Dans l’éditeur de clé de la console (/console/token), en tant que Developer+. Les deux politiques sont rédigées dans leurs propres consoles, puis liées sur la clé.

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

Un agent planifié qui résume les tickets de support avec un seul modèle bon marché, depuis un seul hôte, n’a presque besoin d’aucune agence. Une clé entièrement durcie :
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 ses outilsaucun 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 du firewall montre exactement ce qu’il était autorisé à faire.
Une clé sans model_limits, sans allow_ips, credit_limit_usd: 0, expired_time: -1, et sans attachement de politique a une agence maximale. Si elle fuite, le détenteur obtient l’intégralité de votre espace de travail. Traitez cette combinaison comme un constat, pas un défaut — voir illimité vs borné.

​
4. L’appel de relais /v1 vs la console

La checklist est configurée dans la console avec votre session (un utilisateur Developer+). Votre agent ne touche jamais ces routes de config — il présente sa clé de relais à portée limitée (sk-orca-…) sur les appels d’inférence /v1/*, et les limites et politiques liées ci-dessus sont appliquées sur chacun. 
# L'appel de runtime de l'agent — la clé de relais, scopée par la checklist ci-dessus.
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..."}]
  }'
Si le model_limits de la clé n’inclut pas openai/gpt-4o-mini, cet appel est rejeté avant de quitter la passerelle. Si l’IP de l’appelant n’est pas dans allow_ips, il est rejeté à la couche d’authentification. Le code de l’agent reste le même ; la clé décide le rayon d’explosion.

​
5. Barrière 5 — le guardrail lié

guardrail_id lie une politique de contenu ordonnée et à portée d’espace de travail à la clé. La résolution est le guardrail explicite de la clé (s’il existe et est activé), sinon le défaut de l’espace de travail, sinon aucun.
Les guardrails sont un interrupteur d’arrêt strict lorsqu’ils sont désactivés : un guardrail_id désactivé ou supprimé signifie que la clé ne reçoit aucun guardrail — il ne retombe pas sur le défaut de l’espace de travail. C’est l’opposé du plan firewall (§6), alors vérifiez que le guardrail lié est activé, pas seulement attaché.
Les règles d’un guardrail s’exécutent avant le modèle (étape d’entrée) et, là où c’est supporté, sur la réponse (étape de sortie), avec les actions block, mask, ou flag. Le preset PII Shield, par exemple, masque la PII dans la requête avant qu’elle n’atteigne le modèle. Rédigez et attachez les guardrails en tant que Developer+ — voir Guardrails et Lier des politiques.

​
6. Barrière 6 — la politique firewall liée + portée de passerelle

firewall_policy_id lie une politique d’appels d’outils à portée d’espace de travail. Elle gouverne les actions qu’un agent entreprend — outils annoncés, tool_calls émis par le modèle, dispatchs MCP, et egress sortant — contre une liste de règles ordonnée dont les verdicts sont allow, audit, deny, sanitize, pending_approval, ou cap_cost.
Le plan firewall se résout différemment 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. Donc lier une politique et la désactiver ramène la clé au défaut de l’espace de travail — elle ne devient jamais silencieusement non protégée.
La façon la plus rapide de définir les deux plans d’un coup est un niveau d’autonomie — un seul interrupteur qui configure atomiquement la posture firewall et guardrail de votre espace de travail (tight / balanced / permissive), avec annulation en un clic. Voir Firewall §8.
is_firewall_gateway est un type de clé séparé — 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 sur ces routes, et une clé de passerelle sur le chemin d’inférence est sur-scopée. Activer le flag, et lire le plaintext d’une clé de passerelle, requièrent Admin+. Une clé, un objectif.

​
7. Après la checklist

Référentiel secure-agents

La posture de départ recommandée — un interrupteur d’autonomie, puis ajustez à partir du trafic réel.

Lier des politiques

Comment guardrail_id et firewall_policy_id s’attachent et se résolvent.

Agence excessive

La menace que cette checklist est conçue pour contenir.

Clé fuitée

Que faire dès l’instant où une clé à portée limitée est exposée.
Plus chaque clé est étroite, plus petit est le rayon d’explosion si l’un des agents est compromis — et plus clair est le relevé de ce que chaque agent était autorisé à faire. Exécutez la checklist de moindre agence sur chaque clé, et continuez de l’exécuter.