Passer au contenu principal
Les vérifications de sécurité n’ont d’importance que si elles s’exécutent réellement — mais vous ne devriez pas avoir à échanger le débit contre la sécurité. Cette page répond à la question que les développeurs posent le plus souvent : l’application va-t-elle ralentir mon agent, et de combien ? La réponse courte : les règles intégrées ne coûtent rien de mesurable. Les règles avancées coûtent au plus un appel modèle borné, concurrent, fail-open. Voici pourquoi, et comment le contrôler.

​
1. Deux classes de vérification

Chaque règle guardrail et chaque évaluation firewall appartient à l’une de deux classes.

​
Vérifications intégrées / déterministes

Les règles guardrail de liste de mots interdits (keyword), d’expression régulière (regex), de détection de PII (pii), et de longueur maximale (max_chars) sont des opérations locales pures de chaînes et regex — pas d’appel modèle, pas de saut réseau, rien qui puisse expirer. L’évaluation des règles firewall (correspondance de glob de nom d’outil, prédicats d’arguments, portée d’egress) est identique : déterministe et locale. Pour des raisons pratiques, ces vérifications ajoutent une latence négligeable à votre requête. Elles sont sûres à exécuter sur le chemin à chaud et constituent la base des templates guardrail intégrés.

​
Vérifications avancées / sémantiques

Les règles llm_judge, grounding et external délèguent la vérification à un modèle ou un fournisseur. Elles coûtent un aller-retour. Trois propriétés bornent ce coût :
  1. Dispatch concurrent. Si votre politique comporte plusieurs règles avancées, elles sont dispatchées en parallèle — une vérification lente ne se sérialise jamais derrière une autre.
  2. Timeout par règle. Chaque règle avancée a un timeout (judge_timeout_ms / grounding_timeout_ms / timeout_ms). La vérification d’ancrage est par défaut à ~3 000 ms ; le juge utilise une valeur configurable (0 → défaut du moteur). La règle est bornée — elle ne peut pas rester en suspens indéfiniment.
  3. Fail-open par défaut. Quand une règle expire ou que son fournisseur retourne une erreur, l’événement est enregistré mais la requête continue. Définissez judge_fail_open: false (juge) ou fail_open: false (external) pour basculer en fail-closed à la place.
Donc le pire cas pour un nombre quelconque de règles avancées est le timeout individuel le plus long, pas la somme de tous les timeouts.

​
2. En un coup d’œil

Type de vérificationAjoute de la latence ?Comment elle est bornée
Liste de mots interdits keywordNégligeable — scan local de chaînesPas de réseau ; pas de timeout nécessaire
regexNégligeable — correspondance RE2 localePas de réseau ; pas de timeout nécessaire
Détection piiNégligeable — scan local regex/entitéPas de réseau ; pas de timeout nécessaire
max_charsNégligeable — comptage de caractèresPas de réseau ; pas de timeout nécessaire
Évaluation des règles firewallNégligeable — correspondance glob + prédicatPas de réseau ; pas de timeout nécessaire
llm_judgeUn appel modèle bornéjudge_timeout_ms ; fail-open par défaut
groundingUn appel modèle bornégrounding_timeout_ms (défaut ~3 000 ms) ; fail-open par défaut
Fournisseur externalUn appel fournisseur bornétimeout_ms ; fail_open par défaut
Plusieurs règles avancéesUn aller-retour borné (dispatch concurrent)Pire cas = timeout individuel max, pas la somme

​
3. Où dans le cycle de vie de la requête les vérifications s’exécutent

L’application ne se produit pas toute au même endroit. Le filtrage d’entrée et de sortie ajoute du temps à des endroits différents : 
Client
  │
  ▼
