Passer au contenu principal
Un guardrail trop zélé est pire que pas de guardrail — votre équipe apprend à ignorer le flux Matches, ou vous relâchez la règle et perdez la prise que vous vouliez réellement. OrcaRouter vous donne une voie médiane précise : marquez une seule correspondance comme faux positif, et le moteur mémorise ce finding et le saute sur les requêtes futures — sans toucher à la règle, relâcher le motif ou livrer un changement de SDK. C’est une page d’atterrissage ciblée sur le workflow des faux positifs. Pour le moteur de guardrail complet — chaque type de règle, champ et route — voir la référence Guardrails.
Chaque étape ici est une action de console sur la passerelle hébergée (api.orcarouter.ai). Vous triez les correspondances sous votre propre session ; seul l’appel /v1/* final utilise une clé de relais sk-orca-.... Marquer une correspondance comme faux positif nécessite le rôle Admin de l’espace de travail ; lire le flux Matches et la liste de suppressions résultante est ouvert à chaque membre.

​
1. Réduire les faux positifs des guardrails sans affaiblir la règle

L’instinct quand une règle se déclenche trop est de la relâcher — élargir une exclusion regex, retirer une entité, basculer block en flag. Cela échange un faux positif contre un trou dans la politique. La suppression par marquage-faux-positif est l’alternative chirurgicale :

Supprimer un finding

Faites taire la correspondance exacte qui a raté — une sous-chaîne spécifique sous une règle spécifique — pas toute la règle. Le prochain hit véritablement sensible se déclenche toujours.

Aucune édition de règle, aucun redéploiement

La suppression vit dans la passerelle comme mémoire d’espace de travail. La règle reste exactement telle qu’écrite ; votre application continue d’appeler /v1/* inchangée.

Mémoire à l'échelle de l'espace de travail

Un Admin la marque une fois ; la suppression est dédupliquée à travers l’espace de travail, donc le trafic de chaque membre en bénéficie — aucun fan-out par clé.

Réversible

Dé-marquez la correspondance (ou supprimez la suppression) et le finding se déclenche de nouveau à la prochaine requête. Rien n’est détruit.
La suppression est pour un finding que vous avez jugé bénin. Si toute une règle est mal calibrée — mauvaise forme, mauvaise étape — corrigez la règle et prouvez-la dans le harnais d’évaluation au lieu de faire taire correspondance après correspondance.

​
2. Comment une correspondance devient une suppression

Chaque règle qui se déclenche enregistre une correspondance dans le flux des correspondances de l’espace de travail — type de règle, action, étape et une chaîne de détail. Quand vous marquez l’une de ces correspondances comme faux positif, la passerelle dérive une empreinte stable pour le finding et l’écrit dans la liste de suppressions de l’espace de travail. À chaque requête future, le moteur vérifie l’empreinte de chaque finding contre cette liste et saute un finding supprimé avant qu’il ne puisse bloquer, masquer ou signaler. Deux types de finding produisent une empreinte :
Un finding CVE / SBOM est déjà livré avec une identité stable — l’identité de l’avis ou du composant voyage avec le finding. Supprimer un fait taire ce CVE/composant exact, et lui seul. C’est le cas natif pour lequel le store de suppressions a été construit.
Keyword, regex, PII et les autres types de règles déterministes ne portent pas d’identité propre, donc la passerelle en synthétise une à partir de données identiques côté écriture (votre clic mark-FP) et côté application (la prochaine requête) : le guardrail, l’identité de correspondance de la règle, et — quand la capture brute est activée — les sous-chaînes correspondantes elles-mêmes.
La précision de l’empreinte synthétique dépend de Log raw content, qui est désactivé par défaut. Avec la capture activée, l’empreinte se base sur la sous-chaîne correspondante exacte, donc supprimer ORD-48291507 fait taire ce numéro de commande et rien d’autre. Avec la capture désactivée, il n’y a pas de sous-chaîne sur laquelle se baser, donc la suppression bascule vers un mute au niveau de la règle — elle fait taire cette seule règle (à cette étape) pour l’espace de travail. Le fallback ne va jamais au-delà de la règle dont il provient. Voir Journalisation & confidentialité.

​
3. Un exemple concret

Disons que vous exécutez une règle regex qui masque les numéros de commande internes de forme ORD- plus huit chiffres. Un ticket de support cite légitimement ORD-48291507 d’une façon que vous avez décidé d’autoriser à passer. Vous ne voulez pas affaiblir la règle — vous voulez juste que ce seul numéro cesse de se déclencher.
1

Ouvrir le flux Matches

Dans la console, ouvrez Guardrails → Matches. Filtrez par guardrail et type de règle pour trouver la ligne du hit ORD-48291507. (Pour voir la sous-chaîne littérale, Log raw content du guardrail doit avoir été activé quand la correspondance a été enregistrée — il est désactivé par défaut.)
2

La marquer comme faux positif

Ouvrez le détail de la correspondance et choisissez Mark as false positive. En tant qu’Admin de l’espace de travail, cela tamponne la correspondance et reflète une suppression d’espace de travail basée sur l’empreinte du finding.
3

Confirmer qu'elle est supprimée

Ouvrez la liste Suppressions — la nouvelle entrée apparaît, étiquetée avec le guardrail et la règle dont elle provient et la raison “Marked as false positive from Matches”. Chaque membre de l’espace de travail peut lire cette liste.
4

Envoyer la même requête de nouveau

En utilisant votre clé de relais, appelez OrcaRouter exactement comme avant — aucun nouvel en-tête, aucun changement de SDK :
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": "Status of order ORD-48291507?"}
    ]
  }'
Le finding supprimé est sauté — ORD-48291507 passe — tandis que tout autre numéro de commande correspond toujours et est masqué comme avant.

​
4. Suppression vs. les alternatives

La suppression est l’une des quatre façons de faire taire une règle bruyante. Choisissez la plus étroite qui convient :
ApprocheCe qu’elle changeQuand y recourir
Mark FPUn finding (ou une règle, capture désactivée)Un hit bénin spécifique ; la règle est par ailleurs juste
Modifier la règleLa correspondance elle-mêmeMauvaise forme/étape — corrigez-la, puis ré-évaluez
Action flagObservation seule, aucun blocageUne nouvelle règle à laquelle vous ne faites pas encore confiance
Harnais d’évaluationRien en direct — mesureProuver la précision avant de livrer
Ne masquez pas une règle systématiquement fausse en marquant FP après FP. Si vous supprimez la même forme à répétition, la règle est mal calibrée — ancrez la regex, resserrez la liste de mots-clés, ou choisissez une entité PII plus serrée, et vérifiez avec une exécution d’éval.

​
5. Inverser une suppression

Rien ici n’est à sens unique :
  • Dé-marquer la correspondance — la même action Admin, inversée, retire le tampon FP de la correspondance et (quand aucune autre correspondance marquée FP ne s’y mappe encore) supprime la suppression. Le finding se déclenche de nouveau à la prochaine requête.
  • Supprimer la suppression directement — depuis la liste Suppressions, une action Developer+ retire l’entrée. Même effet : le finding est de nouveau actif.
Parce que les suppressions sont une mémoire d’espace de travail, en inverser une restaure la prise pour le trafic de chaque membre d’un coup — comme la façon dont la marquer l’a supprimée pour tout le monde.

​
6. Surface API

Ce sont des routes de console, authentifiées par votre session — pas des clés de relais. Contrôlez chaque action par rôle : marquer une correspondance FP est Admin ; les lectures de suppressions sont Member ; les écritures de suppressions sont Developer+.
Méthode & cheminRôleObjectif
GET /api/guardrail/matchMemberLister les correspondances à trier.
POST /api/guardrail/match/:id/mark-fpAdminMarquer une correspondance comme faux positif (reflète une suppression).
DELETE /api/guardrail/match/:id/mark-fpAdminDé-marquer — restaurer le finding.
GET /api/guardrail/suppressionsMemberLister les suppressions actives de l’espace de travail.
POST /api/guardrail/suppressionsDeveloper+Ajouter une suppression directement.
DELETE /api/guardrail/suppressions/:idDeveloper+Retirer une suppression.
Les endpoints mark-FP sont rate-limited — c’est une action de triage délibérée et à faible volume, pas une API en masse. Recourez au harnais d’évaluation, pas à une boucle d’appels mark-FP, quand vous ajustez toute une politique.

​
7. Où aller ensuite

Flux des correspondances

Où chaque règle déclenchée atterrit — l’endroit d’où vous triez avant de marquer quoi que ce soit.

Test & éval

Prouvez la précision d’une règle contre un corpus avant de la livrer — le correctif systématique quand la suppression traite un symptôme.

Journalisation & confidentialité

Comment Log raw content contrôle si la suppression se base sur la sous-chaîne exacte ou bascule vers un mute au niveau de la règle.

Référence Guardrails

Le moteur complet — chaque type de règle, action et route.
La suppression gouverne les findings de contenu. Pour faire taire une règle de firewall d’agent bruyante — une correspondance d’outil que vous avez jugée sûre — c’est une surface séparée ; voir le Firewall et son flux d’anomalies. Pour comprendre où les guardrails et le firewall se divisent, lisez Guardrails vs Firewall.