Passer au contenu principal
Vous avez une politique que vous voulez placer devant la production. La peur n’est pas la politique — c’est de la basculer et de découvrir qu’elle bloque un outil dont votre agent a réellement besoin, ou masque un champ dont votre app dépend. Le correctif n’est pas plus de tests dans une sandbox ; c’est de déployer contre du trafic réel dans une posture qui ne peut rien casser, puis de resserrer seulement une fois que vous avez vu ce qui se déclenche. Cette recette est ce déploiement : observe → shadow → enforce, avec autonomie balanced avant tight. Vous restez dans la console (ou l’API REST) tout du long ; l’agent continue d’appeler https://api.orcarouter.ai/v1/... exactement comme avant.
Nouveau dans le modèle ? Lisez Modes d’application pour ce que chaque posture fait mécaniquement, et le référentiel Secure Agents pour ce que chaque niveau d’autonomie définit. Cette page est la séquence — l’ordre dans lequel vous basculez les interrupteurs.

​
1. Le déploiement de sécurité IA en trois mouvements

Tout le déploiement échange de l’autonomie contre de la sécurité en trois étapes, chacune vérifiée contre du trafic en direct avant la suivante :

Observe

Autorisez tout, journalisez tout. Les appels d’outils non couverts atterrissent dans Discovered Tools ; les règles de guardrail flag enregistrent les correspondances sans changer le trafic. Vous apprenez la forme réelle de votre agent.

Shadow

Une vraie politique évalue chaque appel, mais chaque verdict appliquant est rétrogradé en audit et journalisé [shadow] would …. Vous voyez exactement ce qui bloquerait — sans que rien ne soit réellement bloqué.

Enforce

Shadow désactivé. deny bloque, mask redacte, pending_approval met en attente. L’autonomie passe de large (balanced) à serrée (tight), et votre agent est gouverné.
La discipline est l’enjeu : vous n’appliquez jamais une règle que vous n’avez pas d’abord regardée se déclencher en shadow contre votre propre trafic.

​
2. Mouvement un — observe (autonomie = permissive)

Partez aussi large que possible. Appliquez le niveau d’autonomie permissive depuis Firewall → Posture (Developer+) — ou POST /api/workspace/firewall/autonomy. Il active le mode observe de l’espace de travail et ne laisse aucune politique appliquante, de sorte que chaque appel soit autorisé et chaque appel non couvert soit journalisé comme une lacune de couverture. 
# Console: Firewall → Posture → apply "permissive"
# or, via the REST API on your session token:
curl https://api.orcarouter.ai/api/workspace/firewall/autonomy \
  -H "Authorization: Bearer <your console access token>" \
  -H "X-Workspace-Id: <workspace>" \
  -H "Content-Type: application/json" \
  -d '{"level": "permissive"}'
