Passer au contenu principal
Vous avez rédigé une politique firewall — une posture default-deny, un deny sur shell.exec, une allow-list d’egress — et vous pensez qu’elle est correcte. Mais l’activer contre le trafic de production des agents est un acte de foi : une seule règle trop large et vous bloquez des appels que vos agents effectuent légitimement. Le mode shadow du firewall est l’interrupteur de déploiement sûr. C’est un flag par politique qui indique à la passerelle d’évaluer la politique exactement comme elle le ferait en production, de tout journaliser, mais de ne rien bloquer. Chaque verdict appliquant est rétrogradé en audit, et la raison de l’événement est préfixée [shadow] would … afin que vous puissiez lire précisément ce que la politique aurait fait — sans qu’elle n’ait encore rien fait.
Le mode shadow est un flag sur la politique, défini dans la console (ou via les routes de gestion /api/workspace/firewall/policies, qui utilisent votre session / token d’accès — pas une clé de relais sk-orca-…). Le basculer est une action Developer+. Les appels de relais /v1/* de votre agent ne changent pas.

​
1. Ce que fait le mode shadow du firewall

Lorsque le flag shadow_mode d’une politique est activé, la passerelle exécute l’évaluation complète — résout la politique, parcourt les règles dans l’ordre de priorité, choisit un verdict — puis, juste avant que le verdict ne prenne effet, rétrograde tout ce qui aurait changé l’appel :
Verdict résoluEn mode shadow
deny→ audit, raison [shadow] would deny — …
sanitize→ audit, raison [shadow] would sanitize — …
pending_approval→ audit, raison [shadow] would pending_approval — …
allow / auditinchangé (déjà non bloquant)
L’appel passe toujours. Rien n’est bloqué, aucun argument n’est redacté, aucune mise en attente humaine n’est ouverte — mais l’événement est enregistré avec le verdict que la politique aurait produit, de sorte que le flux d’événements se lit comme une exécution de production avec l’application désactivée.
Le préfixe [shadow] would … est votre filtre principal. Triez le flux d’événements dessus et vous avez une liste complète de chaque appel que cette politique est sur le point de commencer à bloquer, avant qu’elle n’en bloque un seul.

​
2. Un déploiement concret

Disons que vous avez une politique prod-agents avec une règle deny sur les commandes shell destructrices, et que vous voulez confirmer qu’elle ne se déclenchera sur rien de légitime.
1

Activer le mode shadow

Dans Security → Firewall → Policies, ouvrez prod-agents, basculez Shadow mode sur activé, et enregistrez. La politique garde son attachement et ses règles — elle cesse simplement d’appliquer.
2

Laisser le trafic réel circuler

Vos agents continuent d’appeler la passerelle exactement comme auparavant. Chaque appel d’outil est évalué ; rien n’est bloqué. Donnez-lui une fenêtre représentative — assez longue pour couvrir votre vrai mélange d’outils.
3

Lire les refus potentiels

Ouvrez Events et filtrez sur la raison [shadow]. Chaque ligne montre l’outil, la surface, l’exécution et la règle qui a correspondu — de sorte qu’un [shadow] would deny — destructive shell command sur un appel shell.exec est exactement ce que vous verriez en production, moins le HTTP 400.
4

Désactiver le mode shadow

Une fois que le flux montre la politique se déclenchant sur ce que vous attendez et sur rien d’autre, basculez Shadow mode sur désactivé. Dès le prochain appel, ces événements [shadow] would deny deviennent de vrais refus firewall_blocked.
Si le mode shadow a fait remonter un faux positif — un appel légitime qui a correspondu à une règle deny — corrigez la règle (resserrez le glob ou ajoutez une clause d’argument) tout en restant en shadow, et surveillez à nouveau le flux. Vous itérez contre le trafic réel avec un rayon d’impact nul.

​
3. Ce que le mode shadow n’adoucit pas

Le mode shadow est un aperçu de la politique, pas un interrupteur d’arrêt maître.
Les skills gouvernés s’appliquent toujours sous une politique shadow. Un skill en mode block refuse toujours, et un skill en mode quarantine met toujours en attente d’approbation, même lorsque la politique correspondante est en shadow. Le mode d’application d’un skill est une propriété de l’état de revue du skill, pas de la politique que vous prévisualisez — mettre une politique en shadow n’a jamais été une demande de dé-quarantaine d’un skill. La politique reste marquée comme en shadow dans les événements, mais la disposition du skill l’emporte.
Quelques autres limites à connaître :
Seuls les verdicts appliquants (deny, sanitize, pending_approval) sont rétrogradés. Un allow ou audit laisse déjà passer l’appel, donc il n’y a rien à adoucir — ces événements portent quand même le badge shadow pour que vous puissiez savoir que la politique était en shadow lorsqu’ils ont été enregistrés.
Une règle cap_cost se résout en un allow ou deny concret selon la dépense accumulée de l’exécution, et c’est ce verdict résolu que le mode shadow rétrograde ensuite — un refus potentiel de plafond apparaît comme [shadow] would deny comme n’importe quel autre.
Le mode shadow vit sur chaque politique indépendamment. Vous pouvez mettre en shadow une toute nouvelle politique pendant qu’une politique éprouvée continue d’appliquer — il n’y a pas d’interrupteur shadow à l’échelle de l’espace de travail qu’on oublierait de désactiver.

​
4. Le mode shadow vs. les autres réglages de déploiement

Le firewall vous donne trois contrôles différents de type « ne rien casser pour l’instant ». Ils résolvent des problèmes différents :
ContrôlePortéeQuestion à laquelle il répond
Mode shadowUne politique« Que bloquerait cette politique si je l’appliquais ? »
Verdict par défaut auditUne politique« Tout journaliser que nulle règle ne nomme, ne rien bloquer. »
Mode observeEspace de travail« Quels outils s’exécutent sans aucune politique les couvrant ? »
Le mode shadow est celui auquel recourir lorsque vous avez une politique réelle et appliquante et que vous voulez mesurer son impact exact avant qu’elle ne change le trafic. Un verdict par défaut audit concerne la queue non correspondante d’une politique ; le mode observe concerne les lacunes de couverture à travers l’espace de travail, pas l’application d’une politique spécifique.
Vous pouvez les empiler. Une nouvelle politique default-deny sous le mode shadow est le déploiement le plus doux possible : même le plancher default-deny ne fait que journaliser [shadow] would deny au lieu de bloquer, de sorte que vous voyez l’ensemble complet des appels que vos règles allow ne couvrent pas encore avant que le deny ne soit en live.

​
5. Les packs de conformité atterrissent d’abord en shadow

Lorsque vous installez un pack de conformité en mode observe (non appliquant), les politiques firewall qu’il matérialise sont créées avec le mode shadow activé — elles évaluent et journalisent contre votre trafic sans rien bloquer. Promouvoir le pack pour appliquer fait sortir ces politiques du shadow. Même mécanisme, appliqué pour vous : exécutez les contrôles en dry-run, lisez les verdicts potentiels, puis appliquez.

​
6. Le basculer

Dans la console, le mode shadow est un toggle sur l’éditeur de politique. Le même flag est exposé sur l’API de gestion comme shadow_mode sur l’objet politique — ces routes utilisent votre session / token d’accès et requièrent Developer+ :
Méthode & cheminRôleNote
PUT /api/workspace/firewall/policiesDeveloper+Définir shadow_mode: true / false sur la politique dans le corps.
GET /api/workspace/firewall/policies/:idMemberLire l’état shadow_mode actuel d’une politique.
Chaque changement écrit une ligne d’audit et incrémente l’entier version de la politique, de sorte qu’activer et désactiver le shadow est lui-même tracé.

​
Où aller ensuite

Créer et attacher une politique

La configuration en deux étapes que le mode shadow déploie — créez la politique, attachez une clé.

Journal d'événements

Où [shadow] would … apparaît — filtrez, plongez dans les exécutions et les règles.

Verdicts

Les verdicts appliquants que le mode shadow rétrograde, et ce que fait chacun en live.

Modes d'application

Comment shadow, audit et observe s’insèrent dans le modèle d’application plus large.
Pour les menaces qu’une politique arrête une fois que vous désactivez le shadow, voir appels d’outils dangereux et agence excessive.