Passer au contenu principal
Quand un agent appelle http_fetch, web_search, ou tout outil qui ouvre une connexion sortante, la destination est la partie que vous avez le plus besoin de gouverner. Un agent confus ou détourné qui peut atteindre 169.254.169.254 lit vos identifiants cloud ; un qui peut POSTer vers un hôte attaquant exfiltre vos données. Le contrôle d’egress des agents gouverne cette destination — vous rédigez une règle d’autorisation/refus host/CIDR sur la surface egress du firewall, l’attachez à une clé, et la passerelle vérifie chaque destination sortante que l’outil d’un agent rapporte avant que l’appel ne sorte. C’est une page de cas d’usage ciblée. Pour la grammaire complète des règles et la sémantique des verdicts, voir Schéma de règle et Verdicts ; pour la façon dont l’egress se place parmi les autres points d’application, voir Stages.

​
1. Le contrôle d’egress des agents sur la surface egress

Des quatre surfaces du firewall, egress est celle qui voit la destination réseau sortante qu’un outil rapporte — un host, un littéral d’IP, ou un CIDR. Une règle épinglée à stage: egress correspond sur cette destination, pas sur le nom d’outil ni ses arguments, ce qui en fait le contrôle de SSRF et d’exfiltration de données : elle répond à où cet agent peut atteindre, indépendamment de quel outil a effectué l’atteinte.
L’egress est du scoping de destination, pas du blocage d’outil. Pour empêcher un outil d’exister du tout, refusez-le par son nom sur la surface inbound (Bloquer des outils). Le contrôle d’egress suppose que l’outil peut légitimement récupérer — il contraint juste vers où.

​
2. Un exemple : refuser les destinations SSRF

La règle d’egress canonique refuse l’endpoint cloud metadata et les plages privées RFC-1918 — les destinations qu’un outil de forme fetch ne devrait jamais atteindre. Dans la console de votre espace de travail, ouvrez une politique et ajoutez une règle avec stage egress, le verdict deny, et une liste d’egress : 
{
  "label": "deny SSRF destinations",
  "stage": "egress",
  "verdict": "deny",
  "egress_json": "{\"deny\":[\"169.254.169.254\",\"10.0.0.0/8\",\"172.16.0.0/12\",\"192.168.0.0/16\"],\"allow\":[\"api.openai.com\"]}"
}
egress_json est une chaîne encodée en JSON portant les listes host/CIDR — décodée, c’est {"deny": [...], "allow": [...]}. Chaque entrée correspond comme un CIDR, un littéral d’IP, ou un nom d’hôte insensible à la casse. Pour un verdict deny, la liste deny est l’ensemble en portée (les destinations que la règle bloque) et la liste allow y taille des exceptions — de sorte que la règle ci-dessus bloque les quatre plages mais laisse passer api.openai.com même s’il se résolvait un jour dans l’une d’elles. Quand une destination est un nom d’hôte plutôt qu’un littéral d’IP et que votre liste porte des entrées IP/CIDR, le nom est résolu en best-effort et ses adresses re-vérifiées, de sorte que metadata.internal correspond quand même à un deny 169.254.0.0/16 même s’il n’est pas listé par son nom.
Pour une posture de liste blanche à la place — ne permettre qu’un ensemble nommé de destinations et bloquer le reste — rédigez la règle avec le verdict allow et mettez vos destinations dans la liste allow. La polarité s’inverse : allow devient l’ensemble en portée et deny y taille des exceptions. Associez-la à un default_verdict de politique deny de sorte que tout ce que la règle allow ne couvre pas est bloqué.

​
3. Vous rédigez les règles CIDR — aucun preset ne les embarque

Il n’y a pas de liste CIDR de preset. OrcaRouter n’embarque pas une règle intégrée qui refuse 169.254.169.254, RFC-1918, ou toute autre plage. La règle d’autorisation/refus CIDR est à vous de la rédiger — c’est l’exemple du §2, écrit par vous contre votre propre réseau. Copiez-le, puis ajustez les plages et les exceptions de liste blanche à votre environnement.
Ce que le niveau d’autonomie tight et son preset block_ssrf_egress embarquent est un ensemble de refus sur les noms d’outils de forme fetch — http_fetch, web_search, fetch_url, request, plus leurs variantes MCP <server>.<tool>. C’est une posture brutale : elle refuse les outils de forme egress purement et simplement plutôt que de scoper où ils peuvent atteindre. Recourez-y quand un agent n’a rien à faire à faire des appels réseau ; recourez à une règle de destination (§2) quand il récupère mais seulement depuis un ensemble approuvé d’hôtes.
ApprocheCe qu’elle contraintAuteur
Preset SSRF tightLes noms d’outils de forme fetch (les refuse)Intégré
Règle CIDR/host d’egressLa destination qu’un fetch peut atteindreVous