Les routes /api/workspace/firewall/* s’exécutent sur votre session de console / token d’accès, pas sur une clé de relais sk-orca-.... Appliquer un niveau d’autonomie est une écriture d’espace de travail — Developer+. Seuls les appels de modèle /v1/* utilisent la clé de relais.
Maintenant, pointez du trafic réel dessus et laissez-le tourner. Surveillez deux flux :
  • Firewall → Discovered Tools (Member) — chaque outil que votre agent appelle, marqué covered ou gap. C’est l’entrée pour vos règles : vous êtes sur le point d’écrire de la politique pour du trafic qui se produit réellement, pas des hypothèses.
  • Guardrails → Matches (Member) — si vous avez ajouté des règles à action flag, chaque correspondance qu’elles enregistrent, sans toucher la requête.
Laissez-le tourner jusqu’à ce que Discovered Tools cesse de faire remonter de nouveaux outils. Cette liste stable est votre spécification de rédaction de règles.

​
3. Mouvement deux — shadow (une vraie politique, zéro blocage)

Maintenant, rédigez la politique que vous voulez vraiment — globs d’outils, clauses d’arguments, listes d’egress, un plafond cap_cost — et activez le shadow_mode avant de l’attacher. (Construisez les règles à partir des règles du firewall ; le modèle de politique complet est dans la référence Firewall.) 
{
  "name": "prod-rollout",
  "enabled": true,
  "shadow_mode": true,
  "default_verdict": "audit",
  "rules": [
    { "priority": 10, "tool_name_glob": "shell.exec", "verdict": "deny" },
    { "priority": 20, "tool_name_glob": "*",          "verdict": "cap_cost", "cap_cost_cents": 1000 }
  ]
}
Avec shadow_mode: true, ce deny et ce cap_cost sont tous deux rétrogradés en audit au moment de l’évaluation — le moteur calcule le verdict réel, le journalise préfixé [shadow] would …, et laisse passer l’appel. Attachez la politique aux clés que vous déployez (définissez firewall_policy_id sur la clé) ou faites-en le défaut de l’espace de travail. Puis lisez Firewall → Events / Runs (Developer+) filtré sur le préfixe [shadow] et confirmez les deux côtés :
Chaque appel shell.exec montre [shadow] would deny. Chaque exécution qui franchit votre plafond montre [shadow] would cap_cost. La politique voit le trafic pour lequel vous l’avez construite.
Aucun outil légitime n’apparaît avec un verdict would-block. C’est la vérification des faux positifs — la raison pour laquelle le shadow existe. Si un outil dont vous avez besoin est signalé, corrigez la règle et re-regardez avant d’appliquer quoi que ce soit.
Les guardrails n’ont pas de shadow au niveau de la politique. L’équivalent est l’action flag par règle : elle enregistre une correspondance dans le flux Matches et ne change rien, de sorte que vous puissiez mesurer une règle de contenu avant de la basculer en block ou mask. Exécutez vos règles de guardrail comme flag à travers ce même mouvement.

​
4. Mouvement trois — enforce (autonomie balanced, puis tight)

Quand le journal shadow semble correct, appliquez en deux étapes, pas une. Ne sautez pas directement au deny par défaut. D’abord, balanced. C’est la première posture appliquante recommandée : le verdict par défaut du firewall est audit, mais les actions les plus destructrices (comme le shell destructeur) sont refusées, et le guardrail PII Shield s’exécute en audit-only — il signale la PII sans la masquer encore. Vous bloquez maintenant la pire chose tout en observant encore le reste. Désactivez le shadow_mode sur votre propre politique dans le même mouvement afin que ses verdicts deny / cap_cost passent en direct aux côtés du référentiel. 
curl https://api.orcarouter.ai/api/workspace/firewall/autonomy \
  -H "Authorization: Bearer <your console access token>" \
  -H "X-Workspace-Id: <workspace>" \
  -H "Content-Type: application/json" \
  -d '{"level": "balanced"}'
Surveillez Events pendant une heure. De vrais blocks apparaissent maintenant sans le préfixe [shadow]. Un appel d’outil refusé renvoie une HTTP 400 firewall_blocked ; il est skip-retry et ne coûte aucun token de modèle. Puis, tight. Une fois que balanced est calme, passez au deny par défaut. Le niveau tight refuse par défaut, refuse le shell destructeur et l’egress SSRF, et applique PII Shield + Secrets Blocker — la PII est masquée sur la requête avant que le modèle ne la voie, et les secrets dans vos requêtes sont bloqués. Un prompt bloqué renvoie une HTTP 400 guardrail_blocked, ne coûte aucun quota, et est skip-retry.
ÉtapeFirewall (actions)Guardrails (texte)Ce que vous prouvez
permissiveObserve ; rien bloquéflag seulementLa forme réelle du trafic
balancedAudit par défaut ; shell destructeur refuséPII signaléeLe pire cas est arrêté
tightDeny par défaut ; outils shell + fetch (SSRF) refusésPII masquée, secrets bloquésZero-trust complet
Réserve sur le streaming pour la PII. Sous tight, PII Shield masque la PII sur la requête avant que le modèle ne la voie — c’est actif. Le masquage côté sortie d’une réponse streamée n’est pas encore actif ; un block de sortie est appliqué en streaming (le scanner coupe le flux). Si vous dépendez de la redaction de la sortie du modèle, vérifiez votre combinaison stage/stream dans l’onglet Test du guardrail d’abord. Voir Guardrails.

​
5. La trappe de secours — annulation en un clic

Chaque changement d’autonomie est une seule transaction qui capture en snapshot votre posture antérieure, de sorte que vous puissiez revenir directement en arrière depuis Firewall → Posture (ou POST /api/workspace/firewall/autonomy/undo/:audit_id). Vous pouvez aussi simplement réappliquer un niveau plus souple — faire redescendre tight à balanced, ou balanced à permissive — à tout moment.
L’annulation restaure à partir du snapshot d’audit du plus récent apply. Si vous avez fait des éditions manuelles de politique depuis l’apply que vous annulez, ce snapshot n’est plus le dernier inutilisé et l’annulation décline plutôt que d’emporter silencieusement ces éditions. Quand cela se produit, réappliquez plutôt un niveau plus souple — c’est toujours disponible.

​
6. D’où viennent les verdicts de chaque mouvement

Le déploiement ne bloque jamais quelque chose que vous n’avez pas demandé, parce que chaque posture correspond à un mécanisme explicite et observable :
PostureMécanismeRésultat
Observefirewall_observe_mode de l’espace de travail activé + guardrail flagAutoriser + journaliser lacunes / correspondances
Shadowshadow_mode par politiqueVerdict réel calculé, rétrogradé en audit, journalisé [shadow] would …
Enforceshadow_mode désactivé + autonomie tight/balanceddeny / mask / cap_cost passent en direct
Les quatre termes — mode observe, le verdict audit, l’action flag, et shadow_mode — sont des interrupteurs distincts, documentés côte à côte dans Modes d’application.

​
7. Étapes suivantes

Modes d'application

La carte des mécanismes derrière observe, shadow et enforce.

Référentiel Secure Agents

Ce que chaque niveau d’autonomie définit, et comment le simuler d’abord.

Maîtriser un agent autonome

L’étape suivante une fois que vous avez appliqué : plafonds de coût, détection d’anomalies, et approbations.

Agent Firewall

Politiques, règles, verdicts, mode shadow, et la passerelle MCP en entier.
Un go-live auquel vous pouvez faire confiance est un déploiement, pas un interrupteur. Observez ce que fait votre agent, shadow la politique contre son trafic réel, puis appliquez — balanced avant tight — et chaque règle est vérifiée en production avant qu’elle ne le bloque jamais.