Passer au contenu principal
Un agent qui peut atteindre le réseau peut être transformé en tuyau de données. Des instructions injectées lui disent de rassembler des secrets, des lignes ou de la PII avec les outils qu’il possède déjà et de les POSTer vers un hôte attaquant — ou de 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 recette câble trois contrôles qui ferment la boucle de bout en bout — une allow-list d’egress qui verrouille où les appels sortants peuvent aller, le guardrail Secrets Blocker qui arrête les identifiants avant qu’ils n’atteignent jamais un modèle, et un assainisseur d’arguments qui retire les secrets des appels d’outils qu’un modèle émet bel et bien. Tout cela vit dans la passerelle, donc vous le configurez une fois dans la console sans aucun changement dans le code de votre agent. Pour l’anatomie complète de l’attaque, lisez Exfiltration de données sur le réseau ; cette page est les étapes de construction.
Tout ici se lie à votre espace de travail et est configuré depuis la console. Votre agent continue d’appeler https://api.orcarouter.ai/v1/... avec la même clé sk-orca-... — seule la politique dans la passerelle change. Les actions de configuration nécessitent les rôles indiqués à chaque étape ; les appels de relais utilisent la clé scopée. Le firewall ne voit l’egress que pour les destinations routées à travers la passerelle (le chemin de dispatch MCP ou le hook d’évaluation) — routez vos appels d’outils liés au réseau à travers elle et ils sont gouvernés.

​
1. Les trois couches qui préviennent l’exfiltration de données IA

Chaque couche attrape l’attaque à un point différent du cycle de vie de la requête. Empilez les trois — elles sont indépendantes et complémentaires.

Identifiants dans le prompt

Un secret collé dans (ou tiré dans) la requête est attrapé au stage input par le guardrail Secrets Blocker — avant qu’aucun modèle ne le voie.

Secrets dans les args d'outil

Un modèle qui émet un appel d’outil portant un identifiant est nettoyé par une règle de firewall sanitize, qui redacte l’argument correspondant.

Destination sortante

L’étape réseau effective est bornée par une allow-list d’egress — seuls les hôtes énumérés passent ; tout le reste est refusé.
Cette recette utilise les deux plans : les Guardrails pour le texte de la requête, le Firewall pour les actions et le réseau. Voir guardrails vs firewall pour savoir où la ligne se situe.

​
2. Arrêtez les identifiants au prompt — le guardrail Secrets Blocker

La première chose à verrouiller est l’identifiant lui-même. Le guardrail Secrets & API-Key Blocker s’exécute au stage input et scanne la requête à la recherche de motifs d’identifiants — clés d’accès de style AWS, clés OpenAI, JWTs, et tokens similaires — avant que la requête ne quitte la passerelle. Sur une correspondance, la requête est bloquée : l’identifiant n’atteint jamais un modèle et n’atterrit jamais dans un appel d’outil. Dans la console, ouvrez Guardrails → Nouveau guardrail (le rôle Developer ; les lectures et la sandbox Test sont ouvertes à tout membre), nommez-le exfil-shield, et appliquez le preset Secrets & API-Key Blocker depuis la bibliothèque de templates (catégorie secrets). Le preset sème trois règles de block regex au stage input, une par forme d’identifiant — clés d’accès AWS, clés de style OpenAI, et tokens GitHub : 
[
  { "type": "regex", "stage": "input", "action": "block", "pattern": "AKIA[0-9A-Z]{16}" },
  { "type": "regex", "stage": "input", "action": "block", "pattern": "sk-[A-Za-z0-9]{20,}" },
  { "type": "regex", "stage": "input", "action": "block", "pattern": "ghp_[A-Za-z0-9]{36}" }
]
Pour étendre la couverture, ajoutez une règle pii sur les entités intégrées — le jeu de détecteurs couvre email, phone, credit_card, ssn, ip, iban, mac_address, api_key_openai, aws_access_key, jwt, et bitcoin_address. Choisissez mask (redacter en une étiquette typée comme [EMAIL]) ou block par entité via entity_actions. Le masquage au stade input est actif ; il réécrit la requête avant que le modèle ne la voie.
Une requête bloquée renvoie une HTTP 400 guardrail_blocked, ne coûte aucun quota (un block au stade input se déclenche avant le metering), et est marquée skip-retry. Prouvez-le dans l’onglet Test — collez une clé AWS d’échantillon, choisissez le stage input, et confirmez le verdict — avant d’attacher une clé.

​
3. Assainissez les secrets hors des arguments d’appel d’outil

Un guardrail filtre le prompt ; il ne voit pas les appels d’outils qu’un modèle émet. Quand le modèle produit un tool_call dont les arguments portent un identifiant, une règle de firewall sanitize l’attrape. Sanitize redacte les sous-chaînes correspondantes des arguments d’appel d’outil et transmet l’appel nettoyé — l’outil s’exécute, mais avec le secret retiré. Dans Firewall → Policies → Nouvelle politique (rôle Developer), nommez-la exfil-firewall et ajoutez une règle sanitize sur la surface response — les tool_calls que le modèle émet dans sa réponse : 
{
  "priority": 10,
  "label": "Redact secrets from tool args",
  "stage": "response",
  "tool_name_glob": "*",
  "verdict": "sanitize",
  "sanitize": {
    "presets": ["aws_access_key", "openai_key"],
    "custom": ["sk-[A-Za-z0-9]{20,}"]
  }
}
Sanitize redacte les arguments uniquement d’appel d’outil — jamais le contenu qu’un outil renvoie. C’est une défense sur la forme d’appel sortant, pas sur les résultats d’outils entrants. Sur la surface inbound (où il n’y a pas encore d’arguments au moment de l’appel) un verdict sanitize escalade en un deny. Voir le langage de correspondance complet dans Règles du firewall.

