Passer au contenu principal
Tout prompt que votre application envoie à un modèle peut transporter des données personnelles qu’il ne devrait pas — un e-mail collé dans un ticket de support, un SSN dans une note CRM, un numéro de carte qu’un utilisateur a tapé dans une zone de chat. Une fois que ce texte atteint un fournisseur amont, il est hors de votre contrôle : journalisé, mis en cache, peut-être utilisé pour l’entraînement. La réponse du modèle peut elle aussi laisser fuir de la PII, en répétant ou en inférant des détails qui atterrissent ensuite dans les journaux de votre application. Cette page montre comment stopper une fuite de PII llm à la passerelle avec un guardrail PII — une règle à portée d’espace de travail qui masque ou bloque les entités sensibles sur la requête avant que le modèle ne les voie. C’est le pendant côté contenu de l’Agent Firewall, et il ne nécessite aucun changement dans le code de votre application.
Un guardrail PII filtre le texte des prompts et des réponses. Pour gouverner les actions qu’un agent entreprend avec les données — outils de récupération, hôtes d’egress — voir Exfiltration de données. Les deux plans se composent ; la plupart des équipes utilisent les deux.

​
1. Comment l’exposition se produit

La PII atteint un fournisseur amont à travers du trafic ordinaire et bien intentionné :
  • Un utilisateur colle ses propres coordonnées dans un chat et votre application transmet le message entier mot pour mot.
  • Un pipeline RAG récupère un document contenant des dossiers clients et le bourre dans le prompt comme contexte.
  • Un agent lit une ligne de base de données et inclut des champs bruts dans un argument d’outil ou un prompt de suivi.
  • La réponse du modèle reformule ou infère de la PII, que votre application écrit ensuite dans ses propres journaux.
Aucun de ces cas n’est une attaque — c’est la forme normale des applications LLM. La correction est une politique qui filtre chaque requête et chaque réponse à un point d’étranglement unique, au lieu d’auditer chaque site d’appel dans votre code.

​
2. Défendez la fuite de PII llm avec un guardrail PII

Un guardrail est une politique de contenu nommée, à portée d’espace de travail. Une règle pii à l’intérieur détecte les entités sensibles et applique une action à chaque correspondance :
ActionEffet
maskRemplace chaque correspondance par un tag typé — jane@acme.com → [EMAIL] — et transmet le texte nettoyé. Le modèle ne voit jamais l’original.
blockRejette la requête entière avec une HTTP 400 guardrail_blocked. À utiliser lorsque la PII ne doit jamais atteindre le fournisseur.
flagNe change rien au trafic ; enregistre une correspondance. Mesurez l’exposition avant d’appliquer.
L’ensemble des détecteurs est intégré et déterministe — pure correspondance de motifs, aucun appel réseau, sûr sur le chemin chaud. Entités intégrées : email, phone, credit_card, ssn, ip, iban, mac_address, jwt, aws_access_key, api_key_openai, bitcoin_address, plus les identifiants régionaux à checksum jp_mynumber, kr_rrn, et cn_resident_id. Sur une action mask, chaque correspondance se rend sous forme de son tag typé — [EMAIL], [SSN], [CREDIT_CARD], et ainsi de suite — de sorte que la structure du prompt survit tandis que la valeur disparaît.
Besoin d’un détecteur qui n’est pas intégré (un identifiant d’employé interne, un numéro de compte) ? Ajoutez une entité personnalisée — un regex avec checksum Luhn optionnel, jusqu’à 25 par règle — directement aux côtés des intégrées. Voir la référence des Guardrails.

​
3. Exemple concret — masquer la PII sur la requête

Le démarrage le plus rapide est le preset PII Shield : une seule règle pii qui masque email, phone, ssn, credit_card, et ip. Configurez-le dans la console — aucun changement de code, aucune clé à cette étape.
1

Créer le guardrail

Dans la console, ouvrez Guardrails et cliquez sur New guardrail. Choisissez le preset PII Shield dans la catégorie pii, ou rédigez à la main une règle pii avec l’action mask sur les entités ci-dessus. Enregistrez. (Les écritures requièrent le rôle Developer ou supérieur.)
2

Prouvez-le dans le sandbox

Ouvrez l’onglet Test, collez “reply to jane@acme.com”, choisissez la surface input, et exécutez. Le sandbox renvoie reply to [EMAIL] — localement, sans appel amont et sans quota dépensé.
3

Attachez-le à une clé

Dans API Keys, éditez une clé et sélectionnez le guardrail dans le menu déroulant Guardrail, ou définissez le guardrail comme défaut de l’espace de travail afin que chaque clé non attachée en hérite. La liaison vit sur la clé dans la passerelle.
4

