Passer au contenu principal
Vous avez rédigé une règle de firewall — un deny sur shell.exec, une allow-list d’egress, une clause d’argument qui ne se déclenche que sur rm -rf — et maintenant vous voulez savoir qu’elle fait exactement ce que vous pensez avant qu’elle ne change un seul appel d’outil de production. Le firewall vous donne trois façons non destructrices de tester les règles de firewall, chacune répondant à une question différente :

Dry-run d'un appel

Le sandbox Test fait passer un seul appel d’outil synthétique à travers le vrai moteur et renvoie le verdict — rien de dispatché, rien de journalisé. Developer+.

Rejouer une posture

Simulate rejoue un niveau d’autonomie contre votre trafic récent et compte combien d’appels il bloquerait. Lisible par un Member.

Exécuter contre le trafic réel

Le mode shadow évalue toute une politique sur des appels réels mais rétrograde chaque verdict appliquant en audit. Rayon d’impact nul.
Les trois se configurent via la console (ou les routes de gestion /api/workspace/firewall/*, qui s’authentifient avec votre session / token d’accès — pas une clé de relais sk-orca-…). Les appels de relais /v1/* de votre agent ne changent jamais pendant que vous testez.

​
1. Tester les règles de firewall avec le sandbox Test en dry-run

Le sandbox Test est la boucle la plus serrée : donnez-lui un seul appel d’outil synthétique et il exécute le vrai moteur d’évaluation — résolution complète de la politique, règles parcourues dans l’ordre de priorité, first-match-wins — puis renvoie le verdict, la règle qui l’a produit, et la raison lisible par un humain. L’appel est un dry run : rien n’est dispatché vers aucun outil, et rien n’est écrit dans le flux d’événements ni dans l’inventaire Discovered-tools. Il répond précisément à une question : étant donné ce nom d’outil exact et ces arguments, que décide ma politique — et quelle règle le décide ?
Le sandbox Test est Developer+. Il peut prévisualiser contre une politique brouillon non enregistrée par id et la réponse fait remonter le nom de politique et le label de règle correspondants, donc il se situe plus près d’un aperçu de surface d’écriture qu’une lecture simple — contrairement à Simulate et aux autres vues en lecture, qui sont ouvertes à chaque membre.

​
Un dry run concret

Disons que vous avez ajouté une règle qui devrait refuser shell.exec uniquement quand la commande contient rm -rf. Vous voulez confirmer deux choses d’un coup : la commande dangereuse est refusée, et une innocente passe quand même.
1

Tester l'appel dangereux

Dans Security → Firewall, ouvrez l’onglet Test, choisissez la surface response, entrez le nom d’outil shell.exec et les arguments {"command": "rm -rf /data"}, et exécutez. La réponse nomme le verdict et la règle correspondante :
{
  "verdict": "deny",
  "policy_name": "prod-agents",
  "rule_label": "block destructive shell",
  "reason": "destructive shell command",
  "gap": false,
  "shadow_mode": false
}
2

Tester l'appel innocent

Exécutez-le à nouveau avec {"command": "ls -la"}. La clause d’argument ne correspond plus, donc la règle retombe sur le défaut de la politique — vous devriez voir allow ou audit et un rule_label vide. Si rm -rf refuse et ls -la non, votre clause d’argument est scopée correctement.
3

Prévisualiser un brouillon avant de l'attacher

Passez un policy_id pour évaluer contre une politique brouillon spécifique plutôt que celle vers laquelle votre trafic se résout actuellement — de sorte que vous pouvez prouver qu’une nouvelle politique est correcte avant de lui attacher une clé ou de la promouvoir en défaut d’espace de travail.
Lisez gap dans la réponse. gap: true signifie qu’une politique s’est résolue mais qu’aucune règle à l’intérieur n’a fait correspondre l’appel (et que l’espace de travail est en mode observe) — l’outil s’est glissé à travers chaque règle et est retombé sur le défaut. C’est un trou de couverture à combler avant de livrer, pas un verdict en lequel avoir confiance.
Le sandbox Test utilise les mêmes surfaces que l’évaluation en live — inbound, response, mcp, egress (défaut inbound) — donc testez chaque règle sur la surface à laquelle elle est épinglée. Sur inbound, il n’y a pas d’arguments au moment de l’appel, donc une règle sanitize escalade en un block là exactement comme elle le ferait en production ; voir stages pour savoir pourquoi la surface compte.

​
2. Simuler un niveau d’autonomie avant de l’appliquer

Le sandbox Test vérifie un appel. Simulate répond à la question au niveau de la posture : si je passais tout cet espace de travail à un niveau d’autonomie plus strict, combien de mon trafic récent bloquerait-il ? Simulate rejoue les règles deny d’un niveau candidat contre vos événements firewall récents et renvoie l’impact potentiel — noms d’outils et comptes seulement, jamais d’arguments. Il est en lecture seule et lisible par un Member, de sorte que quiconque dans l’équipe peut prévisualiser le rayon d’impact de tight avant qu’un Developer ne s’y engage.
  • tight — default-deny, refus du shell destructeur, refus des outils de forme fetch (le vecteur SSRF), PII Shield + Secrets Blocker appliqués. Simulate montre quelle part de votre trafic réel ce plancher attraperait.
  • balanced — audit par défaut, refus du shell destructeur, PII Shield en audit seulement (signale la PII). La posture de départ recommandée.
  • permissive — observe seulement ; rien d’appliqué.
Simulate ne change rien — c’est un what-if sur les événements passés. Appliquer un niveau d’autonomie (une écriture Developer+) matérialise des lignes de politique et de guardrail autonomy_* réelles et éditables, avec annulation en un clic à partir du snapshot d’audit. Prévisualisez avec Simulate, puis appliquez quand le compte paraît correct.

​
3. Mode shadow : tester contre le trafic réel sans rayon d’impact

Le sandbox Test et Simulate sont des aperçus hors-ligne. Le mode shadow est celui en live : un flag par politique qui évalue la politique sur le trafic d’agent réel, parcourt chaque règle, choisit un verdict — puis rétrograde chaque verdict appliquant (deny, sanitize, pending_approval) en audit et préfixe la raison [shadow] would …. L’appel passe toujours ; rien n’est bloqué, redacté ou mis en attente. Cela fait que le flux d’événements se lit comme une exécution de production avec l’application désactivée. Filtrez sur [shadow] et vous avez une liste complète de chaque appel que la politique est sur le point de commencer à bloquer — avant qu’elle n’en bloque un.
Méthode de testS’exécute contreQuestion à laquelle elle répond
Sandbox TestUn appel synthétique« Quel verdict reçoit cet appel exact, et quelle règle décide ? »
SimulateÉvénements récents« Combien d’appels un niveau d’autonomie plus strict bloquerait-il ? »
Mode shadowTrafic réel« Que bloquerait cette politique à travers le trafic de production réel ? »
Le mode shadow est le plus profond des trois — couverture en live complète avec un rayon d’impact nul. Il a sa propre page : Déployer une politique firewall avec le mode shadow parcourt le toggle, les raisons [shadow] would …, et le passage à l’application.

​
4. Un ordre de test pratique

Les trois outils se composent en un seul chemin de déploiement sûr — la vérification la moins coûteuse d’abord, la couverture la plus large en dernier :
1

Dry-run des règles que vous venez d'écrire

Utilisez Test pour confirmer que chaque nouvelle règle se déclenche sur les appels qu’elle devrait et passe ceux qu’elle ne devrait pas — y compris les cas négatifs. Rapide, Developer+, rien de persisté.
2

Jauger la posture (optionnel)

Si vous recourez à un niveau d’autonomie plutôt qu’à des règles écrites à la main, Simulate le niveau et lisez le compte d’appels potentiellement bloqués contre le trafic réel avant de l’appliquer.
3

Shadow contre le trafic réel

Activez le mode shadow et laissez circuler une fenêtre représentative d’appels réels. Lisez les événements [shadow] would … ; resserrez toute règle qui fait remonter un faux positif — toujours en shadow, rayon d’impact nul.
4

Appliquer

Quand le flux se déclenche sur ce que vous attendez et sur rien d’autre, désactivez le shadow. Le prochain appel applique pour de vrai.
Tester prévisualise la politique, pas les skills gouvernés. Un skill en mode block ou quarantine applique toujours même sous une politique en shadow — la disposition de revue du skill l’emporte. Mettre une politique en shadow n’a jamais été une demande de dé-quarantaine d’un skill.

​
5. Référence API

Ces routes de gestion utilisent votre session / token d’accès et sont à portée d’espace de travail :
Méthode & cheminRôleObjectif
POST /api/workspace/firewall/testDeveloper+Dry-run d’un appel d’outil synthétique contre la politique résolue (ou un policy_id brouillon). Renvoie verdict, policy_name, rule_label, reason, gap, shadow_mode. Rien de dispatché ni journalisé.
GET /api/workspace/firewall/simulate?level=MemberRejouer un niveau d’autonomie contre les événements récents ; renvoie les comptes d’appels potentiellement bloqués.
GET /api/workspace/firewall/policies/:idMemberLire le flag shadow_mode actuel d’une politique.
PUT /api/workspace/firewall/policiesDeveloper+Basculer shadow_mode sur la politique.
Le corps Test prend surface (défaut inbound), un tool_name requis, un args_json optionnel, et un policy_id optionnel pour outrepasser la résolution.

​
Où aller ensuite

Mode shadow

Le déploiement sur trafic réel : [shadow] would …, le filtre d’événements, et le passage à l’application.

Valider les arguments

Scoper une règle à quels arguments — les clauses que le sandbox Test vous laisse vérifier contre rm -rf vs ls -la.

Verdicts

Ce que font allow / audit / deny / sanitize / pending_approval / cap_cost quand un test cesse d’être un test.

Journal d'événements

Où atterrissent les verdicts en shadow — filtrez, plongez dans les exécutions et les règles correspondantes.
Pour la grammaire de correspondance de règles que ces tests exercent, voir la référence complète des règles du firewall ; pour savoir où le test s’insère dans le modèle plus large, voir modes d’application.