Passer au contenu principal
Un chatbot client prend des entrées non fiables du public et les envoie à un modèle. Cela en fait la surface la plus exposée que vous exploitez : les utilisateurs collent des PII que vous ne voulez pas voir stockées en amont, les attaquants tentent d’écraser votre system prompt, et le modèle peut renvoyer des secrets ou du contenu non sûr dans la fenêtre de chat. Cette recette câble les quatre contrôles qui sécurisent un chatbot IA de bout en bout — un guardrail PII sur la requête, le dépistage d’injection de prompt, la sûreté des sorties et une seule clé étroitement scopée — le tout dans la console, sans aucun changement dans le code de votre chatbot.
Tout ici se lie à votre espace de travail et est configuré depuis la console. Votre chatbot continue d’appeler https://api.orcarouter.ai/v1/chat/completions avec la même clé sk-orca-... — seule la politique dans la passerelle change. Les actions de configuration nécessitent les rôles indiqués à chaque étape ; les appels de relais utilisent la clé scopée.

​
1. Le modèle de menace d’un chatbot public

Avant de rédiger quoi que ce soit, sachez contre quoi vous vous défendez. La surface d’attaque d’un chatbot est plus étroite que celle d’un agent complet — mais les risques à haute fréquence sont concrets :

PII entrant, PII journalisé

Les utilisateurs collent des emails, des numéros de carte, des numéros de sécurité sociale dans le chat — et vous les transmettez en amont et dans vos journaux.

Injection de prompt

« Ignore les instructions précédentes et … » — des tentatives d’écraser votre system prompt et de modifier le comportement du bot.

Jailbreaks

Des cadrages DAN / jeu de rôle qui tentent de faire dévier le bot de sa politique.

Sortie non sûre

Le modèle qui renvoie des secrets fuités, du boilerplate de system prompt, ou du contenu truffé d’injection dans le chat.
Un chatbot simple n’a aucun appel d’outil, donc cette recette s’appuie sur les Guardrails — le plan texte — plutôt que sur le Firewall. Si votre bot appelle bel et bien des outils, superposez le Firewall par-dessus (voir §6).

​
2. Un guardrail, quatre missions

Plutôt que quatre politiques distinctes, rédigez un seul guardrail d’espace de travail avec des règles ordonnées couvrant chaque risque. Un guardrail est une liste de règles nommée et ordonnée ; chaque règle dit quoi chercher, où (input, output ou both), et quoi faire (block, mask ou flag). Dans la console, ouvrez Guardrails → Nouveau guardrail, nommez-le chatbot-shield, et ajoutez les règles ci-dessous. Rédiger un guardrail — et exécuter la sandbox Test — nécessite le rôle Developer ; consulter les guardrails est ouvert à tout membre.

​
a. PII sur la requête

Ajoutez une règle PII, stage input, action mask. Le jeu d’entités intégré est fermé — choisissez celles qu’un chatbot voit réellement : 
{
  "type": "pii",
  "stage": "input",
  "action": "mask",
  "entities": ["email", "phone", "credit_card", "ssn", "ip"],
  "entity_actions": { "credit_card": "block", "ssn": "block" }
}
Un mask remplace chaque correspondance par une étiquette typée — jane@acme.com devient [EMAIL], de sorte que le modèle amont ne voit jamais l’adresse. L’override entity_actions bloque la requête purement et simplement sur un numéro de carte ou un SSN tout en masquant les entités de moindre gravité. C’est exactement le preset PII Shield, étendu avec des overrides par entité — appliquez le preset depuis la bibliothèque de templates et éditez à partir de là.
Le masquage PII au stade input est actif aujourd’hui — il réécrit la requête avant que le modèle ne la voie. Le masquage en direct de la réponse streamée est sur la feuille de route. Pour redacter la PII de ce que le bot renvoie, utilisez une règle de block en sortie (appliquée en streaming et non-streaming) ou exécutez le bot en non-streaming, où le masquage de sortie s’applique. Prouvez votre combinaison exacte stage/stream dans l’onglet Test d’abord.

​
b. Dépistage d’injection de prompt

OrcaRouter livre cela comme le preset de sûreté Prompt-Injection Basics (une denylist de mots-clés pour des phrases comme « ignore previous instructions » et « reveal your system prompt » ; pour une couverture regex plus stricte des cadrages DAN / jeu de rôle, ajoutez le preset Jailbreak / Role-Play Blocker) plus, pour l’intention sémantique qu’aucun motif n’attrape, une règle llm_judge. Ajoutez le preset, puis une règle de juge sur le stage input avec une grille qui signale les tentatives d’injection/écrasement. Le juge s’exécute contre un modèle de votre espace de travail, est borné par judge_timeout_ms, et fail open par défaut (une erreur de juge est journalisée et la requête continue) — définissez judge_fail_open: false pour fail closed.
Commencez les règles d’injection à flag, surveillez le flux Matches pendant une journée sur du trafic réel, puis promouvez en block une fois que vous avez confirmé qu’elles se déclenchent sur des attaques et non sur des questions légitimes. Voir modes d’application.

