Guardrails

Une fois que vous disposez d’un espace de travail et d’une clé API (voir Introduction), les guardrails sont la façon de placer une politique de contenu devant chaque modèle. Cette page est la référence canonique du moteur de guardrails d’OrcaRouter — ce que c’est, comment l’utiliser, et comment il se compose avec le reste de la passerelle.

1. Qu’est-ce que le moteur de guardrails

Un guardrail est une politique de contenu nommée, à portée d’espace de travail — une liste ordonnée de règles que la passerelle exécute contre l’entrée de la requête et la sortie du modèle. Vous enregistrez un guardrail une seule fois, liez n’importe quelle clé API à ce guardrail (ou en définissez un comme défaut de l’espace de travail), et la passerelle filtre chaque appel avant et après le modèle en amont. Chaque règle décide d’une seule chose — quoi rechercher (un type de règle), où chercher (une étape : entrée de la requête ou sortie du modèle), et quoi en faire (une action : block, mask ou flag). Le moteur exécute toutes les règles applicables et fond les résultats en une seule décision. La modification d’un guardrail prend effet sur chaque clé qui y est attachée dès le prochain appel. Aucun redéploiement. Aucun changement de code. Aucune mise à jour du SDK. La politique vit dans la passerelle, pas dans votre application — votre application continue d’appeler /v1/chat/completions exactement comme auparavant. Le moteur est déterministe et sans dépendance pour les types de règles intégrés : pur appariement de chaînes et de regex sans appel réseau, sûr à exécuter sur le chemin de relais à chaud. Les règles avancées (fournisseurs externes, juge LLM, ancrage contextuel) font des appels sortants et sont dispatchées en concurrence afin qu’une vérification lente ne se sérialise jamais derrière une autre. Les guardrails sont à portée d’espace de travail — chaque membre voit les guardrails de l’espace de travail ; rien ne franchit les frontières du tenant.

2. Démarrage rapide — filtrez votre première requête en 5 étapes

Créer un guardrail

Dans la console, allez sur /console/guardrails et cliquez sur New guardrail. Nommez-le pii-shield. Ajoutez une règle :

Type : PII detection
Étape : Input (request)
Action : Mask — redacter la correspondance
Entités : email, phone, ssn

Enregistrez.

Le tester dans le sandbox

Ouvrez l’onglet Test à l’intérieur de l’éditeur, collez “email me at jane@acme.com”, choisissez l’étape input, et lancez. Le sandbox affiche le verdict et le texte rendu — email me at [EMAIL] — sans rien envoyer en amont.

Attacher une clé

Allez sur /console/token, créez ou modifiez une clé API, et choisissez pii-shield dans la liste déroulante Guardrail. La liaison vit sur la clé dans la passerelle.

Envoyer une requête

Avec cette clé, appelez OrcaRouter exactement comme avant :

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 please"}
    ]
  }'

La passerelle masque l’email en [EMAIL] avant transmission. Le modèle en amont ne voit jamais l’adresse.

Renforcer la politique

De retour sur /console/guardrails, modifiez pii-shield — changez l’action sur ssn en Block via un override par entité. Enregistrez. La toute prochaine requête contenant un SSN est rejetée avec une HTTP 400 guardrail_blocked. Aucun changement applicatif.

C’est la valeur phare.

3. Concepts : guardrails, règles, étapes, actions

Concept	Définition
Guardrail	Une politique nommée, à portée d’espace de travail. Identifiant : `name` (≤ 64 caractères). Possède `enabled`, `is_default`, et un blob JSON `rules`.
Règle	Une vérification à l’intérieur d’une politique : un `type`, une `stage`, une `action`, plus des champs spécifiques au type. Les règles s’exécutent dans l’ordre.
Étape	`input` (la requête), `output` (la réponse du modèle), ou `both`.
Action	`block` (rejeter l’appel), `mask` (redacter la correspondance), ou `flag` (journaliser uniquement — observer sans modifier le trafic).

Portée et défaut de l’espace de travail

