Passer au contenu principal
Chaque plan de contrôle sur OrcaRouter a deux postures : observe, où la passerelle évalue et journalise ce qu’une politique ferait mais ne change jamais une réponse, et enforce, où la même politique bloque, masque ou met en attente l’appel pour de vrai. Cette séparation vous permet d’observer un framework contre votre trafic réel pendant une semaine avant qu’une seule requête n’échoue — puis de le basculer en production lorsque les chiffres ont l’air corrects. Cette page est la carte côté client de cette frontière : quelle posture est gratuite, laquelle est payante, qui peut la changer, et comment lire l’écart entre les deux avant de vous engager.

1. Pourquoi compliance observe enforce est une porte à deux étapes

Un framework de conformité qui bloque dès le premier jour est un framework que vous désactivez le deuxième jour. La séquence honnête est : installer en observe, lire les chiffres de would-block contre votre propre trafic, combler les lacunes que vous ignoriez, puis passer en production. OrcaRouter intègre cette séquence dans le modèle de posture afin que vous n’ayez jamais à deviner. (Installer un pack est une étape payante réservée à l’Admin sur chaque plan — observe et enforce sont deux postures du même pack payant, pas un palier gratuit et un palier payant. Le chemin observe gratuit vit sur les plans Firewall et Guardrails, qui ne portent aucune barrière de plan.)

Observe — gratuit sur Firewall & Guardrails

Mettez une politique Firewall en shadow_mode ou un Guardrail en audit, et la passerelle l’évalue contre le trafic réel et enregistre ce qu’elle aurait fait — sans jamais changer une réponse. Aucun plan requis ; les écritures sont réservées à Developer+. Parcourir le catalogue de conformité et lire les rollups de readiness est gratuit pour tout membre de l’espace de travail également.

Packs de conformité — payant, Admin uniquement

Le plan du pack de conformité — installer un pack (même en observe), configurer les contrôles, et passer en production — requiert un plan payant et le rôle Admin de l’espace de travail. Le passage en production est le moment où les règles matérialisées du pack commencent à réellement bloquer, masquer et mettre en attente les appels.
Observe n’est pas un essai édulcoré. Il exécute le même moteur d’évaluation qu’enforce contre le même trafic réel — il supprime juste l’effet du verdict. Les chiffres que vous voyez en observe sont les chiffres que vous obtiendrez lorsque vous basculerez l’interrupteur.

2. À quoi ressemble chaque posture sur les différents plans

La porte à deux étapes n’est pas propre aux packs de conformité — chaque plan expose un équivalent observe. Même idée partout : évaluer et journaliser, ne pas agir.
PlanPosture observePosture enforce
Pack de conformité (payant)Installé en mode observe — les règles matérialisées journalisent seulementgolive bascule le pack en enforce
Politique Firewallshadow_mode — verdicts journalisés comme [shadow] would …deny / sanitize / pending_approval réels
Espace de travail Firewallfirewall_observe_mode — journalise les appels non couverts comme lacunesLes politiques évaluent et agissent sur les surfaces couvertes
Niveau d’Autonomiepermissive — observe seulement, aucune politique appliquantbalanced / tight — lignes réelles d’audit et de deny
Installer un pack de conformité écrit des politiques Guardrails et Firewall réelles et éditables dans votre espace de travail en posture observe (les politiques firewall atterrissent en shadow_mode). Passer en production n’est qu’un basculement de posture sur des lignes qui existent déjà — pas une réinstallation.

3. Un parcours concret

Voici la boucle observe-vers-enforce complète pour un seul framework. Parcourir le catalogue et lire les rollups est gratuit ; installer le pack (même en observe) et le golive final requièrent tous deux un plan payant et l’Admin.
1

Parcourez le catalogue (gratuit, tout membre)

Ouvrez Compliance dans la console et passez en revue les frameworks disponibles. Tout membre de l’espace de travail peut lire le catalogue, la liste des packs installés et le rollup de readiness — aucun plan requis.
# Read-only, session-authenticated (UserAuth) — done from the console.
GET /api/compliance/catalog
GET /api/compliance/readiness
2

Installez en observe (plan payant, Admin)

Depuis la carte du framework, choisissez Install. Installer un pack de conformité requiert un plan payant — le serveur rejette une installation sur un plan gratuit. Le pack matérialise ses règles de guardrail et de firewall en posture observe (règles firewall en shadow_mode, actions de guardrail contraintes au log seul), de sorte que la passerelle les évalue contre votre trafic réel immédiatement et journalise chaque would-block sans changer une seule réponse.
# Paid + Admin, server-gated. Done from the console.
POST /api/compliance/packs/{key}/install
3

