Passer au contenu principal
Quand vous avez besoin de masquer les données sensibles qu’un prompt llm transporte — emails, numéros de carte, identifiants nationaux, secrets — la passerelle réécrit chaque correspondance en place avant que le modèle ne la voie. Une valeur masquée devient une balise typée (jane@acme.com → [EMAIL]), donc le modèle lit toujours un prompt cohérent tandis que la valeur brute ne quitte jamais votre espace de travail. Cette page est le point de vue ciblé sur ce que le masquage rend, comment changer la balise, et comment masquer certaines entités tout en en bloquant d’autres sur une seule règle. Pour le moteur complet — chaque type de règle, étape et route — voir la référence Guardrails, et pour le masquage sur la requête spécifiquement, Règles à l’étape input.

​
1. Masquer les données sensibles que les prompts llm transportent, avec des balises typées

Une règle pii avec l’action mask détecte une entité et remplace chaque correspondance par une balise de redaction typée — un label en majuscules entre crochets qui nomme ce qui a été retiré sans révéler la valeur :
EntitéBalise rendue
email[EMAIL]
credit_card[CREDIT_CARD]
ssn[SSN]
L’ensemble complet de détecteurs intégrés — email, phone, credit_card, ssn, ip, iban, mac_address, jwt, aws_access_key, api_key_openai, bitcoin_address, plus les détecteurs régionaux jp_mynumber, kr_rrn et cn_resident_id — rend chacun sa propre balise entre crochets ([PHONE], [IBAN], [JP_MYNUMBER], et ainsi de suite). La balise est déterministe : la même entité rend toujours le même label, donc les prompts en aval restent stables et vos journaux se lisent proprement.
Les balises typées battent un [REDACTED] générique pour la qualité du modèle. Le modèle sait toujours qu’il regarde un email vs. un numéro de compte vs. un numéro de téléphone, donc il peut continuer à raisonner sur la forme des données — « reply to [EMAIL] » reste une instruction actionnable — sans jamais détenir la valeur réelle.
Le masquage d’entrée est pleinement actif — la passerelle réécrit le prompt avant qu’il n’atteigne le modèle, streaming ou non. Le masquage de sortie est actif sur les réponses non-streaming aussi : une règle mask à l’étape output réécrit la complétion avant son retour. Seul le masquage de sortie streaming est sur la feuille de route ; sur une réponse streamée, préférez block à l’étape output. Voir Couverture du streaming pour la matrice exacte étape/flux.

​
2. Un exemple concret

Rédigez la règle dans la console sous votre propre session — la config des guardrails nécessite Developer+, pas une clé de relais. Ajoutez une seule règle pii à un guardrail nommé pii-shield : 
{
  "type": "pii",
  "stage": "input",
  "action": "mask",
  "entities": ["email", "phone", "ssn"]
}
Attachez-la à une clé (définissez guardrail_id, ou marquez-la comme défaut de l’espace de travail — voir Attacher à une clé), puis appelez la passerelle avec cette clé de relais sk-orca-... : 
curl https://api.orcarouter.ai/v1/chat/completions \
  -H "Authorization: Bearer sk-orca-..." \
  -H "Content-Type: application/json" \
  -d '{
    "model": "openai/gpt-4o-mini",
    "messages": [
      {"role": "user", "content": "Reply to jane@acme.com about her SSN 123-45-6789"}
    ]
  }'
La passerelle réécrit le prompt en “Reply to [EMAIL] about her SSN [SSN]” avant la transmission. Le modèle en amont ne voit jamais l’adresse ni le numéro. Prouvez le rendu exact dans l’onglet Test de l’éditeur d’abord (aucun appel en amont, aucun quota) — voir Test & éval.

​
3. Surcharger la balise avec mask_with

