Passer au contenu principal
Vous pouvez attacher un guardrail à une seule clé API, mais la plupart des équipes veulent un plancher : une politique de contenu qui s’applique à chaque clé de l’espace de travail à moins qu’une clé n’opte pour autre chose. Ce plancher est le défaut de l’espace de travail — un guardrail, marqué is_default, sur lequel la passerelle retombe chaque fois qu’une clé n’a pas d’attachement explicite. Cette page couvre le guardrail IA par défaut : comment le définir, comment fonctionne la résolution, et l’unique invariant à mémoriser — un défaut par espace de travail. Pour la référence complète du moteur, voir la référence Guardrails.
Tout ici est une action de console sur la passerelle hébergée (api.orcarouter.ai), exécutée sous votre propre session. Seul l’appel /v1/* final utilise une clé de relais sk-orca-.... Promouvoir ou rétrograder un guardrail par défaut nécessite Developer+ dans l’espace de travail.

​
1. Pourquoi définir un guardrail IA par défaut

L’attachement par clé est précis mais facile à oublier — émettez une nouvelle clé, sautez la liste déroulante, et cette clé part avec zéro filtrage. Un défaut d’espace de travail comble cet écart :

Les clés sans attachement en héritent

Toute clé dont le guardrail_id est non défini (0/null) est filtrée par le défaut automatiquement — y compris les clés créées après que vous l’avez défini.

Modifiez une fois, déplacez tout l'espace de travail

Le défaut vit dans la passerelle, pas sur chaque clé. Modifiez-le et chaque clé héritière se déplace au prochain appel — aucun redéploiement, aucun changement de SDK.
Un motif courant : faites d’un PII Shield conservateur le défaut de l’espace de travail afin que rien ne fuite par accident, puis laissez des clés spécifiques attacher une politique plus stricte ou plus souple quand elles en ont besoin.

​
2. Promouvoir un guardrail au défaut

Dans la console, ouvrez Guardrails, modifiez le guardrail que vous voulez comme plancher, et basculez Set as workspace default. Enregistrez.
1

Créer ou choisir un guardrail

Rédigez une politique comme d’habitude — par exemple le preset PII Shield, une seule règle pii qui masque à l’étape both.
2

Le marquer défaut et enregistrer

Activez Set as workspace default et enregistrez. Le flag is_default du guardrail bascule sur on.
3

Laisser les clés non attachées

Toute clé sans guardrail explicite hérite désormais de celui-ci. Les clés qui pointent déjà vers un autre guardrail conservent leur attachement.
Le défaut doit aussi être activé pour prendre effet. Un guardrail marqué is_default mais désactivé se résout vers aucune application — le toggle et l’état activé sont des interrupteurs indépendants.

​
3. Un défaut par espace de travail — la promotion est atomique

C’est l’invariant : au plus un guardrail par espace de travail porte is_default. Vous n’avez jamais à dé-marquer manuellement l’ancien. Lorsque vous promouvez un nouveau guardrail au défaut, la passerelle rétrograde le défaut précédent dans la même transaction — la promotion et la rétrogradation atterrissent toutes les deux ou aucune. Il n’y a jamais de fenêtre où deux guardrails sont tous deux le défaut, et jamais de fenêtre où aucun ne l’est. 
Before:   billing-pii   ← is_default ✓
          legal-redact

Promote "legal-redact" to default
          (single transaction)
          ┌─────────────────────────────────────────┐
          │  legal-redact  → is_default = true       │
          │  billing-pii   → is_default = false       │
          └─────────────────────────────────────────┘

After:    billing-pii
          legal-redact  ← is_default ✓
Vous n’avez pas à rétrograder d’abord. Promouvez simplement le nouveau — l’ancien défaut est effacé pour vous, atomiquement. Le guardrail rétrogradé existe toujours et reste activé ; il n’agit simplement plus comme le fallback. Les clés explicitement attachées à lui ne sont pas affectées.
Le même échange atomique s’applique que vous promouviez à la création (marquer un guardrail tout neuf comme défaut) ou à la modification (basculer le flag sur un guardrail existant).

​
4. Comment la résolution utilise le défaut

Pour toute requête, la passerelle résout exactement un guardrail (ou aucun) dans cet ordre fixe :
OrdreCe qui s’applique
1Le guardrail_id explicite de la clé — s’il existe et est activé.
2Le guardrail is_default activé de l’espace de travail (la clé n’avait pas d’attachement).
3Aucun — la requête est identique octet pour octet à un espace de travail sans politique.
Un attachement explicite de clé ne retombe jamais silencieusement sur le défaut. Si une clé pointe vers un guardrail et que ce guardrail est désactivé, la clé se résout vers aucune application — pas le défaut de l’espace de travail. Désactiver un guardrail attaché est l’interrupteur d’arrêt pour cette clé. (Les politiques firewall se comportent différemment ici — une politique firewall attachée désactivée retombe bien sur le défaut de l’espace de travail. Voir Guardrails vs. firewall.)
Donc le défaut est le fallback pour les clés non attachées uniquement. Il ne remplace jamais une clé qui a fait un choix explicite.
Fail-open par conception. Si la résolution du défaut rencontre une erreur transitoire, la passerelle dégrade vers aucune application plutôt que de faire échouer la requête. La sécurité se dégrade ; la disponibilité est préservée.

​
5. Exemple travaillé

Disons que votre espace de travail a deux guardrails et trois clés :
  • pii-shield — marqué défaut de l’espace de travail, activé.
  • strict-block — bloque les cartes de crédit, pas défaut.
  • Clé A — aucun attachement. Clé B — attachée à strict-block. Clé C — attachée à un guardrail que vous avez ensuite désactivé.
Une requête qui mentionne un email se résout ainsi :
guardrail_id est non défini, donc la résolution bascule vers le guardrail is_default activé pii-shield. L’email est masqué en [EMAIL] avant que le modèle ne le voie.
L’attachement explicite gagne. strict-block s’applique ; le défaut n’est jamais consulté.
L’attachement existe mais son guardrail est désactivé, donc la résolution renvoie aucun — elle ne bascule pas vers pii-shield. La requête n’est pas filtrée.
Maintenant, promouvez strict-block au défaut et enregistrez. En une transaction, strict-block.is_default devient true et pii-shield.is_default devient false. La clé A hérite immédiatement de strict-block à son prochain appel — sans aucun changement à la clé elle-même.

​
6. Confirmer que la requête atteint le défaut

Envoyez une requête avec une clé non attachée et vérifiez le flux des correspondances — une correspondance enregistrée sous votre guardrail par défaut confirme que le fallback s’est déclenché : 
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": "Reply to jane@acme.com please"}
    ]
  }'
Si le défaut est une politique PII de masquage, la passerelle réécrit l’email en [EMAIL] avant la transmission. S’il bloque, l’appel renvoie une HTTP 400 guardrail_blocked — qui ne coûte aucun quota et est marquée skip-retry. Voir l’erreur guardrail_blocked pour la forme complète de la réponse.
Vous voulez prouver le comportement du défaut avant qu’une clé ne s’y appuie ? Ouvrez l’onglet Test dans l’éditeur de guardrail et exécutez un échantillon à l’étape input — aucun appel en amont, aucun quota. Voir Test & éval.

​
7. Où aller ensuite

Attacher à une seule clé

Quand une clé a besoin d’une politique différente du plancher de l’espace de travail.

Créer votre premier guardrail

La boucle de bout en bout — créer, tester, attacher, envoyer.

Résolution & portée

Comment les clés, les politiques et les espaces de travail se composent.

Versioning

Chaque promotion écrit une ligne d’historique — diff et revert.
Promouvoir ou rétrograder le défaut est lui-même un changement versionné — ouvrez History sur le guardrail pour voir quand is_default a basculé et qui l’a fait. Pour le moteur complet, lisez la référence Guardrails.