Lisez l'écart (gratuit, tout membre)

La vue de readiness affiche désormais un would-block count par framework : combien de requêtes réelles dans votre fenêtre glissante le framework aurait arrêtées (attribuées aux lignes du plan guardrail du pack). Un nombre élevé est votre signal pour corriger un workflow avant d’appliquer, pas après.
4

Passez en production (plan payant, Admin)

Lorsque les chiffres ont l’air corrects, un Admin sur un plan payant bascule le pack en enforce. Les mêmes règles qui journalisaient bloquent, masquent et mettent en attente désormais — et la politique firewall du pack quitte le shadow_mode.
# Paid + Admin, server-gated. Done from the console.
POST /api/compliance/packs/{key}/golive
Les routes de configuration (/api/compliance/*, /api/guardrail/*, /api/workspace/firewall/*) s’authentifient avec votre session console, pas une clé de relais. Seuls les appels de modèle /v1/* utilisent une clé sk-orca-…. Les exemples ci-dessus sont montrés comme des routes pour la clarté, mais vous les pilotez tous depuis la console.

4. La frontière gratuit / payant, précisément

Sur le plan de conformité, seule la lecture de votre posture est gratuite ; dès l’instant où vous matérialisez un pack vous êtes sur un chemin payant. La vérification de plan est appliquée côté serveur — un appel API direct ne peut pas la contourner.
Parcourir le catalogue de frameworks, lister les packs installés, lire le rollup de readiness, lire la résidence des données configurée et lister les métadonnées de rapport sont ouverts à chaque membre sans frais. Générer le premier rapport de conformité de votre espace de travail en PDF est gratuit aussi.
Installer un pack (même en observe), configurer les contrôles, passer un pack en production (golive), générer des rapports signés supplémentaires au-delà du premier, et exporter les preuves en CSV/JSON requièrent tous un plan payant et le rôle Admin. Le plan de conformité n’a pas de palier observe gratuit — l’installation elle-même est le paywall.
Définir la résidence des données est réservé au rôle Admin de l’espace de travail mais n’est pas derrière un plan payant — tout Admin peut définir la région.
Les rapports sont publiquement vérifiables une fois générés — quiconque possède l’artefact peut confirmer sa signature sans compte via la vérification de rapport. Chaque rapport est signé (PDF, CSV et JSON de même) ; la vérification est ouverte au monde entier.

5. Lisez les chiffres de would-block avant de basculer

Observe existe pour que vous puissiez répondre à une question avec des données plutôt qu’avec du cran : qu’est-ce qui casse quand cela passe en production ? Deux surfaces vous donnent la réponse.
  • Rollup de readiness — comptes de would-block par framework pour les packs de conformité installés (attribués aux lignes du plan guardrail du pack), pour que vous puissiez voir quels frameworks mordent le plus fort contre votre trafic glissant avant de les appliquer. Lisible par tout membre de l’espace de travail.
  • Événements Firewall — enregistrent ce que chaque politique shadow_mode aurait fait ; une ligne [shadow] would deny est un refus qui n’a pas encore eu lieu. Le flux Events est réservé à Developer+ (les lignes portent la provenance des appels d’outils). Les politiques firewall, les réglages, la vue des outils découverts, le simulateur d’autonomie et le flux d’anomalies restent lisibles par tout membre.
  • Correspondances Guardrails — le flux de correspondances enregistre ce que chaque guardrail en mode audit aurait signalé. Lisible par tout membre.
Le même déploiement par étapes fonctionne au niveau de l’autonomie. Appliquez permissive (observe seulement) d’abord, surveillez le flux d’événements, puis montez vers balanced et tight pour les surfaces qui le méritent — avec annulation en un clic depuis le snapshot d’audit. Voir le référentiel secure-agents.

6. Où aller ensuite

Plan gating

Exactement quelles actions de conformité requièrent un plan payant, et ce qui reste gratuit sur chaque palier.

Installer un pack

Matérialisez les règles guardrail et firewall d’un framework en observe — une première étape payante, réservée à l’Admin, avant de passer en production.

Modes d'application

Le vocabulaire de posture complet — observe, shadow, audit et enforce — sur chaque plan.

Responsabilité partagée

Ce que la passerelle applique versus ce qui reste votre décision.
Observe est l’endroit où vous apprenez ce qu’enforce vous coûtera. Sur les plans Firewall et Guardrails vous pouvez observer gratuitement ; sur le plan du pack de conformité, l’installation et le passage en production sont les étapes payantes réservées à l’Admin — lisez d’abord les chiffres de would-block, puis passez en production selon vos conditions.