Les entités intégrées rendent une balise fixe. Les entités personnalisées — vos propres détecteurs regex superposés sur l’ensemble intégré — vous laissent définir le texte de remplacement vous-même avec mask_with : 
{
  "type": "pii",
  "stage": "input",
  "action": "mask",
  "custom_entities": [
    {
      "name": "employee_id",
      "pattern": "EMP-[0-9]{6}",
      "mask_with": "[STAFF_ID]"
    }
  ]
}
mask_with est la chaîne de remplacement verbatim pour les correspondances de cette entité. EMP-004217 devient [STAFF_ID]. Laissez-la vide et la correspondance rend la balise par défaut [<UPPERCASE_NAME>] — ici, [EMPLOYEE_ID] — afin qu’un détecteur personnalisé produise toujours une redaction typée et lisible même sans override.
name (ASCII minuscule / chiffres / underscore, doit commencer par une lettre), pattern (une regex Go RE2 — temps linéaire, sans backreferences), checksum optionnel (luhn valide les numéros en forme de carte), et mask_with optionnel. Jusqu’à 25 entités personnalisées par règle — chacune est un scan sur l’intégralité du texte, donc le plafond garde le chemin à chaud linéaire. Voir Entités PII personnalisées.
Un name circule dans les journaux d’audit et le flux Matches sans guillemets, donc gardez-le en lettres ASCII minuscules, chiffres et underscores commençant par une lettre (par exemple employee_id, internal_ticket). Le validateur rejette tout le reste.

​
4. Masquer certaines entités, en bloquer d’autres — entity_actions

Une seule règle pii peut appliquer différentes actions à différentes entités via entity_actions, au lieu d’empiler trois règles qui se chevauchent. La forme classique : masquer les données de contact à faible sensibilité, mais bloquer carrément les champs à haute sensibilité. 
{
  "type": "pii",
  "stage": "input",
  "action": "mask",
  "entities": ["email", "phone", "ip", "credit_card", "ssn"],
  "entity_actions": {
    "credit_card": "block",
    "ssn": "block"
  }
}
Ici, email, phone et ip suivent le mask de premier niveau de la règle et rendent [EMAIL] / [PHONE] / [IP] ; une correspondance credit_card ou ssn bloque plutôt toute la requête avec une HTTP 400 guardrail_blocked.
ChampRègle
ClésDoit être une entité déclarée sur la règle (intégrée ou personnalisée).
Valeursblock, mask, flag ou annotate.
Une requête bloquée ne coûte aucun quota — un block à l’étape input se déclenche avant la mesure. Une requête masquée passe avec le texte assaini. Donc une règle peut discrètement redacter les champs de routine et arrêter net les champs réglementés, avec un seul attachement et aucun changement applicatif.

​
5. Mask vs. block vs. flag

Le masquage est l’une des actions qu’une règle (ou un override par entité) peut prendre. Choisissez selon à quel point vous voulez perturber le trafic :

mask

Redacter la correspondance en une balise typée et laisser passer la requête avec le texte assaini. Le modèle ne voit jamais la valeur brute.

block

Rejeter toute la requête avec une HTTP 400 guardrail_blocked. Rien n’atteint le modèle. Utilisez-le pour les données qui ne doivent jamais transiter.

flag

Ne rien changer au trafic — enregistrer seulement une correspondance. Mesurez à quelle fréquence une règle se déclencherait avant de l’appliquer.
Un bon déploiement est flag → mask → block : flag pour dimensionner l’impact, mask une fois que vous faites confiance au détecteur, et réservez block aux champs que vous ne pouvez pas du tout laisser passer. Voir Actions et Ajuster les faux positifs.

​
6. Vérifier ce qui a été masqué

Chaque règle qui se déclenche enregistre une correspondance dans le flux des correspondances de l’espace de travail — type de règle, action, étape et une chaîne de détail. La sous-chaîne correspondante elle-même (l’email brut, le numéro de carte réel) n’est enregistrée que lorsque Log raw content est activé, ce qui est désactivé par défaut — la posture conservatrice en matière de confidentialité, puisque tout l’intérêt est de garder les valeurs brutes hors de vos journaux.
Activez Log raw content uniquement quand vous avez véritablement besoin de la sous-chaîne pour le triage, et uniquement par guardrail. Avec lui désactivé, le flux prouve qu’une [CREDIT_CARD] a été masquée sans jamais stocker le numéro. Le toggle n’est pas rétroactif. Voir Journalisation & confidentialité.

​
7. Où aller ensuite

Lisez la référence Guardrails pour le moteur complet, ou exposition de PII et fuite de secrets pour les menaces que le masquage est conçu pour contenir.