Passer au contenu principal
La posture la plus sûre pour un agent autonome est default-deny : bloquer chaque outil par défaut, puis autoriser explicitement seulement la poignée que votre agent est censé utiliser. Tout ce qu’un agent récupère de nouveau — un skill communautaire, un serveur MCP mal configuré, un outil qu’un jailbreak a persuadé le modèle d’appeler — est refusé parce que vous ne l’avez jamais autorisé, pas parce que vous vous êtes souvenu de le bloquer. Cette page présente le pattern de liste blanche d’outils pour les agents sur api.orcarouter.ai : un verdict par défaut deny plus une ou plusieurs règles allow keyées sur un tool_name_glob. Pour le langage de correspondance complet derrière ces règles, voir Règles du Firewall.
Les listes blanches sont rédigées dans la console sous Security → Firewall, ou via les routes de gestion /api/workspace/firewall/* (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 ou éditer une politique est une action Developer+.

​
1. Pourquoi default-deny pour les agents

Une liste de blocage (« refuser shell.exec, refuser db.delete, … ») n’est jamais plus complète que la dernière menace à laquelle vous avez pensé. Une liste blanche inverse la charge de la preuve : la passerelle refuse tout ce que la politique ne permet pas explicitement, de sorte qu’un outil inconnu est fermé par construction.

Verdict par défaut = deny

Le plancher de la politique. Sans règle correspondante, chaque appel d’outil est bloqué.

Les règles allow ré-autorisent des outils

Chaque règle allow nomme les outils que vous utilisez réellement — par nom exact ou par glob.
Le moteur parcourt les règles d’une politique dans l’ordre de priorité et la première correspondance gagne ; si rien ne correspond, il retombe sur le default_verdict de la politique. Donc une liste blanche est simplement : des règles allow de haute priorité pour vos vrais outils, avec un plancher deny attrapant tout le reste.

​
2. Un exemple : mettre en liste blanche les outils d’un agent de recherche

Disons que votre agent n’a jamais besoin que de chercher sur le web et de lire depuis une base de connaissances — des outils nommés web.search et kb.read. Tout le reste (shell, écritures de fichiers, mutations de base de données, tout outil qu’une injection de prompt pourrait invoquer) doit être refusé. Construisez la politique comme deny par défaut + deux règles allow :
1

Créer la politique avec un défaut deny

Security → Firewall → Policies → New policy. Nommez-la, laissez Enabled activé, et définissez le verdict par défaut sur deny. C’est le plancher fermé — voir Créer une politique.
2

Ajouter une règle allow par famille d'outils

Dans l’éditeur de règles, ajoutez deux règles, toutes deux verdict = allow :
prioritytool_name_globverdict
10web.searchallow
20kb.*allow
web.search est une correspondance exacte ; kb.* est un glob de préfixe qui autorise kb.read, kb.search, et tout futur outil kb.* sans ré-éditer la politique.
3

L'attacher à la clé de votre agent

Définissez le firewall_policy_id de la clé sur cette politique (ou faites-en le défaut de l’espace de travail). Le corps de requête de votre agent est inchangé.
Désormais web.search et kb.read passent ; un appel à shell.exec ne correspond à aucune règle allow, atteint le plancher deny, et revient en HTTP 400 avec le code firewall_blocked sur la surface inbound — voir à quoi ressemble un block.
Rédigez les règles allow comme des noms exacts ou des préfixes étroits (kb.*), pas des suffixes larges. Un *.read lâche autoriserait kb.read et secrets.read — l’opposé de ce à quoi sert une liste blanche. Gardez le glob aussi serré que le nommage des outils le permet.

​
3. Le glob en un écran

tool_name_glob est une petite grammaire sensible à la casse — pas de regex, temps linéaire. Les formes qui comptent pour une liste blanche :
MotifAutorise
web.searchExactement cet outil.
kb.*Préfixe — kb.read, kb.search (pas kb nu).
*.searchSuffixe — web.search, kb.search, et search nu.
*.tools.*Infixe — byo.tools.fetch et similaires.
Pour la grammaire complète (règles infixes, cas limites, globs de nom de skill), voir Syntaxe glob et la référence des Règles du Firewall.
Un glob *.suffix correspond aussi au verbe nu, sans namespace — *.search autorise un outil littéralement nommé search, pas seulement web.search. Les fournisseurs et les serveurs MCP sans namespace exposent des outils sous des verbes nus, donc un suffixe mis en liste blanche est plus large qu’il n’y paraît. Préférez des noms exacts ou des préfixes lorsque vous voulez une liste blanche serrée.

​
4. Le déployer sans casser votre agent

Default-deny est la posture la plus susceptible de bloquer un outil dont vous aviez oublié avoir besoin. Mettez-la en place par étapes :
Activez le mode shadow. La politique évalue et journalise exactement comme elle le ferait en live, mais rétrograde chaque deny en audit avec la raison préfixée [shadow] would …. Faites circuler du trafic réel, puis lisez le flux d’événements.
Les Outils découverts listent chaque outil que l’espace de travail a vu, marqué covered ou gap. Les événements « would-deny » du mode shadow plus les lacunes vous indiquent exactement quelles règles allow il vous manque encore.
Le sandbox Test 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 de dispatché, rien de persisté. Confirmez que web.search autorise et que shell.exec refuse, puis désactivez le shadow.
Un appel inbound refusé ne coûte aucun token de modèle — il est bloqué avant que le modèle amont ne s’exécute — et est marqué skip-retry, de sorte qu’un outil bloqué ne consommera pas un budget de retry en bloquant à nouveau. Voir Verdicts.

​
5. Où aller ensuite

Bloquer des outils spécifiques

L’inverse — gardez un plancher default-allow et refusez des outils nommés.

Valider les arguments

Autorisez un outil, mais seulement avec des arguments sûrs (db.query mais pas DROP TABLE).

Priorité des règles

Comment first-match-wins ordonne vos règles allow au-dessus du plancher deny.

Verdicts

allow, audit, deny, sanitize, pending_approval, cap_cost.
Pour la menace que ce pattern traite, voir agence excessive et appels d’outils dangereux. Pour savoir pourquoi default-deny est le référentiel des agents, voir pourquoi le zero trust.