Les guardrails sont scopés exactement comme les clés API : partagés dans l’espace de travail lorsque vous avez un espace de travail actif, par utilisateur sinon. Résolution pour toute requête :

Attachement de clé — si la clé a un guardrail_id explicite, ce guardrail s’applique (lorsqu’il existe et est activé). Un attachement explicite ne retombe jamais silencieusement ; le désactiver est l’interrupteur d’arrêt.
Défaut de l’espace de travail — si la clé n’a pas d’attachement, le guardrail is_default activé de l’espace de travail s’applique.
Ni l’un ni l’autre — aucune application. La requête est identique octet pour octet à un espace de travail qui n’a jamais activé la fonctionnalité.

Au plus un guardrail par espace de travail peut être le défaut. Promouvoir un nouveau défaut rétrograde l’ancien dans la même transaction.

Fail-open par conception. Si la résolution d’un guardrail rencontre une erreur transitoire (par exemple un hoquet de la BD), la passerelle dégrade vers aucune application plutôt que de couper le trafic. La sécurité se dégrade ; la disponibilité est préservée.

À quoi ressemble un block

Une requête bloquée renvoie une HTTP 400 avec le code d’erreur guardrail_blocked et un message nommant le guardrail et la règle qui s’est déclenchée. Une requête bloquée ne vous coûte aucun quota — un block à l’étape input se déclenche avant la mesure, et un block à l’étape output rembourse le quota pré-consommé — et elle est marquée skip-retry (ré-exécuter le même prompt ne ferait que bloquer à nouveau).

4. Types de règles

Les règles se répartissent en deux groupes : intégrées (déterministes, sans réseau) et avancées (appels sortants vers un modèle ou un fournisseur).

Type	Groupe	Ce qu’il fait
Liste de mots interdits (`keyword`)	Intégrée	Correspond à l’un des termes littéraux d’une liste — insensible à la casse, correspondance de sous-chaîne (ainsi `class` correspond aussi à `classic`).
Expression régulière (`regex`)	Intégrée	Correspond à un motif RE2 (temps linéaire, sans backreferences).
Détection de PII (`pii`)	Intégrée	Détecte les types d’entités intégrés (et vos propres types personnalisés). Voir §5.
Longueur maximale (`max_chars`)	Intégrée	Plafonne le nombre de caractères du texte à une étape.
Fournisseur externe (`external`)	Avancée	Délègue la vérification à un fournisseur connecté (Aporia, Averta, webhook BYO, …). Voir §9.
Juge LLM (`llm_judge`)	Avancée	Exécute une vérification sémantique contre un modèle de votre espace de travail. Voir §6.
Ancrage contextuel (`grounding`)	Avancée	Évalue la fidélité de la réponse par rapport aux sources récupérées sur la requête (RAG). Voir §7.

Un guardrail mélange un nombre quelconque de règles de types quelconques. Les règles avancées (external, llm_judge, grounding) sont dispatchées en concurrence afin qu’une vérification lente ne se sérialise pas derrière une autre.

5. Détection de PII en profondeur

Une règle pii détecte les entités sensibles et applique l’action de la règle à chaque correspondance. L’ensemble de détecteurs intégrés est fermé et partagé par le moteur, le validateur et le constructeur de règles : email, phone, credit_card, ssn, ip, iban, mac_address, api_key_openai, aws_access_key, jwt, bitcoin_address. Sur une action mask, chaque correspondance est remplacée par une balise typée — un email devient [EMAIL], un SSN devient [SSN], et ainsi de suite.

Entités personnalisées

Superposez vos propres détecteurs par-dessus l’ensemble intégré. Une entité personnalisée est :

name — ASCII minuscule / chiffres / underscore, doit commencer par une lettre (par exemple employee_id). Circule dans les journaux d’audit et la télémétrie sans guillemets.
pattern — une regex Go RE2 (temps linéaire, sans backreferences).
checksum — optionnel ; luhn valide la correspondance avec l’algorithme de Luhn (par exemple pour les numéros de type carte).
mask_with — remplacement verbatim optionnel ; par défaut [<UPPERCASE_NAME>].

