Modes d'application : observe, shadow et enforce

Avant qu’une règle bloque le trafic de production, vous voulez savoir qu’elle se déclenche sur les bonnes choses et rien d’autre. OrcaRouter vous donne trois postures — observe, shadow et enforce — qui vous permettent de déployer de manière incrémentale, avec visibilité à chaque étape et sans surprises. Cette page explique ce que chaque posture signifie mécaniquement, comment les traverser, et comment les niveaux d’autonomie les définissent tous en une seule étape.

​

1. Les trois postures en un coup d’œil

​

2. Posture Observe — mesurez avant de régler

La posture observe n’est pas un interrupteur unique. C’est une combinaison de trois mécanismes indépendants qui produisent ensemble « autoriser tout, enregistrer tout » :

​

Mode observe du Firewall (réglage de l’espace de travail)

Quand un appel d’outil se résout à aucune politique du tout — pas d’attachement de clé et pas de défaut d’espace de travail — le mode observe au niveau de l’espace de travail du firewall détermine ce qui se passe :

• Mode observe activé : l’appel est autorisé et journalisé comme un écart de couverture. La vue Discovered Tools se remplit de ces événements d’écart, montrant exactement quels outils vos agents exécutent sans aucune règle les couvrant.
• Mode observe désactivé : l’appel est autorisé silencieusement — byte-identique à un espace de travail qui n’a jamais activé la fonctionnalité.

Le mode observe est la surface de détection des écarts. Il ne se déclenche que quand aucune politique ne se résout. Ce n’est pas la même chose qu’avoir une politique définie sur audit.

​

Verdict audit du Firewall (défaut par politique)

Quand une politique se résout mais qu’aucune règle ne correspond à un appel d’outil, le default_verdict de la politique s’applique. La valeur par défaut de default_verdict est audit — autorise l’appel et l’enregistre pour revue. Une nouvelle politique sans règles et sans changement de configuration ne bloque rien et n’autorise rien silencieusement : elle audite tout ce qu’elle voit. audit est aussi un verdict de règle normal. Une règle qui correspond et produit audit laisse passer l’appel et l’enregistre — l’analogue du mode audit des guardrails pour le firewall.

​

Action flag des Guardrails (action de règle par règle)

Côté guardrails, l’action flag est l’équivalent d’observe : la règle se déclenche, une correspondance est enregistrée dans le flux Matches, et la requête continue sans modification. Pas de block. Pas de redaction. Utilisez flag quand vous voulez mesurer une règle — voir à quelle fréquence elle se déclenche et sur quoi — avant de vous engager sur block ou mask.

---

Ensemble, ces trois mécanismes produisent la posture observe : le mode observe intercepte les appels d’outils non couverts ; les verdicts audit couvrent les appels d’outils sous une politique mais pas encore sous une règle spécifique ; les actions flag couvrent les vérifications guardrail que vous n’êtes pas encore prêt à appliquer.

​

3. Posture Shadow — validez avant d’appliquer

Le mode shadow est un flag par politique (shadow_mode: true) sur une politique firewall. Quand il est activé :

• La politique évalue chaque appel d’outil exactement comme elle le ferait en production — les règles sont comparées, les verdicts calculés, les prédicats d’arguments testés.
• Chaque verdict appliquant (deny, sanitize, pending_approval) est rétrogradé en audit avant d’atteindre l’outil.
• La raison journalisée est préfixée [shadow] would … afin que vous puissiez voir dans le flux d’événements exactement ce qui aurait été bloqué, assaini ou mis en attente.

Le mode shadow est votre interrupteur de déploiement sûr. Rédigez une politique, activez shadow, pointez le trafic réel dessus, regardez les vues events et runs pendant quelques heures ou jours, confirmez que la politique se déclenche sur les bons outils et rien d’inattendu, puis désactivez shadow pour commencer à appliquer.

​

4. Posture Enforce — vrais verdicts, vraies conséquences

Dans la posture enforce, rien n’est rétrogradé :

• Firewall deny → l’agent voit une erreur d’outil (MCP) ou HTTP 400 firewall_blocked (surface inbound). L’erreur nomme l’outil et la raison. Marqué skip-retry.
• Firewall sanitize → les sous-chaînes correspondantes sont redactées des arguments de l’outil et l’appel nettoyé est transféré.
• Firewall pending_approval → l’appel est mis en attente ; l’agent reçoit HTTP 400 firewall_approval_pending et un id d’approbation à interroger.
• Guardrail block → HTTP 400 guardrail_blocked, nommant le guardrail et la règle qui s’est déclenchée. Ne coûte aucun quota.
• Guardrail mask → la correspondance est redactée (ex. jane@acme.com → [EMAIL]) et la requête continue avec le texte assaini.

Pour atteindre la posture enforce : désactivez shadow_mode sur la politique firewall, et changez les actions des règles guardrail de flag en block ou mask selon le cas.

​

5. Déploiement recommandé

​

6. Niveaux d’autonomie — définissez tout d’un coup

Ajuster les politiques règle par règle est le chemin précis. Les niveaux d’autonomie sont le chemin rapide — un seul contrôle qui définit atomiquement la posture Firewall et Guardrails de votre espace de travail en une transaction, avec annulation en un clic : Appliquez via POST /api/workspace/firewall/autonomy (Developer+). L’endpoint Simulate (GET /api/workspace/firewall/simulate?level=) prévisualise ce qu’un changement de niveau ferait avant que vous ne l’appliquiez.

​

7. Carte des mécanismes — quel réglage fait quoi

Ce tableau est la référence authoritative. Les quatre termes sont distincts — ne les confondez pas :

---

Les modes d’application ne sont pas un simple on/off. Progressez à travers observe → shadow → enforce et vos règles sont vérifiées sur le trafic réel avant de jamais le bloquer.