Appelez la passerelle comme d'habitude

Avec cette clé, votre appel de relais est inchangé :
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": "Draft a reply to jane@acme.com"}
    ]
  }'
La passerelle réécrit l’e-mail en [EMAIL] avant de transmettre. Le modèle amont ne reçoit jamais l’adresse.
PII Shield est une règle à surface both, mais le masquage en direct au niveau de la requête est ce qui est livré aujourd’hui — la passerelle masque le prompt avant qu’il ne parte pour le modèle. Le masquage côté sortie (réponse) sur le relais en direct est sur la feuille de route. Pour vérifier comment se comporte une règle côté sortie, évaluez-la dans l’onglet Test. Pour le streaming, voir §5.

​
4. Masquer le plus, bloquer le pire — surcharges par entité

Une seule règle peut appliquer différentes actions à différentes entités via entity_actions. Masquez les identifiants à faible risque mais bloquez fermement les entités que vous ne voulez jamais transmettre — une règle au lieu de trois qui se chevauchent : 
{
  "type": "pii",
  "stage": "input",
  "action": "mask",
  "entities": ["email", "phone", "ip", "credit_card", "ssn"],
  "entity_actions": {
    "credit_card": "block",
    "ssn": "block"
  }
}
Ici, les e-mails, les téléphones et les IP sont masqués et passent ; un prompt portant un numéro de carte ou un SSN est rejeté avec une HTTP 400 guardrail_blocked à la place. Une requête bloquée ne coûte aucun quota — un block côté entrée se déclenche avant la mesure — et est marquée skip-retry. Chaque clé entity_actions doit être une entité déclarée sur la règle (intégrée ou personnalisée) ; son action est validée contre l’ensemble d’actions de la règle.

​
5. Ce qui fonctionne sur le streaming aujourd’hui

L’action et la surface interagissent différemment avec le streaming — connaissez la matrice avant d’en dépendre :
Entièrement en direct. Le prompt est filtré avant l’appel amont, donc le masquage et le blocage fonctionnent à l’identique que la réponse soit en streaming ou non. C’est la surface que PII Shield applique aujourd’hui.
Appliqué sur les réponses en streaming et non-streaming. Sur un flux, un scanner coupe le flux en vol et émet un message de remplacement avant qu’aucun contenu bloqué n’atteigne le client ; un block en sortie rembourse le quota pré-consommé.
Actuellement non-streaming uniquement. Sur une réponse en streaming, le chunk d’origine passe non masqué — la réécriture de flux en bande est une amélioration planifiée. Pour le masquage de réponse aujourd’hui, utilisez des requêtes non-streaming, ou reposez-vous sur le masquage côté entrée. Prouvez d’abord votre combinaison exacte surface/flux dans l’onglet Test.

​
6. Voir ce qui a été attrapé

Chaque règle qui se déclenche enregistre une correspondance — son type, son action, sa surface, et une chaîne de détail — visible sur le flux Matches de l’espace de travail (GET /api/guardrail/match, ouvert à tout membre). De là, vous pouvez grouper, filtrer, exporter en CSV, et marquer les faux positifs.
Les valeurs brutes ne sont pas journalisées par défaut. L’interrupteur Log raw content d’un guardrail est désactivé — la posture respectueuse de la vie privée — de sorte que le flux Matches enregistre qu’une règle PII s’est déclenchée et quelle entité, mais pas la sous-chaîne correspondante (l’adresse e-mail elle-même). Activez-le par guardrail uniquement lorsque vous avez besoin de la valeur pour le triage ; le réglage n’est pas rétroactif. Capturer la PII dans votre propre piste d’audit pour déboguer une fuite de PII serait contre-productif.

​
7. Aller plus loin

Pour des contrôles complets de résidence, de rétention et de droit à l’effacement — y compris l’installation d’un compliance pack qui matérialise ces guardrails pour le RGPD, HIPAA ou PCI DSS — partez des pages de référence ci-dessous.

Référence des Guardrails

Chaque type de règle, surface, action, entités personnalisées, versionnage, et le harnais d’éval — la référence approfondie derrière cette page.

Fuite de secrets

Le frère en forme d’identifiant — tokens AWS, OpenAI, GitHub — attrapé par le guardrail Secrets Blocker.

Sortie non sûre

Filtrer ce que le modèle renvoie, pas seulement ce qu’il reçoit.

Guardrails vs Firewall

Quand filtrer le texte et quand gouverner les actions — et pourquoi vous voulez généralement les deux.