Passer au contenu principal
Vous avez connecté un serveur MCP, et maintenant vous voulez que la passerelle extraie un secret fuité d’un appel d’outil avant qu’il n’atteigne le vrai serveur — et empêche tout ce que cet outil renvoie de faire passer en douce un credential (ou une charge d’injection) de retour vers le modèle. Ce sont deux tâches différentes, gérées par deux contrôles différents, et la version honnête importe : si vous supposez qu’un seul bouton couvre les deux, vous livrerez une lacune. Cette page est le guide ciblé pour assainir la sortie mcp sur OrcaRouter — ce que le verdict firewall sanitize redacte réellement, ce qu’il ne fait pas, et quel contrôle gouverne le contenu qu’un outil renvoie.
Le verdict sanitize redacte les arguments d’un appel d’outil, jamais le résultat qu’un outil renvoie. Il réécrit ce que votre agent envoie dans un outil. Pour gouverner ce qu’un outil renvoie, vous utilisez un guardrail de stage output sur la réponse du modèle — voir §3.

​
1. Ce que « sanitize » signifie sur la surface mcp

Quand un agent appelle un outil à travers la passerelle MCP, chaque tools/call est évalué sur la surface mcp avant le dispatch. Une règle correspondante peut porter l’un des verdicts firewall rédigeables — allow, audit, deny, sanitize, pending_approval, ou cap_cost. Le verdict sanitize est celui qui redacte :
  • Il exécute un ensemble de détecteurs de forme de secret sur les arguments de l’appel (le JSON que le modèle a passé dans l’outil).
  • Chaque correspondance est remplacée par un token canonique comme [redacted:openai_key], et ce sont les arguments réécrits qui sont transmis au serveur.
  • L’outil s’exécute quand même — sanitize est un verdict non bloquant, qui laisse passer. L’agent ne plante pas ; il ne remet simplement jamais le secret brut à l’outil.
Les détecteurs intégrés couvrent les formes de secret bien connues (clés d’accès AWS, clés d’API de style sk-, tokens Bearer, SSN US, numéros de carte valides selon Luhn, email), et une règle peut ajouter des regex personnalisées dont les correspondances s’affichent comme [redacted:custom].
Sur la surface inbound — les tools[] annoncés qu’une requête déclare, avant tout appel d’outil — il n’y a aucun argument au moment de l’appel à redacter, donc un verdict sanitize là échoue fermé et escalade en deny. Sanitize n’a de sens que là où il y a une charge d’argument en direct à réécrire : les surfaces mcp et response.

​
2. Une règle concrète

Disons que vous voulez que tout appel d’outil dont les arguments contiennent une clé de style OpenAI soit transmis avec la clé nettoyée, plutôt que bloqué. Rédigez une règle sur la surface mcp avec un verdict sanitize, configurée pour détecter cette forme de secret. Faites-le depuis la console (Firewall → politique → règles) ; l’écriture requiert Developer+. La règle, conceptuellement :
ChampValeur
Surfacemcp
tool_name_glob* (ou cadrer à un serveur, p. ex. github.*)
Verdictsanitize
Presets de sanitizeles détecteurs de secret à activer
Au moment de l’appel, une charge d’argument comme : 
{ "note": "use key sk-AAAABBBBCCCCDDDDEEEEFFFFGGGGHHHH for the upstream" }
est transmise au serveur comme : 
{ "note": "use key [redacted:openai_key] for the upstream" }
L’appel réussit ; le secret n’atteint jamais le serveur. L’événement firewall enregistre le verdict sanitize, la surface, et la règle correspondante.
Recourez à sanitize quand un outil a légitimement besoin de la plupart d’un argument mais qu’un secret se glisse occasionnellement dans du texte libre. Quand tout l’appel est dangereux, utilisez deny (ou pending_approval) à la place — voir Lister les outils MCP autorisés.

​
3. Les résultats d’outils sont non fiables — gouvernez-les sur la réponse du modèle