Jusqu’à 25 entités personnalisées par règle (chacune est un scan regex sur l’intégralité du texte, donc le plafond garde le chemin à chaud linéaire). Les motifs compilés sont mis en cache à travers les requêtes.

Overrides d’action par entité

Une seule règle PII peut appliquer différentes actions à différentes entités via entity_actions. Une règle qui masque les emails / téléphones / IPs par défaut mais bloque sur credit_card ou ssn — au lieu de trois règles qui se chevauchent :

{
  "type": "pii",
  "stage": "input",
  "action": "mask",
  "entities": ["email", "phone", "ip", "credit_card", "ssn"],
  "entity_actions": {
    "credit_card": "block",
    "ssn": "block"
  }
}

Les clés doivent être une entité activée sur la règle ; les valeurs doivent être block / mask / flag. Le validateur rejette tout le reste.

6. Juge LLM

Une règle llm_judge exécute une vérification sémantique contre un modèle que votre espace de travail peut déjà appeler. Utilisez-la pour les politiques floues qu’aucune regex ne capture — toxicité, harcèlement, hors-sujet, intention d’injection de prompt.

Champ	Signification
`judge_model`	Le modèle ou l’alias de routeur avec lequel évaluer (par exemple `gpt-4o-mini`, `orcarouter/cheap`). Résolu contre les canaux de votre espace de travail.
`judge_rubric`	Le message système décrivant ce qu’il faut signaler.
`judge_format`	L’une des valeurs `yes_no`, `score` ou `category` (requis ; la console présélectionne `yes_no`).
`judge_threshold`	Pour `score` : bloque/signale lorsque le score est égal ou supérieur à cette valeur.
`judge_categories`	Pour `category` : la liste refusée.
`judge_timeout_ms`	Borne l’appel au juge. `0` → défaut du moteur.
`judge_fail_open`	`true` (défaut) → une erreur du juge est observée mais la requête continue ; `false` → traiter l’erreur/timeout comme un block.

L’appel au juge est routé à travers les canaux de votre espace de travail, donc ses tokens sont facturés et attribués comme tout autre appel (comme une sous-ligne de juge). Le moteur ajoute une annexe de schéma JSON à votre rubric afin que le modèle renvoie une sortie analysable.

7. Ancrage contextuel

Une règle grounding mesure la réponse de l’assistant par rapport aux sources récupérées sur la requête (votre contexte RAG) et signale ou bloque les réponses qui ne leur sont pas fidèles. Elle réutilise la couture du juge — mêmes canaux de l’espace de travail, même attribution de coût.

Champ	Défaut	Signification
`grounding_model`	choix de l’espace de travail	Le modèle vers lequel le runner résout la vérification de fidélité.
`grounding_rubric`	intégré	Remplace le rubric de fidélité par défaut.
`grounding_threshold`	`0.7`	Plancher de fidélité, `0.0`–`1.0`. En dessous, l’action se déclenche.
`grounding_strict`	`false`	Lorsque `true`, “no sources provided” est traité comme un block (vs l’autorisation par défaut).
`grounding_max_bytes`	`100000`	Plafonne le contexte source concaténé remis au juge.
`grounding_timeout_ms`	`3000`	Borne l’appel au juge.

8. Templates, le sandbox et le harnais d’évaluation

Bibliothèque de templates

Le split-button New guardrail ouvre directement sur un template, et la bibliothèque complète est à un clic. Les presets sont créés côté serveur afin que la console, le sandbox et cette documentation décrivent exactement le même comportement. Les catégories incluent :

