Passer au contenu principal
Un agent de codage est la chose la plus à fort levier de votre espace de travail et la plus dangereuse. Il exécute shell.exec, édite des fichiers, récupère des URL et charge des skills communautaires — n’importe lequel de ces actes peut rm -rf un volume, lire un .env, ou exfiltrer vers un hôte attaquant. Cette recette verrouille cette surface avec le Firewall : refusez le shell destructeur, validez les arguments des appels que vous autorisez, clôturez l’egress, et mettez les opérations véritablement risquées en attente d’un humain. Rien de cela ne touche le code de votre agent — la politique vit dans la passerelle et est appliquée au prochain appel.
Tout ce qui suit est configuré dans la console (Firewall → Posture / Politiques). Ces routes de gestion utilisent votre session de console, pas une clé de relais. Seuls les appels /v1/* que votre agent effectue portent une clé sk-orca-…. Les éditions de politique nécessitent le rôle Developer.

​
1. Commencez par observer, pas bloquer — le référentiel agent de codage sécurisé

Ne rédigez pas de règles à l’aveugle. Donnez à l’agent sa clé sk-orca-…, puis ouvrez Firewall → Posture et appliquez le niveau d’autonomie balanced. En une seule transaction, cela audite chaque appel d’outil, signale la PII, et refuse le shell destructeur — de sorte que la pire action est déjà clôturée pendant que vous apprenez le reste du comportement de l’agent à partir du trafic réel. Laissez-le tourner, puis lisez Firewall → Discovered tools : chaque outil que l’espace de travail a vu, marqué covered (une règle s’applique) ou gap (aucune ne s’applique). Cette liste est le brouillon de votre allow-list. Quand le flux semble correct, passez à tight (deny par défaut) ou rédigez la politique ciblée ci-dessous.
balanced est la posture de départ recommandée ; permissive ne bloque rien mais journalise quand même tout ; tight est deny par défaut plus les presets secrets et SSRF. Voir le référentiel pour exactement ce que chacun matérialise.

​
2. Refusez le shell destructeur — le plancher non négociable

La règle la plus importante pour un agent de codage est pas de shell destructeur. Les niveaux d’autonomie balanced et tight livrent déjà cela comme le preset Block destructive shell, qui matérialise de vraies règles deny éditables couvrant à la fois les noms d’outils en direct de l’espace de travail (shell.*, bash, cmd.*, powershell.*, exec.*) et les formes namespacées MCP qu’un serveur enregistré expose (*.shell.*, *.cmd.*, …). Si vous préférez le scoper plus serré que « refuser tout shell », rédigez une règle qui ne refuse que les commandes destructrices et audite le reste. Une règle correspond sur un glob de nom d’outil plus un prédicat d’argument optionnel (JSONPath contre les arguments de l’appel) :
Dans Firewall → Policies, ajoutez une règle au-dessus de votre défaut :
  • Glob d’outil : shell.exec
  • Args match (clause JSONPath) :
{
  "clauses": [
    { "path": "$.command", "op": "regex", "value": "(?i)\\brm\\s+-[a-z]*[rf]" }
  ]
}
  • Verdict : deny
Les opérateurs d’argument forment un jeu fermé — eq, contains, regex, in, cidr_match, gt, lt. Un appel dont le $.command correspond au regex est bloqué ; tout le reste retombe sur la règle suivante.
Un appel refusé sur la surface inbound renvoie une HTTP 400 avec le code d’erreur firewall_blocked et un message nommant l’outil et la raison. Un appel dispatché à travers la passerelle MCP revient comme une erreur d’outil (firewall deny: …) afin que le modèle puisse réagir au lieu de planter. Les blocks inbound se déclenchent avant l’appel au modèle amont, donc ils ne coûtent aucun token de modèle.
Voir Règles du firewall pour le langage de correspondance complet (globs d’outils, clauses d’arguments, séquences, plafonds de coût).

​
3. Validez les arguments sur les outils que vous gardez

Autoriser un outil n’est pas la même chose qu’autoriser chaque argument qu’on lui passe. Le même prédicat JSONPath qui scope un deny vous permet de contraindre la forme d’un appel autorisé — de sorte que db.query ne puisse pas porter un DROP, et file.write ne puisse pas s’échapper d’un répertoire.

Bloquer un DROP SQL

Glob db.query, clause {"path":"$.sql","op":"regex","value":"(?i)\\bdrop\\b"}, verdict deny.

Redacter un secret dans les args

Le verdict sanitize redacte les sous-chaînes correspondantes des arguments de l’appel d’outil avant que l’appel ne soit transmis. Il ne touche jamais ce qu’un outil renvoie ; sur la surface inbound (pas encore d’arguments au moment de l’appel) il escalade en un block.
Le Firewall assainit les arguments d’appel d’outil, pas les résultats d’outil. Pour empêcher un secret d’entrer dans une requête en premier lieu, attachez le guardrail Secrets Blocker à la clé — cela filtre le texte du prompt lui-même avant que le modèle ne le voie. Les deux plans se composent : les guardrails filtrent le texte, le Firewall gouverne l’action.

​
4. Contrôlez l’egress — clôturez où l’agent peut atteindre

Un agent de codage qui peut récupérer des URL peut être dirigé vers du SSRF (atteindre le cloud-metadata ou un hôte interne 10.x) ou utilisé pour exfiltrer. Le niveau d’autonomie tight livre un preset SSRF qui refuse les noms d’outils de forme « fetch » (http_fetch, web_search, fetch_url, request, et leurs formes <server>.*) purement et simplement. Pour un contrôle au niveau de la destination, rédigez une règle egress. Les règles d’egress scopent par host ou CIDR avec des entrées allow / deny, évaluées sur la surface egress : 
{ "deny": ["169.254.169.254", "10.0.0.0/8", "*.internal"] }
Cela se déclenche sur toute destination sortante rapportée par un outil qui atterrit sur une plage privée, l’IP de cloud-metadata, ou un nom d’hôte interne — laissant passer les destinations publiques tout en clôturant les dangereuses.
Aucun preset ne livre de règles d’egress basées sur CIDR — le preset SSRF correspond aux noms d’outils de forme « fetch ». La denylist host/CIDR ci-dessus en est une que vous rédigez vous-même. Voir Arrêter l’exfiltration pour le motif complet.

​
5. Mettez les opérations risquées en attente d’un humain (HITL)

Certaines opérations ne devraient être ni auto-autorisées ni auto-refusées — un déploiement, un git push, une migration destructrice. Pour celles-là, utilisez le verdict pending_approval. L’appel est mis en attente, l’agent reçoit une réponse « held » avec un id d’approbation, et un relecteur le résout hors-bande :
  1. Rédigez une règle (par ex. glob deploy.*, verdict pending_approval).
  2. L’appel mis en attente renvoie une HTTP 400 firewall_approval_pending avec un id d’approbation.
  3. Un relecteur l’approuve depuis la console (Developer+) ou via un callback webhook signé HMAC.
  4. L’agent interroge l’approbation, puis re-soumet l’appel d’origine avec un en-tête X-OrcaRouter-Firewall-Approval à usage unique — et la passerelle le laisse passer cette fois-là.
Déployez toute nouvelle politique en mode shadow d’abord. La politique évalue et journalise exactement comme elle le ferait en production, mais chaque verdict appliquant est rétrogradé en audit avec une raison [shadow] would … — de sorte que vous puissiez prouver qu’elle se déclenche sur ce que vous attendez avant qu’elle ne puisse casser un build.

​
6. Gouvernez les skills et serveurs MCP qu’il charge

Les agents de codage tirent des capacités à l’exécution — skills communautaires, serveurs MCP BYO. Le Firewall gouverne les deux à la passerelle :
  • Les Skills sont scannés dans une bande de risque avec un mode d’application (allow / quarantine / block). Un skill auto-détecté est mis en quarantaine — en attente d’approbation — jusqu’à ce qu’un relecteur le valide. Voir Skills.
  • Les serveurs MCP que vous enregistrez dispatchent chaque tools/call à travers la passerelle, qui évalue chacun sur la surface mcp avant le dispatch. Les identifiants sont stockés chiffrés ; une sonde de santé rapporte ok / degraded / down. Voir Serveurs MCP et Durcir un agent MCP.

​
7. Vérifiez et observez

Avant de dépendre d’une politique, exécutez-la en dry-run. L’onglet Test évalue un appel d’outil d’échantillon contre la politique actuelle et montre le verdict, la règle correspondante et la raison — rien n’est dispatché, rien n’est persisté. Une fois en direct, Firewall → Events / Runs est l’enregistrement de chaque évaluation, filtrable par verdict, surface, outil et exécution, et le flux d’anomalies signale les pics de débit/coût contre la baseline apprise de l’espace de travail, retry_loop, et les chemins d’outils jamais vus auparavant.

​
Récapitulatif

Référence Firewall

Le plan de politique complet — surfaces, verdicts, résolution, autonomie.

Règles du firewall

Le langage de correspondance : globs, clauses d’arguments, egress, séquences.

Appels d'outils dangereux

La menace contre laquelle cette recette se défend.

Agence excessive

Pourquoi les agents sur-permissionnés sont le risque agent central.

Recette agent autonome

Verrouillez de bout en bout une boucle d’agent pleinement autonome.

Arrêter l'exfiltration

Les motifs d’egress et de trifecta létale en profondeur.