Voici la partie que la plupart des montages « assainir la sortie » se trompent. Le verdict sanitize touche aux arguments uniquement. Le résultat d’un outil — le texte ou JSON qu’un serveur MCP renvoie — n’est jamais réécrit par un verdict firewall. OrcaRouter traite le contenu du résultat d’outil comme une entrée non fiable pour le modèle. Un serveur MCP compromis ou empoisonné peut renvoyer un secret, un enregistrement PII, ou une charge d’injection de prompt déguisée en données. Le contrôle pour ce contenu est un guardrail sur le stage output — la réponse du modèle, évaluée après que le modèle a incorporé le résultat de l’outil.
Attachez un guardrail avec le preset Secrets & API-Key Blocker (catégorie secrets). Il bloque les credentials de style AWS / OpenAI / GitHub ; associez-le à Private Keys & Cloud Tokens pour les clés PEM, les tokens Slack/Stripe, les clés Google, et les JWT. Un blocage au stage output renvoie guardrail_blocked (HTTP 400) et rembourse le quota de la requête.
Le preset PII Shield masque les entités typées — [EMAIL], [SSN], [CREDIT_CARD], … — rendant les valeurs correspondantes comme des tags. Le masquage au stage input est en service sur chaque requête (en flux ou non) : il masque la requête avant que le modèle ne la voie. Le masquage au stage output réécrit la réponse du modèle sur les réponses non-streaming uniquement ; la réécriture en bande d’une réponse en flux est sur la feuille de route, donc une règle de masque ne redacte pas encore une réponse streamée.
Un résultat empoisonné peut porter du texte de style « ignore previous instructions ». Le preset de sécurité Prompt-Injection Basics (mot-clé/regex) plus une règle llm_judge qui score l’intention d’injection sont les contrôles ici. Voir Empoisonnement d’outils MCP et Injection de prompt.
Application au stage output et streaming. Le blocage au stage output est appliqué sur les réponses en flux et non-streaming — sur un flux, un blocage coupe le flux quand il correspond et émet un avis de blocage générique. Le masque au stage output s’applique aux réponses non-streaming uniquement ; la réécriture en bande d’une réponse en flux est sur la feuille de route, donc une règle de masque ne redacte pas encore une réponse streamée.

​
4. Où vit chaque contrôle

Une carte compacte des deux surfaces, pour que vous câbliez le bon bouton au bon risque :
Vous voulez gouverner…ContrôleOù
Secrets dans les arguments d’un appel d’outilVerdict firewall sanitize (surface mcp)Règles du firewall
Secrets / PII / injection dans le résultat d’un outilGuardrail sur le stage outputGuardrails
N’essayez pas de faire couvrir les résultats d’outils par sanitize — il ne peut pas les voir. Et ne supposez pas qu’un guardrail de stage input attrapera ce qu’un outil renvoie en milieu de conversation ; le contenu du résultat d’outil est gouverné sur la réponse du modèle, qui est le stage output.

​
5. Attacher et observer

Les deux contrôles sont à portée d’espace de travail, nommés et ordonnés, et s’attachent des deux mêmes façons :
  • Par clé — réglez firewall_policy_id (pour la règle de sanitize) et guardrail_id (pour la politique de sortie) sur la clé que l’agent utilise.
  • Défaut d’espace de travail — marquez une politique / un guardrail comme défaut d’espace de travail pour que chaque clé en hérite.
Configurez tout cela depuis la console avec votre token de session/d’accès (les routes de gestion utilisent UserAuth, pas la clé relais). Les écritures firewall requièrent Developer+ ; les écritures de guardrail requièrent Developer+. Une fois en service, les correspondances de sanitize apparaissent comme des événements firewall (verdict, surface, règle correspondante), et les correspondances de guardrail apparaissent dans le flux de correspondances de guardrail. Les deux ont des portes de lecture différentes : le flux des événements firewall requiert Developer+, tandis que le flux des correspondances de guardrail est lisible par tout membre d’espace de travail. Par défaut une correspondance enregistre son type, son action et son stage mais pas le contenu brut correspondant ; activez Log raw content seulement quand vous avez besoin de la sous-chaîne pour le triage.

​
6. Où aller ensuite

Lister les outils MCP autorisés

Refus par défaut d’un serveur et n’autoriser que les outils que vous avez revus.

Règles du firewall

Le DSL de règle complet — verdicts, globs, args-match, config sanitize.

Guardrails

Politiques de contenu, presets, entités PII, et application au stage output.

Empoisonnement d'outils MCP

La menace qui rend les résultats d’outils non fiables en premier lieu.
Nouveau sur la séparation entre ces deux couches ? Lisez Guardrails vs. firewall, puis Exfiltration de données pour le chemin de fuite que sanitize et les guardrails de sortie ferment ensemble.