PII (pii) — PII Shield, PII Blocker (strict), Contact-Info Redactor, response PII redactor.
Secrets (secrets) — bloqueurs de credentials AWS / OpenAI / GitHub, clés privées & tokens cloud, portefeuilles crypto, secrets en sortie.
Compliance (compliance) — GDPR (PII UE), PCI (block complet de carte), HIPAA (PHI), données financières, compliance logger, application de mention légale.
Brand (brand) — grossièretés (block / mask / multilingue), mentions de concurrents, mots-clés de sécurité enfance.
Safety (safety) — injection de prompt, jailbreak, fuite de prompt système, automutilation.
Cost (cost) — plafonds de taille de prompt / réponse et plafonds de tokens.
Agent (agent) — filtres URL, image markdown, appel d’outil shell et injection SQL en sortie.

Appliquez un preset comme point de départ, puis modifiez librement — un preset est une graine, pas un verrou.

Le sandbox de test

Chaque éditeur a un onglet Test. Collez un échantillon, choisissez une étape, et exécutez la politique actuelle localement — aucun appel en amont, aucun quota. Le sandbox renvoie le verdict et (pour les règles mask) le texte rendu, afin que vous puissiez prouver qu’une règle fait ce que vous attendez avant d’attacher une clé.

Harnais d’évaluation / red-team

L’onglet Eval exécute un guardrail contre un corpus d’entrées et rapporte comment il a été scoré — utile pour ajuster un rubric de juge ou prouver qu’une politique attrape des attaques connues avant de la livrer.

Corpus fournis livrés avec la passerelle — ensembles adverses et de red-team (prompts de comportement nuisible, injection d’outils, red-teaming multilingue) plus des ensembles bénins pour mesurer les faux positifs.
Corpus personnalisés — chargez votre propre JSONL pour tester contre vos formes de trafic réelles.
Exécutions listées avec leurs scores ; ouvrez une exécution pour inspecter les échecs échantillon par échantillon.

9. Fournisseurs externes

Une règle external délègue la vérification à un fournisseur connecté. Connectez un fournisseur une fois sous Integrations (le CTA d’en-tête sur la page Guardrails), puis référencez la connexion depuis une règle.

Fournisseurs pris en charge

Fournisseur	De quoi s’agit-il
Aporia Guardrails (`aporia`)	Moteur de politiques à ensemble de SLM pour les prompts et les réponses.
Averta (`averta`)	Endpoint générique de classifieur SLM (POST du texte → safe / unsafe + réécriture optionnelle).
BYO Webhook (`webhook`)	Votre propre URL — recevez les prompts et renvoyez des verdicts allow / block / mask / flag.

Aporia et Averta prennent une URL de base + une clé API ; le webhook prend une URL + un en-tête d’authentification + un secret HMAC.

Champs de la règle

Champ	Signification
`connection_id`	L’intégration connectée à utiliser (chemin recommandé — le fournisseur + les secrets se résolvent depuis l’intégration de l’espace de travail à l’exécution).
`timeout_ms`	Borne l’unique appel au fournisseur. `0` → défaut.
`fail_open`	`true` (défaut) → une erreur du fournisseur est observée mais la requête continue ; `false` → traiter erreur de transport / timeout / fournisseur inconnu comme un block.

Les secrets sont stockés chiffrés et masqués en lecture. L’appel de vérification porte l’annulation de la requête de relais, donc une requête annulée ne laisse pas un appel au fournisseur en suspens.

10. Observabilité

Les guardrails laissent des traces sur lesquelles vous pouvez agir.

Flux des correspondances

Chaque règle qui se déclenche enregistre une correspondance — type de règle, action, une chaîne de détail, l’étape, et (lorsqu’activé) la sous-chaîne correspondante. L’onglet Matches sur la page Guardrails est le flux à l’échelle de l’espace de travail : lister, grouper, filtrer, plonger dans une seule correspondance, exporter en CSV, et marquer les faux positifs.

La capture de contenu brut est opt-in. Le bouton Log raw content d’un guardrail est désactivé par défaut — la posture conservatrice en matière de confidentialité. Avec lui désactivé, le flux Matches enregistre qu’une règle s’est déclenchée et sa méta-chaîne de détail, mais pas la sous-chaîne réellement correspondante (par exemple l’adresse email elle-même). Activez-le par guardrail lorsque vous avez besoin de la sous-chaîne pour le triage ; le réglage n’est pas rétroactif.

