Passer au contenu principal
Un agent qui peut atteindre le réseau peut être transformé en conduit de données. Un attaquant plante des instructions dans un document que l’agent lit — une page web, un chunk récupéré, un résultat d’outil — et ces instructions orientent l’agent pour POSTer des données sensibles vers un hôte contrôlé par l’attaquant, ou pour sonder des services internes (SSRF). L’agent ne « décide » jamais d’exfiltrer ; il exécute ce qui ressemble, pour lui, à une instruction légitime. Cette page couvre comment l’Agent Firewall et les Guardrails d’OrcaRouter vous permettent de vous défendre contre l’exfiltration de données IA — sans modifier votre code d’agent.
Le firewall voit l’egress uniquement pour les destinations routées via la passerelle via le chemin de dispatch MCP ou le hook d’évaluation. Un outil que votre agent exécute entièrement à l’intérieur de son propre processus est en dehors de sa vue. Routez les appels d’outils réseau de votre agent via la passerelle et ils sont gouvernés.

​
1. Comment fonctionne l’attaque

Le chemin canonique à travers un agent s’exécute en trois étapes :
  1. Injection — l’agent lit du contenu non fiable portant des instructions intégrées (une page web, un document récupéré, une note CRM).
  2. Collecte — les instructions injectées disent à l’agent de rassembler du matériel sensible — clés API, lignes de base de données, PII utilisateur — en utilisant des outils qu’il détient déjà.
  3. Exfiltration — l’agent est dit d’envoyer ce matériel via un outil de forme fetch : http_fetch, web_search, fetch_url ou request. La destination est contrôlée par l’attaquant.
Le SSRF est la même forme redirigée vers l’intérieur : au lieu d’un hôte externe, l’agent est orienté vers 169.254.169.254 (métadonnées cloud), un port Redis interne, ou un autre service privé. Voir Injection de prompt pour l’étape d’injection ; cette page se concentre sur l’étape réseau.

​
2. Liste blanche d’egress — verrouillez les destinations sortantes

La défense la plus durable est une liste blanche d’egress : énumérez les hôtes que vos agents sont légitimement autorisés à atteindre et refusez tout le reste. Une règle d’egress utilise stage: egress et le champ egress. Le verdict contrôle la polarité — allow laisse passer les destinations listées ; un deny catch-all à priorité plus basse bloque le reste : 
[
  {
    "priority": 10,
    "label": "Allow known API endpoints",
    "stage": "egress",
    "tool_name_glob": "*",
    "verdict": "allow",
    "egress": {
      "allow": [
        "api.openai.com",
        "api.anthropic.com",
        "api.orcarouter.ai"
      ]
    }
  },
  {
    "priority": 20,
    "label": "Deny all other outbound destinations",
    "stage": "egress",
    "tool_name_glob": "*",
    "verdict": "deny"
  }
]
Les entrées correspondent comme un CIDR, un IP littéral ou un hostname insensible à la casse. Les hostnames sont résolus au mieux et re-vérifiés contre les entrées IP/CIDR, donc une destination comme 169.254.169.254 retournée par DNS est quand même interceptée par une entrée de refus CIDR 10.0.0.0/8. Un appel bloqué retourne HTTP 400 avec le code d’erreur firewall_blocked. Pour refuser des plages connues mauvaises sans liste blanche explicite, rédigez une règle de refus d’egress ciblée listant l’endpoint de métadonnées cloud (169.254.169.254) et les plages privées RFC-1918 (10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16). Superposez votre liste blanche par-dessus à un numéro de priorité plus bas afin que les règles de refus soient évaluées en premier.

​
3. Bloquez les outils de forme fetch à la couche du nom

Avant même qu’une destination d’egress ne soit évaluée, vous pouvez supprimer la capacité entièrement. Le niveau d’autonomie tight refuse http_fetch, web_search, fetch_url et request par glob de nom d’outil comme filet de sécurité SSRF et d’exfiltration. Si votre agent n’a besoin d’aucun de ces outils, tight supprime la surface d’attaque en une étape : 
POST /api/workspace/firewall/autonomy
{ "level": "tight" }
Pour refuser les outils fetch sans adopter la posture complète tight, rédigez une règle de refus de surface inbound. inbound bloque l’outil avant que le modèle puisse le choisir — l’agent ne reçoit jamais la capacité dans sa liste d’outils : 
{
  "priority": 5,
  "label": "Deny fetch-shaped tools",
  "stage": "inbound",
  "tool_name_glob": "http_fetch",
  "verdict": "deny"
}
Répétez pour chaque nom d’outil de forme fetch que votre stack d’agent utilise.

​
4. Guardrail Secrets Blocker — stoppez les identifiants au niveau du prompt

Le guardrail Secrets Blocker s’exécute à l’étape input, scannant le prompt pour des clés d’accès de style AWS, des clés OpenAI, des clés Anthropic, des tokens GitHub et des patterns d’identifiants similaires avant que la requête ne quitte la passerelle. Si un secret est détecté, la requête est bloquée — l’identifiant n’atteint jamais un modèle et n’apparaît jamais dans un appel d’outil. Activez-le depuis le panneau Guardrails, ou dans le cadre du niveau d’autonomie tight. Il est indépendant des règles d’egress du firewall.
MenaceCouche qui l’arrête
Le prompt porte une clé APISecrets Blocker (guardrail d’entrée)
L’agent appelle un outil fetch vers un hôte d’attaquantRègle d’allow/deny d’egress
Outil de forme fetch annoncé au modèleRègle de refus inbound ou autonomie tight
L’agent atteint les métadonnées cloud ou RFC-1918Règle de refus d’egress listant ces CIDRs

​
5. Déployez avec le mode shadow

Si vous n’êtes pas sûr de quels hôtes votre agent atteint légitimement aujourd’hui, commencez en mode shadow avant d’appliquer :
  1. Créez les règles d’egress avec votre liste allow prévue et définissez shadow_mode: true sur la politique.
  2. Regardez le flux Events — les appels qui seraient bloqués apparaissent comme [shadow] would deny avec la destination.
  3. Ajustez la liste allow jusqu’à ce que seules les destinations atteignables par l’attaquant seraient refusées, puis désactivez le mode shadow pour commencer l’application.
Aucun trafic n’est bloqué pendant que le mode shadow est activé.

​
6. Où aller ensuite

Référence des règles Firewall

Langage de correspondance complet — listes d’egress, CIDRs, clauses d’arguments et tous les verdicts.

Vue d'ensemble de l'Agent Firewall

Politiques, surfaces, niveaux d’autonomie et observabilité.

Injection de prompt

L’étape d’injection qui oriente les agents vers l’exfiltration.

Empoisonnement d'outils MCP

Outils MCP malveillants qui enregistrent des capacités de forme fetch.