Passer au contenu principal
Un guardrail à l’étape input filtre la requête de l’appelant avant qu’elle n’atteigne le modèle. C’est l’endroit le moins coûteux pour appliquer une politique de contenu : la passerelle inspecte le prompt à son entrée, et si une règle bloque, la requête est rejetée avant la mesure — vous ne payez rien pour l’appel. C’est là que vous empêchez un secret fuité, un champ de PII, ou une tentative d’injection d’atteindre le modèle en amont. Pour le moteur complet — chaque type de règle, champ et route — voir la référence Guardrails. Cette page est le point de vue ciblé sur l’étape input : ce qui s’exécute avant le modèle, et pourquoi un block ici ne coûte aucun quota.

​
1. Guardrails d’entrée pour applications LLM, avant le modèle

Chaque règle de guardrail porte une étape — input, output, ou both. Une règle input s’exécute contre le texte de la requête au moment où elle arrive, en route vers le modèle en amont : 
caller → [ input guardrail ] → metering → model → [ output guardrail ] → caller
Cet ordre est le point. Une règle d’entrée voit le prompt avant que la passerelle ne pré-consomme du quota, donc un block à cette étape est gratuit — la requête n’atteint jamais le modèle et ne facture jamais. Comparez l’étape output, qui filtre la réponse du modèle après son retour (un block de sortie rembourse plutôt le quota pré-consommé).
Les règles d’entrée filtrent la requête de l’appelant. Si vous utilisez aussi les prompts du registre, le message système injecté est ajouté plus tard dans le routage — donc les règles d’entrée voient les messages que votre application a envoyés, pas le prompt injecté. Les règles de sortie filtrent la réponse dans tous les cas.

​
2. Ce que vous pouvez exécuter à l’étape input

N’importe quel type de règle peut s’exécuter à input. Les raisons les plus courantes de contrôler la requête avant le modèle :

Masquer la PII dans le prompt

Une règle pii avec l’action mask réécrit les entités en balises typées (jane@acme.com → [EMAIL]) afin que le modèle en amont ne voie jamais la valeur brute. Voir PII Shield.

Bloquer les secrets avant qu'ils ne fuient

Une requête transportant une clé API ou un credential cloud est rejetée à la porte — pré-mesure, aucun appel en amont. Voir Bloquer les secrets.

Arrêter les tentatives d'injection

Le preset Bases de l’injection de prompt associe des détecteurs keyword/regex à une règle llm_judge pour l’intention d’injection. Voir Injection de prompt.

Plafonner la taille du prompt

Une règle max_chars rejette un prompt surdimensionné avant qu’il ne facture aucun token. Voir Cost guardrails.
Les sept types de règles — keyword, regex, pii, max_chars, external, llm_judge, grounding — et les cinq actions block, mask, flag, annotate et spotlight s’appliquent tous ici. (spotlight encadre le texte non fiable correspondant dans des délimiteurs afin que le modèle le traite comme des données, pas des instructions — une défense d’injection de prompt à l’étape input ; annotate attache une note sans changer le trafic.) Une exception à connaître : grounding mesure la réponse par rapport aux sources récupérées, donc c’est par nature une vérification à l’étape output. Tout le reste convient naturellement à l’étape input.
Le masquage à l’étape input est actif aujourd’hui — streaming ou non. La passerelle réécrit la requête avant que le modèle ne la voie sur chaque chemin. Le mask de sortie redacte uniquement les réponses non-streaming ; la réécriture de sortie in-stream est sur la feuille de route, donc une règle mask ne redacte pas encore une réponse streaming. Le block de sortie, en revanche, est appliqué dans les deux cas — streaming et non-streaming (voir Couverture du streaming).

​
3. Un exemple concret

Rédigez la règle dans la console (sous votre propre session — la config des guardrails nécessite Developer+), pas avec une clé de relais. Ajoutez une seule règle input à un guardrail nommé secrets-shield : 
{
  "type": "regex",
  "stage": "input",
  "action": "block",
  "pattern": "sk-[A-Za-z0-9]{20,}"
}
Attachez le guardrail à une clé (définissez guardrail_id, ou marquez-le 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": "Debug this: OPENAI_API_KEY=sk-abcdefghij1234567890"}
    ]
  }'
La requête correspond à l’étape input et est rejetée avec une HTTP 400 guardrail_blocked avant que la passerelle ne transmette quoi que ce soit en amont : 
{
  "error": {
    "type": "guardrail_blocked",
    "message": "request blocked by guardrail \"secrets-shield\": regex(...)"
  }
}
Voir l’erreur guardrail_blocked pour la forme complète de la réponse.

​
4. Pourquoi un block d’entrée ne coûte aucun quota

C’est l’avantage structurel d’attraper les choses à l’entrée. Un block à l’étape input se situe avant la pré-consommation, donc :
PropriétéBlock à l’étape input
Statut HTTP400 guardrail_blocked
Quota facturéAucun — se déclenche avant la mesure
Appel en amontJamais effectué
RetryMarqué skip-retry — ré-exécuter bloque à nouveau
Parce que la requête n’atteint jamais un canal, un block d’entrée est marqué skip-retry : ré-exécuter le même prompt contre un autre canal ne ferait que bloquer à nouveau et gaspiller des efforts. L’étape output diffère — un block là-bas rembourse le quota que la passerelle a déjà pré-consommé. Même 400, comptabilité différente.

​
5. Résolution et fallback

Une règle à l’étape input ne s’exécute que si un guardrail se résout réellement sur la requête. La résolution est explicite :
  1. Le guardrail_id explicite de la clé, s’il existe et est activé.
  2. Sinon le guardrail par défaut de l’espace de travail.
  3. Sinon aucun — la requête est identique octet pour octet à un espace de travail sans politique.
Un attachement explicite ne retombe jamais silencieusement. Désactiver un guardrail attaché est l’interrupteur d’arrêt — il ne bascule pas vers le défaut de l’espace de travail. (Les politiques firewall se comportent différemment ici ; voir Guardrails vs. firewall.)

​
6. Prouvez-le avant de livrer

N’attachez pas une règle d’entrée bloquante au trafic réel par confiance. Deux façons de valider d’abord :
Ouvrez l’onglet Test dans l’éditeur de guardrail, collez un échantillon, choisissez l’étape input, et lancez. Le sandbox évalue la politique actuelle localement — aucun appel en amont, aucun quota — et renvoie le verdict plus (pour les règles mask) le texte rendu. Voir Test & éval.
Mettez l’action sur flag d’abord. Un flag ne change rien au trafic — il enregistre seulement une correspondance — afin que vous puissiez mesurer à quelle fréquence une règle se déclencherait sur de vraies entrées avant de la basculer sur block. Voir Ajuster les faux positifs.
Chaque règle qui se déclenche enregistre une correspondance — type, action, étape et une chaîne de détail. La sous-chaîne correspondante n’est enregistrée que lorsque Log raw content est activé (désactivé par défaut). Voir le flux des correspondances et Journalisation & confidentialité.

​
7. Où aller ensuite

L’étape input empêche les mauvaises entrées d’atteindre le modèle. Pour contrôler la réponse du modèle, associez-la à l’étape output ; pour gouverner les appels d’outils d’un agent, utilisez le firewall. Lisez la référence Guardrails pour le moteur complet, ou le démarrage rapide sécurité pour câbler ensemble les guardrails d’entrée et le firewall en référentiel d’agent.