​
4. Verrouillez les destinations sortantes — l’allow-list d’egress

La défense la plus durable est la frontière réseau elle-même : é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 définit la polarité — allow laisse passer les destinations listées et un deny catch-all de priorité inférieure bloque le reste. Ajoutez ces règles à la même politique exfil-firewall : 
[
  {
    "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 nom d’hôte insensible à la casse. Pour arrêter le SSRF vers des services internes sans allow-list explicite, rédigez votre propre règle de deny d’egress listant l’endpoint de cloud metadata (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). Un appel refusé renvoie une HTTP 400 firewall_blocked.
Aucun preset ne livre de règles d’egress CIDR — vous rédigez vous-même les entrées allow et deny host/CIDR. Le niveau d’autonomie tight est le chemin rapide adjacent : il refuse purement et simplement les noms d’outils de forme « fetch » (http_fetch, web_search, fetch_url, request), supprimant la capacité réseau avant qu’une destination ne soit jamais évaluée. Utilisez-le quand votre agent n’a pas du tout besoin de ces outils.

​
5. Attachez une seule clé scopée

Une politique ne s’applique que sur les clés qui s’y résolvent. Donnez à l’agent sa propre clé, scopée au minimum dont il a besoin — jamais votre clé à portée de compte. Dans API Keys → Nouvelle clé (rôle Developer) :
Choisissez exfil-shield dans le menu déroulant Guardrail (définit guardrail_id) et exfil-firewall dans le menu déroulant Firewall policy (définit firewall_policy_id). Les deux liaisons vivent sur la clé dans la passerelle. Un attachement explicite de guardrail ne retombe jamais silencieusement — le désactiver est l’interrupteur d’arrêt. Une politique firewall désactivée, en revanche, retombe sur la politique par défaut de l’espace de travail.
Définissez credit_limit_usd à un plafond raisonnable (0 = illimité) afin qu’une clé compromise ne puisse pas drainer le quota, et allow_ips sur les IPs d’egress de votre backend si l’agent appelle depuis un serveur fixe. Définissez un expired_time pour les clés temporaires (-1 = n’expire jamais).
La clé est masquée à l’affichage après création — copiez-la une seule fois. Votre agent exécute désormais chaque requête à travers exfil-shield et chaque appel d’outil à travers exfil-firewall sans qu’aucun code ne soit conscient que l’application a lieu.

​
6. Déployez avec le mode shadow, puis surveillez

Si vous ne connaissez pas encore chaque hôte que votre agent atteint légitimement, n’appliquez pas à l’aveugle — observez d’abord. Voir modes d’application pour le chemin complet observe → shadow → enforce.
1

Shadow les règles d'egress

Définissez shadow_mode: true sur exfil-firewall. Chaque verdict appliquant est rétrogradé en audit et journalisé comme [shadow] would deny avec la destination. Aucun trafic n’est bloqué tant que le mode shadow est activé.
2

Surveillez les flux

Firewall → Events / Runs (Developer+) montre chaque appel d’outil et destination d’egress que votre agent a touchés et ce qui aurait été refusé. Guardrails → Matches (tout Member) montre chaque secret que le guardrail d’input a attrapé. Ajustez la liste allow d’egress jusqu’à ce que seuls les hôtes joignables par un attaquant soient refusés.
3

Appliquez

Désactivez shadow_mode. La toute prochaine requête est gouvernée — identifiants bloqués au prompt, secrets retirés des args d’outil, appels sortants confinés à votre allow-list. Aucun changement d’application.
Le flux Matches enregistre la sous-chaîne correspondante uniquement quand Log raw content est activé pour le guardrail (désactivé par défaut — la posture prudente en matière de vie privée). Marquez un faux positif (Admin) pour ajuster la politique. Chaque changement de guardrail écrit une ligne d’historique de versions que vous pouvez comparer et restaurer ; les changements de politique firewall sont enregistrés dans la piste d’audit.

​
7. Couverture en un coup d’œil

Étape d’exfiltrationCouche qui l’arrête
L’identifiant entre dans la requêteGuardrail Secrets Blocker (input)
Le modèle émet un appel d’outil portant un secretRègle de firewall sanitize (surface response)
L’outil compose vers un hôte attaquantRègle d’egress allow / deny
L’agent atteint le cloud metadata ou RFC-1918Règle de deny d’egress listant ces CIDRs
Un outil de forme « fetch » offert au modèleNiveau d’autonomie tight (deny de nom d’outil)

​
8. Où aller ensuite

Référence règles du firewall

Le langage de correspondance complet — listes d’egress, CIDRs, assainisseurs, et tous les verdicts.

Menace d'exfiltration de données

L’anatomie d’attaque contre laquelle cette recette se défend, de bout en bout.

Durcir un agent MCP

Gouvernez chaque tools/call qu’un agent dispatche à travers un serveur MCP.

Journalisation sans PII

Gardez les données sensibles hors de vos journaux de requêtes et du flux Matches.