Stats

Le flux Matches alimente les stats par guardrail — chaque carte de guardrail affiche un sparkline et un compte de correspondances sur 7 jours, et l’onglet Matches porte un total à l’échelle de l’espace de travail. Pour trancher l’activité par politique, utilisez la vue groupée et les filtres du flux Matches (par guardrail, type de règle, action) — c’est là que vivent l’usage par guardrail, le mix d’actions et le taux de faux positifs.

Historique des versions et audit

Chaque création, mise à jour et suppression écrit une ligne d’historique versionnée dans la même transaction que le changement. Ouvrez History sur la ligne d’un guardrail pour :

Voir chaque version avec qui l’a changée et quand.
Diff entre deux versions quelconques.
Revert vers une version plus ancienne (enregistré comme une nouvelle version — l’historique n’est jamais muté).

11. Relation avec le reste de la passerelle

Surface	Comment cela se compose avec les Guardrails ?
Modèles	Les guardrails sont indépendants du modèle. La même politique circule sur GPT-5, Claude, Gemini — elle filtre le texte, pas le choix du modèle.
Routage	Indépendant. Le routage décide quel modèle/canal sert la requête ; les guardrails filtrent le même texte de requête/réponse quoi qu’il arrive et ne remplacent jamais la sélection du modèle. Le filtrage d’entrée s’exécute avant l’appel amont, le filtrage de sortie après que le modèle a répondu. Les règles de juge et d’ancrage résolvent leur propre modèle via les canaux de votre espace de travail, séparément du routage de la requête.
Prompts	Indépendant et complémentaire. Prompts injecte un message système ; les guardrails inspectent et contrôlent le contenu. Les deux peuvent s’appliquer à une même requête et les guardrails s’exécutent toujours. L’ordre compte : les règles d’entrée filtrent la requête de l’appelant avant qu’un prompt du registre ne soit injecté (l’injection se produit plus tard, à l’étape de routage), donc les règles d’entrée voient les messages de l’appelant, pas le prompt système injecté ; les règles de sortie filtrent la réponse du modèle dans tous les cas.
Clés API	Une clé s’attache à un guardrail via `guardrail_id`. La liaison vit sur la clé dans la passerelle, donc modifier le guardrail déplace toutes les clés attachées en même temps ; sans attachement, on retombe sur le défaut de l’espace de travail.
Flux des correspondances	Chaque règle qui se déclenche atterrit dans le flux Matches de l’espace de travail (son propre store, séparé du journal de requête). Groupez-le et filtrez-le par guardrail, type de règle et action pour voir l’usage, le mix d’actions et le taux de faux positifs par guardrail.

12. Référence API

Toutes les routes sont à portée d’espace de travail via l’en-tête X-Workspace-Id. RBAC est appliqué de manière cohérente : les lectures et le sandbox de test sont ouverts à chaque membre ; les écritures nécessitent Developer+ (et la permission guardrails:write) ; les changements de trafic de production (suppression, revert, configuration de fournisseur) sont contrôlés en conséquence.

Méthode & chemin	Rôle	Objectif
`GET /api/guardrail/`	Member	Liste les guardrails (avec les comptes de clés attachées).
`GET /api/guardrail/meta`	Member	Vocabulaire du moteur — types de règles, étapes, actions, entités PII, presets, catégories de presets.
`GET /api/guardrail/my-permissions`	Member	Les permissions de guardrail de l’appelant (pour le contrôle de l’UI).
`GET /api/guardrail/:id`	Member	Détail d’un seul guardrail.
`GET /api/guardrail/:id/tokens`	Member	Clés API attachées à ce guardrail (plafonné, avec le vrai total).
`POST /api/guardrail/test`	Member	Sandbox — évalue une politique sur un texte d’échantillon à une étape. Rien n’est persisté.
`POST /api/guardrail/`	Developer+	Créer un guardrail.
`PUT /api/guardrail/`	Developer+	Mettre à jour un guardrail (écrit une nouvelle version d’historique).
`DELETE /api/guardrail/:id`	Developer+	Supprimer un guardrail.