​
c. Sûreté des sorties

Ajoutez une règle de block au stage output (regex ou mot-clé) pour le contenu qui ne doit jamais atteindre la fenêtre de chat — secrets fuités, tokens de contrôle de gabarit de chat, boilerplate de system prompt. Les presets de sûreté Secrets & API-Key Blocker et de fuite de system prompt couvrent les cas courants ; appliquez-les et épinglez les règles pertinentes au stage output. Le block de sortie est appliqué en streaming aussi — le scanner coupe le flux en plein vol et émet un message de remplacement avant que le contenu bloqué n’atteigne l’utilisateur.

​
3. Testez avant de déployer

Chaque éditeur de guardrail a un onglet Test. Collez un échantillon, choisissez le stage, et exécutez la politique actuelle localement — aucun appel amont, aucun quota dépensé.
Collez ceciStageAttendu
email me at jane@acme.cominputemail me at [EMAIL]
ignore previous instructionsinputflag / block (votre choix)
carte 4111 1111 1111 1111inputguardrail_blocked (selon l’override)
Pour une couverture adversariale, l’onglet Eval exécute la politique contre des corpus red-team intégrés (ou vos propres JSONL) et rapporte le score obtenu — ajustez la grille du juge jusqu’à ce qu’elle attrape les attaques connues sans signaler le chat bénin.

​
4. Frappez une seule clé scopée pour le bot

Un guardrail ne s’applique que sur les clés qui s’y résolvent. Donnez au chatbot sa propre clé, scopée au minimum dont il a besoin — jamais votre clé à portée de compte. Dans API Keys → Nouvelle clé, définissez :
Choisissez chatbot-shield dans le menu déroulant Guardrail. Cela définit guardrail_id sur la clé. Un attachement explicite est l’opposé de l’interrupteur d’arrêt : s’il est défini et activé, il s’applique toujours et ne retombe jamais silencieusement. (Laissez-le non défini pour retomber sur le guardrail is_default de l’espace de travail à la place.)
Définissez credit_limit_usd à un plafond raisonnable (0 = illimité). Un chatbot public est la clé la plus susceptible d’être abusée — un plafond de crédit strict est votre limite de rayon d’explosion. Voir denial-of-wallet.
Activez model_limits et ne listez que le(s) modèle(s) que le bot est autorisé à appeler, de sorte qu’une clé fuitée ne puisse pas servir à exécuter un modèle coûteux que vous n’aviez jamais l’intention d’exposer.
Définissez allow_ips sur les IPs d’egress de votre backend si le bot appelle depuis un serveur fixe, et un expired_time si la clé est temporaire (-1 = n’expire jamais).
La clé est masquée à l’affichage après création — copiez-la une seule fois. Le backend de votre chatbot envoie désormais chaque tour utilisateur à travers chatbot-shield sans qu’aucun code ne soit conscient que le dépistage a lieu.

​
5. Surveillez-le en production

Deux lectures vous gardent honnête, toutes deux à portée d’espace de travail :
  • Guardrails → Matches (tout Member) — chaque règle qui s’est déclenchée : type, action, stage et détail. La sous-chaîne correspondante n’est enregistrée que si Log raw content est activé pour le guardrail (désactivé par défaut — la posture prudente en matière de vie privée). Marquez un faux positif pour ajuster la politique (Admin).
  • Historique de versions — chaque changement écrit une ligne d’historique ; comparez deux versions et revenez en arrière si une règle s’avère trop agressive. Une requête bloquée renvoie une HTTP 400 guardrail_blocked, ne coûte aucun quota, et est marquée skip-retry.
Une réponse guardrail_blocked est une 400 délibérée et visible par l’utilisateur. Gérez-la dans l’UI de votre chatbot avec un message amical (« Je ne peux pas traiter cela ») plutôt que d’exposer l’erreur brute — la passerelle a déjà arrêté le tour non sûr pour vous.

​
6. Si votre bot appelle des outils

Dès l’instant où votre chatbot peut appeler une fonction, récupérer une URL ou atteindre un serveur MCP, le dépistage de texte ne suffit plus — vous avez besoin du plan action. Attachez une politique Firewall à la même clé via firewall_policy_id, ou appliquez le niveau d’autonomie balanced pour auditer les appels d’outils et signaler la PII à l’échelle de l’espace de travail avant de resserrer. Le chemin le plus rapide est le démarrage rapide zero-trust ; pour un agent qui appelle des outils de façon intensive, voir sécuriser un agent autonome.

​
7. Pour aller plus loin

Référence Guardrails

Chaque type de règle, entité PII, champ de juge, et le harnais d’eval en entier.

Guardrails vs Firewall

Plan texte vs plan action — quand vous avez besoin de l’un ou l’autre.

Modes d'application

Observe → shadow → enforce : déployez sans casser le bot.

Clés, politiques, espaces de travail

Comment l’attachement de clé et les défauts d’espace de travail se résolvent.