​
4. À quoi ressemble un egress bloqué

Quand une destination correspond à une règle d’egress appliquante, l’appel est refusé avant de quitter la passerelle et l’évaluation est enregistrée comme un événement firewall avec la surface egress et le verdict deny. En mode shadow, le deny est rétrogradé en audit avec la raison préfixée [shadow] would …, de sorte que vous pouvez mesurer exactement quelles destinations une règle bloquerait contre le trafic réel avant de l’appliquer.
Une liste d’egress malformée ou sans entrées est traitée de façon conservatrice : une règle deny appliquante filtre quand même (une faute de frappe ne peut pas l’empêcher silencieusement de bloquer), mais une règle allow avec une liste cassée ne se déclenchera pas — sinon une liste blanche mal saisie deviendrait allow-all et masquerait un deny par défaut. Les nouvelles règles sont validées à l’enregistrement (la liste doit déclarer au moins une entrée allow ou deny), donc cela ne protège jamais que les anciennes lignes.

​
5. Rédiger à partir du trafic réel, puis déployer

Le journal d’événements enregistre le host de destination sur chaque événement de surface egress (egress_host/egress_url), donc filtrez-le sur la surface egress et rédigez votre liste de refus à partir des destinations qui sont réellement apparues plutôt que de deviner. L’onglet Discovered Tools est un récapitulatif par nom d’outil (les noms d’outils et les surfaces sur lesquelles ils se sont déclenchés) — il vous dit quels outils de forme fetch se sont exécutés, pas les hôtes qu’ils ont atteints. Voir Analytics.
L’onglet Test de la console exécute une politique en dry-run contre un tool_name + surface (+ args optionnels) d’échantillon et renvoie le verdict, la règle correspondante et la raison — rien n’est dispatché. Il confirme à quelle règle un appel se résout ; pour confirmer votre calcul CIDR/host contre des destinations réelles, utilisez le mode shadow ci-dessous (le payload Test ne porte pas de destination, donc la correspondance de liste d’egress est exercée sur le trafic egress réel). Voir Tester les règles.
Activez le mode shadow et le deny d’egress est journalisé comme il se déclencherait sans bloquer. Surveillez le journal d’événements filtré sur la surface egress, confirmez qu’il attrape les destinations que vous attendez, puis désactivez le shadow.
Le scoping de destination à la passerelle est de la défense en profondeur, pas la dernière ligne. L’IP à laquelle un nom d’hôte se résout au moment de l’évaluation peut différer de celle qu’un outil compose réellement (DNS rebinding). Gardez aussi un contrôle de refus d’IP à votre propre couche egress/dialer ; la règle de la passerelle est l’attrape pré-vol bon marché pour les cas évidents.

​
6. Attacher la politique et qui peut l’éditer

Une politique ne fait rien jusqu’à ce qu’une clé s’y résolve. Attachez dans la console en définissant firewall_policy_id sur la clé, ou faites de la politique le défaut de l’espace de travail. La résolution est : la politique attachée de la clé (lorsqu’elle existe et est activée), sinon le défaut de l’espace de travail. Toute la configuration des règles d’egress s’exécute dans la console sous votre session (/api/workspace/firewall/*) :
ActionRôle
Lire les politiques, presets, outils découverts, Simulate d’autonomieMember
Créer / éditer / supprimer des règles d’egress et des politiquesDeveloper+
Endpoint Test de dry-run (POST /test)Developer+
Lire le journal d’événements et les agrégations d’exécutionsDeveloper+

​
Connexe

Exfiltration de données

La menace que le contrôle d’egress traite.

Stages

Les quatre surfaces, et où l’egress se place.

Verdicts

Ce que font deny, audit et allow sur le fil.

Bloquer des outils

Refuser un outil de fetch par son nom plutôt que par destination.

Appels d'outils dangereux

La classe de risque plus large.

Référence du Firewall

La référence complète des règles + correspondance, y compris les listes d’egress.