[Filtrage guardrail d'entrée]     ← ajoute du temps ICI, avant l'amont
  │
  ▼
Appel au modèle en amont
  │
  ▼
[Filtrage guardrail de sortie]    ← ajoute du temps ICI, après que le modèle répond
  │
  ▼
Client
Les guardrails d’entrée s’exécutent avant l’appel au modèle en amont. Une règle d’entrée intégrée ajoute une surcharge négligeable en amont. Une règle d’entrée avancée (ex. un llm_judge qui vérifie l’intention d’injection de prompt) ajoute un appel modèle borné avant que l’appel modèle principal ne commence. Les guardrails de sortie s’exécutent après que le modèle répond. Une règle de sortie intégrée ajoute une surcharge négligeable en queue. Une règle de sortie avancée (ex. grounding vérifiant la fidélité RAG) ajoute un appel borné après que vous ayez déjà la réponse du modèle. L’évaluation des règles Firewall est déterministe et se produit en ligne sur le routage des appels d’outils — négligeable, comme indiqué ci-dessus.
Une requête bloquée ne coûte aucun token de modèle et n’ajoute aucune latence amont pour les blocks en étape input. Un block d’entrée se déclenche avant la mesure et avant l’appel amont, donc vous ne payez ni quota ni temps d’aller-retour amont. Un block en étape output rembourse le quota pré-consommé après le rejet de la réponse.

​
4. Comment les timeouts et le fail-open bornent le pire cas

Les règles avancées ont deux réglages : Timeout — le temps maximal autorisé pour la vérification. La requête attend au plus aussi longtemps que cette durée pour cette règle. Le dispatch concurrent signifie que ce plafond s’applique par règle, pas par politique. Si vous avez trois règles llm_judge chacune avec un timeout de 2 000 ms, les trois s’exécutent en même temps et l’attente totale est ~2 000 ms, pas ~6 000 ms. Fail-open vs fail-closed — quoi faire quand la règle ne se termine pas dans les délais (ou que le fournisseur renvoie une erreur) :
RéglageComportement sur timeout / erreur
fail_open: true (défaut)Enregistre l’événement ; laisse la requête continuer comme si la vérification avait réussi
fail_open: falseTraite le timeout / erreur comme un block ; retourne HTTP 400 guardrail_blocked
Le fail-open préserve la disponibilité au coût d’une vérification manquée. Le fail-closed préserve la garantie de la politique au coût de la disponibilité si le juge est lent ou inaccessible. Choisissez en fonction de ce qui est le plus important pour votre cas d’usage.

​
5. Conseils pratiques

Gardez les règles du chemin à chaud intégrées. Si votre préoccupation principale est la PII, les fuites d’identifiants, la longueur du prompt, ou la liste de mots interdits — tout cela fait partie des règles intégrées. Elles n’ajoutent aucune latence mesurable et devraient être votre choix par défaut pour toute vérification que la correspondance de texte peut gérer. Utilisez llm_judge et grounding là où vous avez besoin de sémantique. La toxicité, le harcèlement, la détection hors-sujet, l’intention d’injection de prompt, et la fidélité RAG sont genuinement flous — aucune regex ne les capture de manière fiable. Ce sont les bons cas pour une règle avancée. Acceptez que chacune ajoute un appel modèle extra borné. Ajustez les timeouts à votre budget de latence. Si votre cible de bout en bout est 1 000 ms, définissez judge_timeout_ms: 800 (ou moins) afin que le juge ne puisse pas consommer tout votre budget. Le timeout par défaut du moteur est un bon point de départ ; abaissez-le si vous avez des exigences strictes. Pour l’ancrage de sortie, l’appel modèle est déjà terminé. La vérification grounding s’exécute après que le modèle en amont répond — la latence extra n’est que dans la queue, pas sur le chemin critique pour le time-to-first-token. Cela en fait un endroit à faible risque pour ajouter une application sémantique. Plusieurs règles avancées ? Répartissez le travail. Parce que les règles avancées s’exécutent de manière concurrente, empiler trois règles llm_judge coûte à peu près autant qu’une seule — le timeout individuel le plus long détermine le temps d’attente, pas le nombre. Utilisez cela pour superposer des vérifications sémantiques sans coût additif.

Modes d'application

Fail-open vs fail-closed — la référence complète pour régler le comportement de votre politique en cas de timeout et d’erreur.

Guardrails

Types de règles, champs du juge, seuils d’ancrage, et la référence complète de configuration des guardrails.
Les règles intégrées sont négligeables sur chaque chemin ; les règles avancées coûtent un appel borné, concurrent, fail-open — réglez le timeout et le mode de fail, et l’application n’ajoute aucune latence incontrôlée à vos agents.