Historique

Méthode & chemin	Rôle	Objectif
`GET /api/guardrail/:id/history`	Member	Historique des versions (plus récente d’abord).
`GET /api/guardrail/:id/history/diff`	Member	Diff entre deux versions.
`GET /api/guardrail/:id/history/:version`	Member	Une seule version historique.
`POST /api/guardrail/:id/revert`	Developer+	Restaurer une version plus ancienne comme nouvelle version.

Eval et corpus

Méthode & chemin	Rôle	Objectif
`POST /api/guardrail/:id/eval`	Member	Exécuter une éval sur un corpus (nom fourni ou JSONL chargé).
`GET /api/guardrail/:id/eval/runs`	Member	Liste les exécutions d’éval pour un guardrail (paginée).
`GET /api/guardrail/eval/runs/:run_id`	Member	Détail d’une seule exécution d’éval.
`GET /api/guardrail/eval/corpora`	Member	Liste les corpus de l’espace de travail + les corpus fournis.
`POST /api/guardrail/eval/corpora`	Developer+	Charger un corpus JSONL.
`GET /api/guardrail/eval/corpora/:id`	Member	Détail d’un corpus.
`DELETE /api/guardrail/eval/corpora/:id`	Developer+	Supprimer un corpus.

Correspondances

Méthode & chemin	Rôle	Objectif
`GET /api/guardrail/match`	Member	Liste les correspondances (à portée d’espace de travail).
`GET /api/guardrail/match/grouped`	Member	Correspondances groupées (par exemple par règle ou par guardrail).
`GET /api/guardrail/match/stats`	Member	Stats de correspondances (supporte `?days=` et `?group_by=`).
`GET /api/guardrail/match/export`	Member	Exporter les correspondances en CSV.
`GET /api/guardrail/match/:id`	Member	Détail d’une seule correspondance.
`POST /api/guardrail/match/:id/mark-fp`	Admin	Marquer une correspondance comme faux positif (rate-limited).
`DELETE /api/guardrail/match/:id/mark-fp`	Admin	Annuler le marquage d’un faux positif (rate-limited).

Attacher une clé

Définissez guardrail_id sur la clé API (via l’éditeur de clé ou l’API token). 0/null signifie aucun attachement explicite — la clé retombe sur le guardrail par défaut de l’espace de travail, s’il y en a un de défini.

13. FAQ

Que se passe-t-il si aucun guardrail ne se résout sur une requête ?

Le comportement est identique octet pour octet à un espace de travail qui n’a jamais activé la fonctionnalité. Si la clé n’est pas attachée et qu’aucun défaut d’espace de travail n’est défini, la passerelle ne fait aucune modification. Rien n’est bloqué, masqué ou journalisé dans le flux Matches.

Une requête bloquée coûte-t-elle du quota ?

Non. Un block à l’étape input se déclenche avant que l’usage ne soit mesuré ; un block à l’étape output rembourse le quota pré-consommé après le rejet de la réponse. Dans les deux cas, l’appelant ne paie aucun quota, obtient une HTTP 400 guardrail_blocked, et la requête est marquée skip-retry (ré-exécuter le même prompt contre un autre canal ne ferait que bloquer à nouveau).

Les règles de sortie (réponse) sont-elles appliquées au streaming ?

Cela dépend de l’action. Block est appliqué dans les deux cas : sur une réponse non-streaming, la réponse est examinée avant d’être renvoyée, et sur une réponse streaming, un scanner coupe le flux en plein vol et émet un message de remplacement avant que tout contenu bloqué n’atteigne le client. Mask sur la sortie ne s’applique actuellement qu’aux réponses non-streaming — sur une réponse streaming, le chunk original passe sans être masqué (la réécriture du flux in-band est une amélioration prévue). Pour le masquage de sortie aujourd’hui, utilisez des requêtes non-streaming ou appuyez-vous sur le masquage à l’étape input. Prouvez votre combinaison spécifique étape/flux dans le sandbox et avec une exécution d’éval avant de vous y fier.

