1. Ce que le journal de correspondances enregistre
Chaque règle déclenchée écrit une correspondance dans un flux à portée d’espace de travail (GET /api/guardrail/match, ouvert à tout Member). Le flux est
séparé de votre journal de requête — il ne stocke que ce qu’un guardrail a fait,
pas le corps complet de la requête. Chaque correspondance enregistre :
Le verdict
Le verdict
rule_type (keyword, regex, pii, max_chars, external,
llm_judge, grounding), l’action effective (block / mask / flag /
annotate / spotlight), et l’stage (input ou output) — afin que vous
puissiez dire instantanément ce qui s’est déclenché et ce que ça a fait.Où elle s'est déclenchée
Où elle s'est déclenchée
guardrail_name, le rule_label déclencheur, plus le contexte de la
requête : model_name, le token sur lequel elle a circulé, l’ip de
l’appelant, et le request_id qui rejoint votre journal de requête.Une chaîne de détail
Une chaîne de détail
detail — la courte note lisible par un humain du moteur pour la violation
(par exemple quelle entité ou quel motif s’est déclenché), toujours
enregistrée.La sous-chaîne correspondante — uniquement si vous optez
La sous-chaîne correspondante — uniquement si vous optez
matched n’est rempli que lorsque le toggle Log raw content du
guardrail est activé. Il est désactivé par défaut, donc par défaut le flux
vous dit qu’une règle s’est déclenchée et pourquoi, mais ne stocke jamais la
chaîne sensible elle-même.2. Lister et filtrer le journal de correspondances
La vue de liste par défaut est paginée par curseur, du plus récent au plus ancien, et à portée de votre espace de travail. Affinez-la avec des paramètres de requête — la console les expose comme des puces de filtre :| Paramètre | Filtre par |
|---|---|
guardrail_id, rule_type, action, stage | Le verdict |
token_id, model_name, request_id | Le contexte de la requête |
days / start_at + end_at, hide_fp | Fenêtre et état de faux positif |
Les routes de gestion comme
/api/guardrail/* s’authentifient avec votre
session / token d’accès de console, pas une clé de relais. Les clés
sk-orca-... ne servent qu’aux appels de modèle /v1/*. Au quotidien, vous
lirez le flux directement depuis l’onglet Matches sur la page Guardrails.3. Grouper par requête
Une seule requête peut déclencher plusieurs règles à la fois — un mask de PII d’entrée et un plafond de longueur max, disons. La vue groupée (GET /api/guardrail/match/grouped, Member) collapse les correspondances par
request_id afin que vous voyiez une ligne par requête fautive avec ses
correspondances repliées inline, au lieu de faire défiler cinq lignes pour le
même appel. Réglez combien de correspondances s’affichent inline par groupe avec
inline_limit (défaut 5).
4. Stats et la bande de tendance
L’endpoint de stats (GET /api/guardrail/match/stats, Member) alimente la bande
de compte et le graphique sur l’onglet Matches — totaux sur une fenêtre days,
optionnellement ventilés avec group_by :
group_by | Ventilation |
|---|---|
| (omis) | Totaux uniquement |
rule_type | Quels types de règles se déclenchent le plus |
guardrail_id | Quel guardrail représente l’activité |
request_id pour obtenir un compte de correspondances en temps constant
pour une requête (utilisé par le cross-link du journal de requête). C’est là que
vivent l’usage par guardrail, le mix d’actions et le taux de faux positifs —
tranchez-le plutôt que de paginer la liste brute.
5. Exporter pour une piste d’audit
Quand vous avez besoin des correspondances hors de la console — un pack de preuves, un tableur, un SIEM en aval —GET /api/guardrail/match/export
(Member) stream votre ensemble de filtres actuel en CSV ou JSON :
6. Trier les faux positifs
Toute correspondance n’est pas un vrai hit. Quand une règle se déclenche sur du trafic bénin, un Admin de l’espace de travail peut marquer la correspondance comme faux positif (POST /api/guardrail/match/:id/mark-fp) ; l’inverse
DELETE /api/guardrail/match/:id/mark-fp la dé-marque. Le marquage est
réservé à l’Admin même si le reste du flux est lisible par les Member — le
triage est une action privilégiée.
Marquer un faux positif fait deux choses : il tague la correspondance (afin que
hide_fp=true la filtre hors du flux) et mémorise le finding afin que la même
règle sur le même contenu soit sautée sur les requêtes futures. Dé-marquez pour
restaurer l’application. Pour le workflow plus large d’ajustement d’une règle
bruyante, voir
Ajuster les faux positifs.
Une correspondance est une donnée de diagnostic, pas une décision
d’application. Le fait qu’une requête ait été bloquée, masquée ou simplement
signalée est déjà réglé par l’action au moment
de la requête — le flux est l’enregistrement après coup. Marquer un faux positif
change le comportement futur, jamais l’appel qui s’est déjà produit.
7. D’où viennent les correspondances
Les correspondances sont produites par le moteur de guardrail sur le chemin de relais, donc le flux reflète exactement ce que vos politiques attachées ont fait :- Les correspondances à l’étape input enregistrent ce que la passerelle a filtré avant que le modèle ne le voie — voir Étape input.
- Les correspondances à l’étape output enregistrent ce qu’elle a filtré sur la réponse — voir Étape output.
- Une requête bloquée apparaît aussi comme une
HTTP 400
guardrail_blockedpour l’appelant ; la correspondance en est l’enregistrement côté serveur.
8. Liés
Référence Guardrails
Le moteur complet : types de règles, étapes, actions, presets, harnais
d’évaluation.
Journalisation & confidentialité
Le toggle Log raw content et ce que le flux stocke — et ne stocke pas.
Ajuster les faux positifs
Utilisez le flux pour trouver et faire taire les règles bruyantes sans
affaiblir la politique.
Versioning
Diffez et rétablissez un guardrail quand le flux montre qu’un changement a
raté.
