Passer au contenu principal
Vous avez une clé que votre agent utilise sur api.orcarouter.ai, et vous voulez que chaque appel d’outil effectué par cette clé soit gouverné — bloqué, audité, assaini ou mis en attente d’approbation — sans toucher au code de votre agent. C’est une configuration du firewall agent en deux étapes : créez une politique firewall une fois, puis pointez la clé dessus. Dès le prochain appel, chaque outil que la clé émet est vérifié contre la politique à la passerelle. Cette page est le chemin créer-et-attacher. Pour le modèle de politique complet (surfaces, verdicts, résolution) voir la Vue d’ensemble du Firewall ; pour la grammaire des règles voir Règles du Firewall.
Toute la configuration des politiques et des clés se fait dans la console (ou via les routes de gestion /api/workspace/firewall/*, qui utilisent votre session / token d’accès — pas une clé de relais sk-orca-…). Seuls les appels /v1/* de votre agent utilisent la clé de relais. Créer et attacher une politique est une action Developer+.

​
1. La configuration du firewall agent en un coup d’œil

Une politique firewall est un objet nommé, à portée d’espace de travail : une liste ordonnée de règles plus un verdict par défaut pour tout ce qu’aucune règle ne fait correspondre. Une clé adhère à une politique via son champ firewall_policy_id. Rien d’autre dans votre stack ne change.

Créer la politique

Nommez-la, choisissez un verdict par défaut, ajoutez des règles — ou initialisez à partir d’un niveau d’autonomie / preset et éditez.

Attacher une clé

Définissez le firewall_policy_id de la clé sur la politique, ou marquez la politique comme défaut de l’espace de travail pour que chaque clé non attachée en hérite.

​
2. Créer une politique dans la console

  1. Ouvrez Security → Firewall → Policies et choisissez New policy.
  2. Nommez-la (unique dans l’espace de travail) et laissez Enabled activé.
  3. Choisissez un verdict par défaut — voir §3.
  4. Ajoutez des règles dans l’éditeur de règles, ou commencez vide et laissez les Outils découverts piloter la rédaction à partir du trafic réel plus tard.
  5. Enregistrez. La politique existe mais ne gouverne rien jusqu’à ce qu’une clé pointe dessus ou que vous en fassiez le défaut de l’espace de travail.
Vous ne voulez pas rédiger les règles à la main d’abord ? Appliquez un niveau d’autonomie (balanced est le départ recommandé) — il matérialise des lignes de politique et de guardrail réelles et éditables que vous pouvez ensuite affiner. Ou démarrez une règle à partir d’un preset intégré et éditez-la. Dans les deux cas, vous aboutissez au même endroit : une politique nommée que vous attachez à une clé.

​
3. Choisir le verdict par défaut

Le verdict par défaut est ce que fait la politique lorsqu’aucune règle ne correspond à un appel d’outil. C’est le plancher de votre posture. Il accepte exactement trois valeurs :
default_verdictQuand aucune règle ne correspond…
audit (défaut)Autorise l’appel, mais l’enregistre. Tout observer, ne rien bloquer — l’endroit sûr pour commencer.
allowAutorise et journalise, sans enregistrement de revue.
denyBloque tout ce qu’une règle ne permet pas explicitement — une posture default-deny que vous associez à des règles allow.
deny est default-deny : tout appel d’outil que vos règles n’autorisent pas explicitement est bloqué. Puissant, mais il arrêtera les appels que vous avez oublié de mettre en liste blanche. Déployez d’abord une politique default-deny sous le mode shadow et surveillez le flux d’événements avant de l’appliquer.
Les verdicts qu’une règle peut produire (allow, audit, deny, sanitize, pending_approval, cap_cost) sont couverts dans Verdicts — le verdict par défaut est limité aux trois ci-dessus.

​
4. Attacher la politique à une clé

Une clé adhère à une politique via son firewall_policy_id. Dans la console :
  1. Ouvrez Keys, éditez la clé que votre agent utilise.
  2. Définissez Firewall policy sur la politique que vous avez créée (cela écrit firewall_policy_id).
  3. Enregistrez. Le prochain appel que cette clé effectue est gouverné.
La liaison vit sur la clé, dans la passerelle — votre agent continue d’envoyer le même Authorization: Bearer sk-orca-… et le même corps de requête. Aucun changement dans le code d’appel d’outils de votre agent. 
# Your agent's relay call is unchanged. The attached policy is enforced
# at the gateway before any tool call in the response is dispatched.
curl https://api.orcarouter.ai/v1/chat/completions \
  -H "Authorization: Bearer sk-orca-..." \
  -H "Content-Type: application/json" \
  -d '{
    "model": "gpt-4o",
    "messages": [{"role": "user", "content": "delete the staging table"}],
    "tools": [{"type": "function", "function": {"name": "db.query"}}]
  }'
Si une règle refuse un appel d’outil sur la surface inbound, cet appel revient en HTTP 400 avec le code firewall_blocked, nommant l’outil et la raison — voir à quoi ressemble un block.

​
5. Résolution : attachée → défaut de l’espace de travail

Pour tout appel d’outil, la passerelle résout quelle politique s’applique dans cet ordre :
Si le firewall_policy_id de la clé appelante pointe vers une politique qui existe et est activée, cette politique s’applique.
Sinon, la politique is_default activée de l’espace de travail s’applique (si elle est définie). Au plus une politique par espace de travail peut être le défaut ; promouvoir un nouveau défaut rétrograde l’ancien dans la même transaction.
Aucun attachement et aucun défaut signifie aucune politique. Avec le mode observe activé, l’appel est autorisé et journalisé comme une lacune de couverture ; avec lui désactivé, l’appel est autorisé silencieusement.
Une politique attachée mais désactivée retombe sur le défaut de l’espace de travail — elle ne désactive pas l’application. (Cela diffère des guardrails, où un attachement désactivé se résout en aucun.) Pour retirer une clé de la portée du firewall, détachez-la (définissez firewall_policy_id à 0), ne désactivez pas seulement sa politique.
Pour faire d’une politique le défaut de chaque clé non attachée, éditez-la et définissez-la comme défaut de l’espace de travail plutôt que d’attacher les clés une par une — voir Gérer les politiques.

​
6. Vérifier qu’elle a pris effet

Avant de vous y fier, confirmez que la politique se déclenche comme vous l’attendez :
  • Testez-la — l’onglet Test du sandbox exécute la politique en dry-run contre un appel d’outil d’échantillon et renvoie le verdict, la règle correspondante et la raison. Rien n’est dispatché ni persisté. Voir Tester les règles.
  • Surveillez le flux d’événements — une fois que la clé prend du trafic réel, Events montre chaque évaluation, filtrable par verdict, surface, outil et exécution.
Déployez toute politique appliquante d’abord derrière le mode shadow : elle évalue et journalise exactement comme elle le ferait en production, mais rétrograde chaque verdict appliquant en audit et préfixe la raison [shadow] would …. Désactivez le mode shadow une fois que le flux d’événements montre qu’elle se déclenche sur ce que vous attendez et sur rien d’autre.

​
Où aller ensuite

Rédiger des règles

Le langage de correspondance complet — globs d’outils, clauses d’arguments, listes d’egress, assainisseurs.

Liste blanche d'outils

Associez un verdict par défaut deny à des règles allow explicites.

Gérer les politiques

Défauts, activer/désactiver, versioning et restauration.

Pourquoi le zero trust

Pourquoi gouverner les actions — pas seulement le texte — compte pour les agents.
Pour les menaces qu’une politique est censée arrêter, voir appels d’outils dangereux et agence excessive.