Quelle est la différence entre mask et block ?

Mask redacte la correspondance (par exemple jane@acme.com → [EMAIL]) et laisse passer la requête avec le texte assaini — le modèle en amont ne voit jamais l’original. Block rejette toute la requête avec une HTTP 400. Flag ne change rien au trafic et enregistre seulement une correspondance — utilisez-le pour mesurer une règle avant de l’appliquer.

Les tokens de prompt injectés et les tokens du juge sont-ils facturés ?

Une règle intégrée (keyword / regex / PII / max_chars) ne fait aucun appel au modèle et ne facture rien. Une règle llm_judge ou grounding appelle un modèle à travers les canaux de votre espace de travail, donc ces tokens sont facturés et attribués comme une sous-ligne de juge.

Comment voir ce qu'une règle a réellement fait correspondre ?

Activez Log raw content pour le guardrail. Avec lui désactivé (le défaut), le flux Matches enregistre qu’une règle s’est déclenchée et sa méta-chaîne de détail mais pas la sous-chaîne correspondante — la posture conservatrice en matière de confidentialité. Le bouton n’est pas rétroactif : il n’affecte que les correspondances enregistrées après que vous l’avez activé.

Puis-je annuler un changement de guardrail ?

Oui. Ouvrez History sur le guardrail, faites le diff des versions, et faites Revert vers celle que vous voulez. Revert copie le contenu de cette version en avant comme une nouvelle version — l’historique n’est jamais muté — et le changement prend effet à la prochaine requête.

Que se passe-t-il si un fournisseur externe ou un juge time out ?

Par défaut, les règles avancées fail open : un timeout ou une erreur de transport est enregistré comme télémétrie et la requête continue. Mettez fail_open (external) ou judge_fail_open (juge) à false pour fail closed — traiter l’erreur comme un block — pour les politiques où une vérification manquée est inacceptable.

​1. Qu’est-ce que le moteur de guardrails

​2. Démarrage rapide — filtrez votre première requête en 5 étapes

​3. Concepts : guardrails, règles, étapes, actions

​Portée et défaut de l’espace de travail

​À quoi ressemble un block

​4. Types de règles

​5. Détection de PII en profondeur

​Entités personnalisées

​Overrides d’action par entité

​6. Juge LLM

​7. Ancrage contextuel

​8. Templates, le sandbox et le harnais d’évaluation

​Bibliothèque de templates

​Le sandbox de test

​Harnais d’évaluation / red-team

​9. Fournisseurs externes

​Fournisseurs pris en charge

​Champs de la règle

​10. Observabilité

​Flux des correspondances

​Stats

​Historique des versions et audit

​11. Relation avec le reste de la passerelle

​12. Référence API

​Guardrails

​Historique

​Eval et corpus

​Correspondances

​Attacher une clé

​13. FAQ

1. Qu’est-ce que le moteur de guardrails

2. Démarrage rapide — filtrez votre première requête en 5 étapes

3. Concepts : guardrails, règles, étapes, actions

Portée et défaut de l’espace de travail

À quoi ressemble un block

4. Types de règles

5. Détection de PII en profondeur

Entités personnalisées

Overrides d’action par entité

6. Juge LLM

7. Ancrage contextuel

8. Templates, le sandbox et le harnais d’évaluation

Bibliothèque de templates

Le sandbox de test

Harnais d’évaluation / red-team

9. Fournisseurs externes

Fournisseurs pris en charge

Champs de la règle

10. Observabilité

Flux des correspondances

Stats

Historique des versions et audit

11. Relation avec le reste de la passerelle

12. Référence API

Guardrails

Historique

Eval et corpus

Correspondances

Attacher une clé

13. FAQ