Passer au contenu principal
Une partie de ce que vous avez besoin d’attraper n’est pas un mot littéral et n’est pas une entité PII typée — c’est une forme. Un format de SKU, une disposition de numéro de commande, un motif d’URL interne, un code de coupon, une référence de contrat. Une règle regex vous permet de faire correspondre cette forme à chaque appel puis de la bloquer, masquer ou signaler, avant que le prompt n’atteigne le modèle et avant que la réponse n’atteigne votre utilisateur. C’est une page d’atterrissage ciblée sur le cas d’usage des motifs structurés. Pour le moteur de guardrail complet — chaque type de règle, champ et route — voir la référence Guardrails.
Chaque étape ici est une action de console sur la passerelle hébergée (api.orcarouter.ai). Vous rédigez le guardrail sous votre propre session ; seul l’appel /v1/* final utilise une clé de relais sk-orca-.... Créer et modifier des guardrails nécessite Developer+ dans l’espace de travail.

​
1. Quand vous avez besoin d’un contrôle de guardrail regex llm

Une règle regex est le bon outil quand la chose que vous voulez attraper a une structure qu’une liste de mots interdits littérale ne peut pas exprimer mais n’est pas une identité standard que le détecteur pii couvre déjà.

Codes structurés

SKUs, codes de coupon, références de contrat, identifiants de ticket internes — un préfixe fixe plus une suite de chiffres ou alphanumérique.

Tokens en forme de format

Tout ce qui se fait correspondre par forme plutôt que par une liste finie de mots — une disposition de numéro de commande, un format de série, un motif d’URL interne.

Motifs de fuite en sortie

Une réponse qui ne devrait pas faire remonter un hostname interne, un chemin de fichier ou un format d’ID d’enregistrement — scannez la sortie du modèle pour la forme.

Vérifications déterministes et peu coûteuses

Pure correspondance de motif, aucun appel de modèle, aucun réseau — sûr à exécuter sur chaque requête dans les deux directions.
Choisissez l’outil le plus léger qui convient. Une liste finie de termes littéraux → liste de mots interdits keyword. Une forme d’identité nommée pour laquelle vous voulez une balise de masque typée ([EMAIL], [SSN]) ou une vérification Luhn → une entité PII / personnalisée. Un motif structurel sans typage par entité → une règle regex, couverte ici.

​
2. RE2 — temps linéaire, sans backreferences

Le pattern d’une règle regex est une regex Go RE2. RE2 est le moteur qui rend une règle regex sûre à exécuter sur chaque requête :
RE2 garantit un temps de correspondance linéaire en la longueur de l’entrée, quel que soit le motif. Un moteur à backtracking peut exploser exponentiellement sur une entrée adverse (un « ReDoS ») ; RE2 ne le peut pas. C’est pourquoi votre motif est sûr à évaluer sur le chemin à chaud à chaque appel.
RE2 ne supporte pas les backreferences (\1), le lookahead ou le lookbehind. Si vous portez un motif PCRE qui s’appuie sur eux, réécrivez-le sans eux. Les classes de caractères, les ancres, les quantificateurs, l’alternation et les groupes non-capturants fonctionnent tous comme attendu.
Il n’y a pas d’interrupteur « ignore case » séparé — définissez les flags inline. Préfixez avec (?i) pour l’insensibilité à la casse, (?m) pour le multiligne. Exemple : (?i)\bproject-orca\b.
Le constructeur de règles compile votre motif quand vous enregistrez le guardrail. Un motif qui ne compile pas est rejeté avec l’index de la règle dans l’erreur, donc un mauvais détecteur n’atteint jamais le chemin de relais.
Les motifs RE2 ne sont pas du PCRE. La surprise de portage la plus courante est une backreference ou un lookahead — aucun n’est supporté. Écrivez plutôt la correspondance comme un motif de classe de caractères / alternation et vérifiez-la dans l’onglet Test avant d’attacher une clé.

​
3. Anatomie d’une règle regex

Une règle regex est la plus petite règle du moteur après keyword : un motif, une étape et une action.
ChampCe qu’il fait
patternUne regex Go RE2 (temps linéaire, sans backreferences). Doit compiler.
stageinput (requête), output (réponse), ou both.
actionblock, mask, ou flag.
Sur une action mask, chaque correspondance est remplacée en place par une seule balise littérale [REDACTED] — une règle regex n’est pas typée, donc elle ne rend pas une balise par entité comme [EMAIL]. Si vous voulez une balise typée ou un token de remplacement personnalisé, modélisez plutôt la forme comme une entité PII personnalisée.

​
4. Un exemple concret

Supposons que vos numéros de commande internes ressemblent à ORD- suivi de huit chiffres, et que vous ne voulez jamais qu’un soit renvoyé en écho dans la réponse d’un modèle. Ajoutez une seule règle regex à l’étape output : 
{
  "type": "regex",
  "stage": "output",
  "action": "mask",
  "pattern": "ORD-\\d{8}"
}
Rédigez-la dans la console :
1

Créer un guardrail

Ouvrez Guardrails, cliquez sur New guardrail, et nommez-le (≤ 64 caractères), par exemple order-id-filter.
2

Ajouter une règle regex

Ajoutez une règle — Type : Regular expression, Étape : Output, Action : Mask — et collez le motif ORD-\d{8}. Enregistrez.
3

La tester dans le sandbox

Ouvrez l’onglet Test, collez un échantillon, choisissez l’étape output, et exécutez la politique actuelle localement — aucun appel en amont, aucun quota :
Your order ORD-48291507 has shipped.

Your order [REDACTED] has shipped.
4

Attacher une clé

Modifiez une clé API et choisissez order-id-filter dans la liste déroulante Guardrail (définit guardrail_id sur la clé), ou marquez le guardrail comme défaut de l’espace de travail. Voir Attacher à une clé et Défaut de compte.
Puis appelez OrcaRouter exactement comme avant — aucun nouvel en-tête, aucun changement de SDK : 
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": "What is the status of my order?"}
    ]
  }'
Le numéro de commande est redacté dans la réponse avant qu’elle n’atteigne votre utilisateur.

​
5. Étape et couverture du streaming

L’action que vous choisissez interagit avec le fait que la réponse soit streamée ou non :
ActionNon-streamingStreaming
block (output)AppliquéAppliqué — le scanner coupe le flux
mask (output)AppliquéAppliqué — le scanner réécrit le buffer
Les règles à l’étape input s’exécutent avant l’appel en amont, donc elles ne sont pas affectées par le streaming — masquer la requête avant que le modèle ne la voie est actif. Le mask de sortie et le block de sortie sont tous deux appliqués sur les réponses streaming et non-streaming. Voir Couverture du streaming.

​
6. Choisir une action

Une règle regex choisit une action par règle :
Toute correspondance rejette la requête avec une HTTP 400 guardrail_blocked. Une requête bloquée ne coûte aucun quota — un block à l’étape input se déclenche avant la mesure ; un block à l’étape output rembourse le quota pré-consommé — et elle est marquée skip-retry. Voir l’erreur guardrail_blocked.
Chaque correspondance est remplacée en place par [REDACTED] et la requête continue avec le texte assaini — le modèle en amont (étape input) ou votre utilisateur (étape output) ne voit jamais l’original. Voir Actions.
Enregistre une correspondance et ne change rien au trafic. Le bon point de départ pour un nouveau motif : livrez-le en flag, surveillez le flux Matches, puis promouvez en mask/block une fois que vous lui faites confiance.
Enregistre une correspondance et attache une note (par exemple un finding à faire remonter dans le triage) sans altérer le trafic. Voir Actions.
Une défense à l’étape input : chaque correspondance est encadrée dans des délimiteurs (par exemple ⟦UNTRUSTED⟧…⟦/UNTRUSTED⟧) qui indiquent au modèle de traiter le texte comme des données, pas des instructions — une mitigation d’injection de prompt. Voir Actions.

​
7. Voir ce qui s’est déclenché — et ajuster la précision

Chaque règle qui se déclenche enregistre une correspondance — type de règle, action, étape et une chaîne de détail — dans le flux Matches de l’espace de travail.
La sous-chaîne correspondante 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é. Avec lui désactivé, vous voyez toujours *qu’*une règle regex s’est déclenchée et à quelle fréquence, juste pas le texte littéral qu’elle a attrapé. Activez-le par guardrail quand vous avez besoin de la sous-chaîne pour le triage ; le réglage n’est pas rétroactif. Voir Flux des correspondances et Journalisation & confidentialité.
Un motif trop large est le piège regex classique — \d{8} correspond à chaque suite de huit chiffres, pas seulement à vos numéros de commande. Ancrez-le (un préfixe fixe comme ORD-, des limites de mots \b), surveillez le flux Matches, et marquez les faux positifs pour resserrer au fur et à mesure. Pour une grille A/B contre un corpus — afin de prouver qu’un motif attrape ce qu’il devrait sans signaler le trafic bénin — le harnais d’évaluation vit dans l’onglet d’à côté. Voir Ajuster les faux positifs.

​
8. Où aller ensuite

Entités PII personnalisées

Quand la forme est une identité pour laquelle vous voulez une balise de masque typée ou un checksum Luhn — pas un simple [REDACTED].

Mots sensibles

Une liste finie de termes littéraux — plus simple qu’un motif quand vous n’avez pas besoin de structure.

Actions

En quoi block, mask et flag diffèrent et quand utiliser chacun.

Référence Guardrails

Le moteur complet — chaque type de règle, champ et route.
Une règle regex gouverne le contenu. Pour gouverner les appels d’outils d’un agent — refuser les actions destructrices, redacter les arguments d’appels d’outils, exiger une approbation — utilisez le Firewall et ses matchers de règles. Pour les politiques floues qu’aucun motif ne peut exprimer (toxicité, hors-sujet, intention d’injection), une règle llm_judge exécute une vérification sémantique contre un modèle de l’espace de travail. Pour voir où le regex s’inscrit dans la conception globale, lisez Guardrails vs Firewall.