Zum Hauptinhalt springen
Ein Guardrail, das zu eifrig ist, ist schlimmer als gar kein Guardrail — Ihr Team lernt, den Matches-Feed zu ignorieren, oder Sie lockern die Regel und verlieren den Fang, den Sie eigentlich wollten. OrcaRouter gibt Ihnen einen präzisen Mittelweg: markieren Sie einen einzelnen Match als False Positive, und die Engine merkt sich jenes Finding und überspringt es bei zukünftigen Requests — ohne die Regel zu berühren, das Muster zu lockern oder eine SDK-Änderung auszuliefern. Dies ist eine fokussierte Landingpage für den False-Positive-Workflow. Die vollständige Guardrail-Engine — jeder Regeltyp, jedes Feld und jede Route — finden Sie in der Guardrails-Referenz.
Jeder Schritt hier ist eine Konsolen-Aktion auf dem gehosteten Gateway (api.orcarouter.ai). Sie triagieren Matches in Ihrer eigenen Session; nur der finale /v1/*-Aufruf nutzt einen sk-orca-...-Relay-Key. Das Markieren eines Matches als False Positive erfordert die Workspace-Rolle Admin; das Lesen des Matches-Feeds und der resultierenden Suppression-Liste ist für jedes Member offen.

​
1. Guardrail-False-Positives reduzieren, ohne die Regel zu schwächen

Der Instinkt, wenn eine Regel über-feuert, ist, sie zu lockern — eine Regex-Ausschluss erweitern, eine Entity fallen lassen, block auf flag umlegen. Das tauscht einen False Positive gegen ein Loch in der Policy. Die Mark-False-Positive-Suppression ist die chirurgische Alternative:

Ein Finding unterdrücken

Stummschalten Sie den exakten Match, der danebenging — einen bestimmten Substring unter einer bestimmten Regel — nicht die ganze Regel. Der nächste wirklich sensible Treffer feuert weiterhin.

Keine Regelbearbeitung, kein Redeploy

Die Suppression lebt im Gateway als Workspace-Speicher. Die Regel bleibt genau wie geschrieben; Ihre App ruft /v1/* unverändert weiter auf.

Workspace-weiter Speicher

Ein Admin markiert es einmal; die Suppression wird über den Workspace dedupliziert, sodass der Traffic jedes Members profitiert — kein Pro-Key-Fan-out.

Umkehrbar

Entmarkieren Sie den Match (oder löschen Sie die Suppression), und das Finding feuert beim nächsten Request wieder. Nichts wird zerstört.
Suppression ist für ein Finding, das Sie als gutartig beurteilt haben. Wenn eine ganze Regel fehlkalibriert ist — falsche Form, falsche Stage — korrigieren Sie die Regel und beweisen Sie es im Eval-Harness, statt Match um Match stummzuschalten.

​
2. Wie ein Match zu einer Suppression wird

Jede Regel, die feuert, zeichnet einen Match im Workspace- Matches-Feed auf — Regeltyp, Action, Stage und einen Detail-String. Wenn Sie einen jener Matches als False Positive markieren, leitet das Gateway einen stabilen Fingerprint für das Finding ab und schreibt ihn in die Suppression-Liste des Workspaces. Bei jedem zukünftigen Request prüft die Engine den Fingerprint jedes Findings gegen jene Liste und überspringt ein unterdrücktes, bevor es blockieren, maskieren oder markieren kann. Zwei Arten von Findings erzeugen einen Fingerprint:
Ein CVE-/SBOM-Finding wird bereits mit einer stabilen Identität ausgeliefert — die Advisory- oder Komponentenidentität reist mit dem Finding. Eines zu unterdrücken schaltet genau jenes CVE/jene Komponente stumm, und nur dieses eine. Das ist der native Fall, für den der Suppression-Store gebaut wurde.
Keyword, Regex, PII und die anderen deterministischen Regeltypen tragen keine eigene Identität, daher synthetisiert das Gateway eine aus Daten, die auf der Schreibseite (Ihr Mark-FP-Klick) und der Durchsetzungsseite (der nächste Request) identisch sind: das Guardrail, die Match-Identität der Regel und — wenn die Rohinhalt-Erfassung aktiviert ist — die getroffenen Substrings selbst.
Die Präzision des synthetischen Fingerprints hängt von Log raw content ab, was standardmäßig deaktiviert ist. Mit aktivierter Erfassung keyt der Fingerprint auf den exakten getroffenen Substring, sodass das Unterdrücken von ORD-48291507 jene Bestellnummer und nichts anderes stummschaltet. Mit deaktivierter Erfassung gibt es keinen Substring zum Keyen, sodass die Suppression auf eine regel-stufige Stummschaltung zurückfällt — sie schaltet jene eine Regel (an jener Stage) für den Workspace stumm. Der Fallback reicht nie über die Regel hinaus, von der er kam. Siehe Logging & Datenschutz.

​
3. Ein konkretes Beispiel

Angenommen, Sie betreiben eine regex-Regel, die interne Bestellnummern maskiert, geformt wie ORD- plus acht Ziffern. Ein Support-Ticket zitiert legitim ORD-48291507 auf eine Weise, die Sie als okay zum Durchlassen entschieden haben. Sie wollen die Regel nicht schwächen — Sie wollen nur, dass diese eine Nummer aufhört zu feuern.
1

Den Matches-Feed öffnen

Öffnen Sie in der Konsole Guardrails → Matches. Filtern Sie nach Guardrail und Regeltyp, um die Zeile für den ORD-48291507-Treffer zu finden. (Um den wörtlichen Substring zu sehen, muss Log raw content des Guardrails aktiviert gewesen sein, als der Match aufgezeichnet wurde — es ist standardmäßig deaktiviert.)
2

Als False Positive markieren

Öffnen Sie das Match-Detail und wählen Sie Mark as false positive. Als Workspace-Admin stempelt dies den Match und spiegelt eine Workspace-Suppression, die auf den Fingerprint des Findings gekeyt ist.
3

Bestätigen, dass es unterdrückt ist

Öffnen Sie die Suppressions-Liste — der neue Eintrag erscheint, beschriftet mit dem Guardrail und der Regel, von der er kam, und dem Grund „Marked as false positive from Matches”. Jedes Member des Workspaces kann diese Liste lesen.
4

Denselben Request erneut senden

Rufen Sie mit Ihrem Relay-Key OrcaRouter genau wie zuvor auf — keine neuen Header, keine SDK-Änderung:
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?"}
    ]
  }'
Das unterdrückte Finding wird übersprungen — ORD-48291507 geht durch — während jede andere Bestellnummer weiterhin trifft und wie zuvor maskiert wird.

​
4. Suppression vs. die Alternativen

Suppression ist einer von vier Wegen, eine laute Regel zu beruhigen. Wählen Sie den schmalsten passenden:
AnsatzWas er ändertWann man dazu greift
Mark FPEin Finding (oder eine Regel, Erfassung aus)Ein bestimmter gutartiger Treffer; Regel ist ansonsten richtig
Die Regel bearbeitenDas Matching selbstFalsche Form/Stage — beheben, dann neu evaluieren
flag-ActionNur beobachten, kein BlockierenEine neue Regel, der Sie noch nicht vertrauen
Eval-HarnessNichts live — misstPrecision beweisen, bevor Sie ausliefern
Übertünchen Sie keine systematisch falsche Regel, indem Sie FP um FP markieren. Wenn Sie dieselbe Form wiederholt unterdrücken, ist die Regel fehlkalibriert — verankern Sie das Regex, verengen Sie die Keyword-Liste oder wählen Sie eine engere PII-Entity und verifizieren Sie mit einem Eval-Lauf.

​
5. Eine Suppression umkehren

Nichts hier ist einseitig:
  • Den Match entmarkieren — dieselbe Admin-Aktion, umgekehrt, entfernt den FP-Stempel des Matches und (wenn kein anderer FP-markierter Match noch darauf abbildet) verwirft die Suppression. Das Finding feuert beim nächsten Request wieder.
  • Die Suppression direkt löschen — aus der Suppressions-Liste entfernt eine Developer+-Aktion den Eintrag. Gleicher Effekt: Das Finding ist wieder live.
Weil Suppressions Workspace-Speicher sind, stellt das Umkehren einer den Fang für den Traffic jedes Members auf einmal wieder her — genauso, wie das Markieren ihn für alle unterdrückte.

​
6. API-Oberfläche

Dies sind Konsolen-Routen, authentifiziert durch Ihre Session — nicht Relay-Keys. Schützen Sie jede Aktion rollenbasiert: Einen Match FP zu markieren ist Admin; Suppression-Lesezugriffe sind Member; Suppression-Schreibzugriffe sind Developer+.
Methode & PfadRolleZweck
GET /api/guardrail/matchMemberMatches zum Triagieren auflisten.
POST /api/guardrail/match/:id/mark-fpAdminEinen Match als False Positive markieren (spiegelt eine Suppression).
DELETE /api/guardrail/match/:id/mark-fpAdminEntmarkieren — das Finding wiederherstellen.
GET /api/guardrail/suppressionsMemberDie aktiven Suppressions des Workspaces auflisten.
POST /api/guardrail/suppressionsDeveloper+Eine Suppression direkt hinzufügen.
DELETE /api/guardrail/suppressions/:idDeveloper+Eine Suppression entfernen.
Die Mark-FP-Endpunkte sind rate-limitiert — sie sind eine bewusste, volumenarme Triage-Aktion, keine Bulk-API. Greifen Sie zum Eval-Harness, nicht zu einer Schleife von Mark-FP-Aufrufen, wenn Sie eine ganze Policy justieren.

​
7. Wie es weitergeht

Matches-Feed

Wo jede gefeuerte Regel landet — der Ort, von dem aus Sie triagieren, bevor Sie irgendetwas markieren.

Testing & Eval

Beweisen Sie die Precision einer Regel gegen ein Korpus, bevor Sie sie ausliefern — der systematische Fix, wenn Suppression ein Symptom behandelt.

Logging & Datenschutz

Wie Log raw content steuert, ob die Suppression auf den exakten Substring keyt oder auf eine regel-stufige Stummschaltung zurückfällt.

Guardrails-Referenz

Die vollständige Engine — jeder Regeltyp, jede Action und jede Route.
Suppression steuert Content-Findings. Um eine laute Agent-Firewall-Regel zu beruhigen — einen Tool-Match, den Sie als sicher beurteilt haben — das ist eine separate Oberfläche; siehe die Firewall und ihren Anomalie-Feed. Um zu verstehen, wo Guardrails und die Firewall sich teilen, lesen Sie Guardrails vs. Firewall.