Passer au contenu principal
Vous avez rédigé un guardrail et une politique firewall pour votre espace de travail. Vous voulez maintenant que cette clé précise — celle qu’utilise votre agent financier — applique une politique de contenu plus stricte et une allow-list d’outils plus serrée que le reste de l’espace de travail. C’est ce que font les deux champs d’attachement d’une clé : lier un guardrail et une politique firewall à une seule clé, et chaque requête que cette clé effectue est filtrée et appliquée par exactement ces politiques — sans changement de code d’agent, sans redéploiement. Cette page couvre les deux champs, leur résolution au moment de la requête, et la seule règle de résolution qui prend les gens au dépourvu : un attachement firewall désactivé se comporte différemment d’un attachement guardrail désactivé.

​
1. La politique de sécurité par clé : deux champs sur une clé

Un guardrail filtre le texte qui circule à travers un modèle (PII, secrets, jailbreaks). Une politique firewall gouverne les appels d’outils qu’un agent émet (quels outils, quels serveurs MCP, quels hôtes). Les deux sont des politiques nommées, à portée d’espace de travail — rédigées une fois, partagées dans l’espace de travail — et une clé opte pour une politique spécifique via deux champs :
ChampLieDéfini en console
guardrail_idLe guardrail qui filtre les prompts et réponses de cette clé.Developer+
firewall_policy_idLa politique firewall qui évalue les appels d’outils de cette clé.Developer+
Les deux sont définis dans l’éditeur de clé à /console/token. Définir l’un ou l’autre est une action Developer+ — les politiques elles-mêmes sont aussi rédigées en Developer+ (voir Portée & clés).
Ces deux champs sont indépendants. Une clé peut attacher un guardrail et pas une politique firewall, l’inverse, les deux, ou aucun — chaque plan se résout indépendamment. Laisser un champ non défini (0) n’est pas la même chose que couper l’application ; voir §3.

​
2. Un exemple concret

Disons que le guardrail par défaut de votre espace de travail signale la PII mais la laisse passer, et que la politique firewall par défaut audite chaque appel d’outil. C’est bien pour la plupart des agents — mais votre agent financier manipule des SSN de clients et ne devrait jamais appeler un outil shell. Rédigez un finance-guardrail plus strict (bloque la PII d’emblée) et un finance-firewall (n’autorise que les trois outils dont il a besoin), puis liez les deux à la clé de cet agent : 
# Configurez via la CONSOLE (UserAuth — votre session), pas une clé de relais.
# Ceci est l'appel de mise à jour de clé que fait l'éditeur à /console/token.
PUT /api/token
{
  "id": 4127,
  "name": "finance-agent",
  "guardrail_id": 12,          // finance-guardrail (PII = block)
  "firewall_policy_id": 8      // finance-firewall (3-tool allow-list)
}
Dès la requête suivante, le trafic de cette clé est filtré par le guardrail 12 et ses appels d’outils sont évalués par la politique 8 — tandis que chaque autre clé de l’espace de travail continue d’exécuter les défauts de l’espace de travail. Le propre code de l’agent ne change jamais ; il continue d’appeler https://api.orcarouter.ai/v1/... avec sa clé sk-orca-… exactement comme avant.
C’est le motif de moindre agence : une clé à portée étroite par agent, chacune liée aux politiques dont son travail a réellement besoin. Lorsque cet agent est compromis, le rayon d’explosion est tout ce que sa clé était autorisée à faire — rien de plus. Voir la checklist de moindre agence.

​
3. Résolution : la règle qui prend les gens au dépourvu

Pour chaque requête, la passerelle résout le guardrail actif et la politique firewall active indépendamment. L’ordre semble le même pour les deux — attachement d’abord, défaut de l’espace de travail ensuite — mais ils divergent sur un cas.

​
Résolution du guardrail

Le guardrail_id de la clé pointe vers un guardrail qui existe et est activé. Ce guardrail filtre la requête.
Désactiver le guardrail attaché est un interrupteur d’arrêt. La clé ne reçoit aucun filtrage de contenu — elle ne retombe pas sur le défaut de l’espace de travail. C’est délibéré : attacher un guardrail et le désactiver est la façon de couper le filtrage pour cette clé.
Aucun guardrail_id sur la clé. Le guardrail par défaut activé de l’espace de travail s’applique, s’il en existe un.
Aucun attachement et aucun défaut d’espace de travail → la requête passe sans filtrage de contenu.

​
Résolution du firewall

Le firewall_policy_id de la clé pointe vers une politique qui existe et est activée. Cette politique évalue les appels d’outils de la clé.
Voici la différence. Un attachement firewall désactivé retombe sur la politique firewall par défaut de l’espace de travail — il ne coupe pas l’application. Désactiver un attachement firewall ramène la clé au défaut de l’espace de travail ; il ne laisse pas la clé sans protection.
Aucun firewall_policy_id sur la clé → la politique firewall par défaut activée de l’espace de travail s’applique.
Désactiver une politique attachée n’est pas symétrique. Un attachement guardrail désactivé signifie aucun guardrail pour cette clé. Un attachement firewall désactivé signifie retomber sur le défaut de l’espace de travail. Si vous voulez qu’une clé n’applique réellement aucune protection firewall, vous ne pouvez pas y arriver en désactivant son attachement — assurez-vous qu’aucune politique firewall par défaut d’espace de travail n’est définie (ou scopez la clé de sorte qu’elle n’émette aucun appel d’outil gouverné).
Au plus un guardrail et une politique firewall par espace de travail peuvent être le défaut à un instant donné ; promouvoir un nouveau défaut rétrograde l’ancien dans la même transaction, de sorte que vous ne pouvez jamais en avoir deux par accident.

​
4. À quoi ressemble un block

Lorsqu’une politique liée refuse une requête, l’appelant voit une erreur structurée — l’agent peut réagir au lieu de planter :
PlanCode d’erreurHTTPCoût
Guardrailguardrail_blocked400Aucun — un block d’entrée se déclenche avant le métrage ; un block de sortie rembourse. Marqué skip-retry.
Firewall (inbound)firewall_blocked400Un block inbound se déclenche avant l’appel au modèle, donc aucun token de modèle. Skip-retry.
Firewall (held)firewall_approval_pending400Mis en attente d’approbation humaine ; l’agent interroge et re-soumet une fois approuvé.
Les deux corps d’erreur sont de forme OpenAI et nomment la politique et la raison, de sorte que votre agent peut brancher sur le code. Voir les références en profondeur pour l’enregistrement d’événement complet et la façon dont les correspondances sont journalisées.

​
5. Où aller ensuite

Portée & clés

Le modèle complet à trois niveaux — espace de travail, politique, clé — et chaque champ qu’une clé porte.

L'objet token

Chaque champ d’une clé : model_limits, allow_ips, credit_limit_usd, expired_time, et les deux attachements de politique.

Guardrails

Rédigez la politique de contenu que vous liez via guardrail_id — règles, entités PII, actions et presets.

Firewall

Rédigez la politique d’appels d’outils que vous liez via firewall_policy_id — verdicts, surfaces et niveaux d’autonomie.
Vous voulez définir toute la posture de votre espace de travail en un seul geste plutôt que de lier les clés une à une ? Un niveau d’autonomie écrit les deux plans — guardrails et firewall — d’un coup. Puis attachez des politiques plus strictes sur les quelques clés qui doivent aller plus loin que le défaut de l’espace de travail. Voir Guardrails vs Firewall.