Zum Hauptinhalt springen
Wenn Ihre App streamt, brauchen Sie eine klare Antwort, bevor Sie einer Content-Policy vertrauen: was tatsächlich auf einer SSE-Response durchgesetzt wird. Ein Guardrail, das eine ganze Antwort prüft, ist leicht zu durchdenken; ein Guardrail, das auf Deltas handeln muss, während sie zum Browser geflusht werden, nicht. Diese Seite ist die Streaming-Guardrail-Abdeckungs-Matrix — jede Action, über die Input- und Output-Stages, auf streamendem und nicht-streamendem Traffic — geschrieben, um präzise zu sein, wie sich jede Zelle auf einem Live-Stream verhält. Für die vollständige Engine — jeder Regeltyp, jedes Feld und jede Route — siehe Guardrails. Für die Mechanik, wie ein Stream unterbrochen wird, siehe Stream-sichere Regeln.

​
1. Die Streaming-Guardrail-Abdeckungsfrage

Eine Guardrail-Regel trägt eine Stage (input, output oder both) und eine Action — eine von fünf: block, mask, flag, annotate oder spotlight. Die Stage entscheidet, wann das Gateway sie ausführt; die Action entscheidet, was sie tut. Der einzige Ort, an dem Streaming die Form der Antwort ändert, ist die Output-Stage — weil das die einzige Stage ist, an der das Gateway Bytes an Ihren Client weiterleitet, sobald sie ankommen, ohne die Chance, zuerst die ganze Payload zu halten. Die Matrix hat also zwei Zellen, in denen Streaming eine Rolle spielt, und sie verhalten sich unterschiedlich: Output-block wird auf einem Stream vollständig durchgesetzt (der Scanner unterbricht ihn), aber Output-mask wird nur auf nicht-streamenden Antworten durchgesetzt. Auf einer streamenden Antwort erkennt der Scanner den Treffer weiterhin und kann auf einer Block-Entscheidung handeln, aber er schreibt den maskierten Text heute nicht in den Stream um — die In-Band-Output-Maskierung beim Streaming ist auf der Roadmap.
Input ist nie das Problem. Input-Stage-Regeln laufen vor dem Modell — das Gateway prüft (und schreibt bei mask um) Ihren Request und leitet dann die bereinigte Version nach Upstream weiter. Ob die Response streamen wird, ist irrelevant; der Request ist eine vollständige Payload, die das Gateway vollständig hält. Input-Scanning ist vollständig live, inklusive Maskierung, auf jedem Request.

​
2. Die Abdeckungsmatrix

Lesen Sie dies von oben nach unten. Jede block-Zelle ist live, Streaming inklusive — aber output + mask + streamend ist die eine Zelle, die im Stream noch nicht durchgesetzt wird: Eine mask-Regel redigiert eine nicht-streamende Antwort, und auf einer streamenden Antwort erkennt sie den Treffer, ohne das Delta umzuschreiben (die In-Stream-Output-Maskierung ist auf der Roadmap).
Stage · ActionNicht-streamendStreamend
input · blocklehnt Request ablehnt Request ab
input · maskschreibt Request umschreibt Request um
output · blocklehnt Antwort abunterbricht den Stream
output · maskredigiert Antworterkennt Treffer; redigiert nicht im Stream (Roadmap)
beliebig · flagzeichnet nur aufzeichnet nur auf
annotate und spotlight hängen eine Notiz an (oder umschließen gematchten Text), ohne Traffic abzulehnen, und sind in der Praxis Input-Stage-Actions, sodass sie die Output-/Streaming-Zellen oben nicht ändern; sie zeichnen einen Match auf wie jede andere Regel.
Input-Stage-Regeln prüfen den Request, bevor das Upstream-Modell läuft. Ein block kurzschließt den Aufruf (HTTP 400 guardrail_blocked, vor der Messung, sodass es kein Kontingent kostet). Ein mask schreibt die gematchten Felder im Prompt an Ort und Stelle um — der bereinigte Text ist das, was nach Upstream geht, und das Modell sieht das Original nie. Nichts davon hängt davon ab, ob die Response streamt.
Auf einer nicht-streamenden Antwort wird die Completion vollständig geprüft, bevor sie zurückkehrt — ein Block taucht als HTTP 400 guardrail_blocked auf. Auf einer streamenden Antwort beobachtet ein Stream-Scanner die Deltas, während sie fließen; wenn eine block-Regel feuert, unterbricht er den Stream — versiegelt den Scanner, gibt einen kurzen Ersatzhinweis anstelle des Rests aus und schließt den SSE-Kanal, bevor weiterer blockierter Inhalt den Client erreicht. Da die 200-SSE-Header bis dahin bereits ausgegangen sind, kann ein streamender Block keinen 400 zurückgeben: Er liefert den Block als finales In-Band-Delta statt eines HTTP-Fehlers.
Auf einer nicht-streamenden Antwort schreibt eine mask-Regel die Completion um — z. B. wird eine E-Mail zu [EMAIL] — und der bereinigte Text ist das, was Ihr Client erhält. Auf einer streamenden Antwort erkennt der Stream-Scanner weiterhin den Treffer und berechnet die Maske, leitet den maskierten Text aber nicht ins Delta weiter — der maskierte Output wird verworfen und nur auf einer Block-Entscheidung gehandelt. Eine mask-Regel redigiert also eine streamende Antwort heute nicht; die In-Band-Output-Maskierung beim Streaming ist auf der Roadmap. Wenn Sie PII jetzt aus einer gestreamten Antwort heraushalten müssen, verfassen Sie die Regel als block (der Scanner unterbricht den Stream bei einem Treffer) oder prüfen Sie nicht-streamend.
Eine flag-Regel verändert nie den Traffic — sie zeichnet einen Match auf und lässt die Bytes durch. Stage und Stream ändern ihr Verhalten nicht. Verwenden Sie sie, um die Trefferquote einer Regel zu messen, bevor Sie sie zu block promoten.
Die eine Zeile, die man sich merken muss: Output-block wird auf beiden Transporten live durchgesetzt — Streaming inklusive — und Input-Maskierung ist immer live. Output-mask redigiert nur nicht-streamende Antworten; auf einem Stream erkennt sie den Treffer, schreibt das Delta aber noch nicht um (die In-Stream-Output-Maskierung ist auf der Roadmap). Um PII heute aus einer gestreamten Antwort herauszuhalten, verfassen Sie die Regel als block oder prüfen Sie nicht-streamend.

​
3. Ein konkretes Beispiel — PII aus einer gestreamten Antwort heraushalten

Angenommen, das Modell kann eine Kunden-E-Mail aus dem RAG-Kontext an die Oberfläche bringen, und Ihre App streamt. Output-mask redigiert heute nicht im Stream (die In-Stream-Output-Maskierung ist auf der Roadmap) — um also PII aus einer gestreamten Antwort herauszuhalten, verfassen Sie die Output-Regel als block: Der Scanner beendet den Stream in dem Moment, in dem ein Treffer auftaucht. (Output-mask redigiert auf einer nicht-streamenden Antwort.) Das Bearbeiten von Policies ist eine Management-Aktion auf Ihrer Konsolen-Session (gegated auf Developer+); der sk-orca-...-Relay-Key sendet nur /v1/*-Traffic und bearbeitet nie Policy.
  • Öffnen Sie /console/guardrails, New guardrail, benennen Sie es stream-pii-out.
  • Fügen Sie eine Regel hinzu:
    • Type: PII detection
    • Stage: output
    • Action: block ← unterbricht den Stream bei einem Treffer; auf einem Stream erkennt mask nur (es redigiert nicht-streamende Antworten)
  • Speichern, dann hängen Sie es auf /console/token über das Dropdown Guardrail des Keys an.
Rufen Sie nun das Gateway mit stream: true genau wie zuvor auf: 
curl https://api.orcarouter.ai/v1/chat/completions \
  -H "Authorization: Bearer sk-orca-..." \
  -H "Content-Type: application/json" \
  -d '{
    "model": "openai/gpt-4o-mini",
    "stream": true,
    "messages": [
      {"role": "user", "content": "Email the customer from the record above"}
    ]
  }'
Wenn ein Delta matcht, unterbricht der Scanner den Stream, gibt einen Ersatzhinweis aus und schließt den Kanal — der Client empfängt den Rest nie. Wenn die Antwort sauber ist, streamt jedes Delta unangetastet durch.
Ein streamender Block stoppt alles nach dem Treffer, kann aber bereits vor dem Treffer geflushte Bytes nicht zurücknehmen. Wenn Ihre Policy verlangt, dass nicht ein einziges anstößiges Byte je den Client erreicht, prüfen Sie den Request nicht-streamend, wo die ganze Completion gehalten wird, bis die Policy sie freigibt.

​
4. PII-Shield über die Matrix

Das PII Shield-Preset ist eine einzelne pii-Regel, Action mask, Stage both. Mappen Sie es auf die Matrix, und die Abdeckung ist genau das, was Sie aus §2 erwarten würden:
  • Input-Stage — vollständig live, streamend oder nicht. Der Request wird maskiert, bevor das Modell ihn sieht (der Schlagzeilen-Wert der Input-Maskierung).
  • Output-Stage, nicht-streamend — die Completion wird maskiert, bevor sie zurückkehrt.
  • Output-Stage, streamend — der Stream-Scanner erkennt den Treffer, schreibt das Delta aber heute nicht um, sodass die maskierte Form keinen gestreamten Client erreicht (die In-Stream-Output-Maskierung ist auf der Roadmap).
Das mask-Preset deckt PII aus einer gestreamten Antwort also nicht allein ab. Um PII aus einer gestreamten Antwort herauszuhalten, verfassen Sie diese Regel als block (oder rufen nicht-streamend auf), sodass der Stream bei einem Treffer unterbrochen wird. Siehe PII-Shield und Maskierungsformate.

​
5. Was ein streamender Block kostet

Ein streamender Block trägt dieselbe Abrechnung wie jeder Output-Block — das Modell ist bereits gelaufen, sodass das Gateway die Erstattung für Sie übernimmt:
  • Auf einer nicht-streamenden Antwort gibt der Aufruf HTTP 400 guardrail_blocked zurück, das das Guardrail und die ausgelöste Regel benennt. Auf einer streamenden Antwort sind die 200-SSE-Header bereits auf der Leitung, sodass der Block als finales In-Band-Ersatz-Delta und ein sauberes Kanal-Schließen statt eines 400 ankommt.
  • Es wird kein Kontingent berechnet. Ein Input-Block feuert vor der Messung; ein Output-Block (streamend oder nicht) erstattet das vorab verbrauchte Kontingent zurück, sobald die Antwort abgelehnt wird. In beiden Fällen zahlt der Aufrufer nichts.
  • Der Request wird als skip-retry markiert — das erneute Ausführen desselben Prompts würde einfach wieder blockieren, sodass das Gateway keinen Retry auf einem anderen Channel verbrennt.
Jede Output-Regel, die feuert, zeichnet außerdem einen Match im workspace-weiten Feed Matches auf (GET /api/guardrail/match, offen für jedes Member); der gematchte Teilstring wird nur dann erfasst, wenn der Log raw content-Toggle des Guardrails ein ist (standardmäßig aus). Volle Details leben im guardrail_blocked-Fehler und im Matches-Feed.

​
6. Beweisen Sie Ihre Stage-/Action-Kombination, bevor Sie ausliefern

Raten Sie nicht, welche Zelle der Matrix auf Ihre Policy zutrifft — verifizieren Sie es. Beide Tools laufen auf Ihrer Konsolen-Session über die Management-API:

Test-Tab

Jeder Guardrail-Editor hat einen Tab Test: Fügen Sie ein Sample ein, wählen Sie die Stage und führen Sie die aktuelle Policy ohne Upstream-Aufruf und ohne Kontingent aus. Sehen Sie das Verdikt und, bei mask-Regeln, den gerenderten Text. Die Test-Sandbox ist auf Developer+ gegated (sie kann kostenpflichtige judge-/grounding-Aufrufe und ausgehende Integrations-Requests feuern).

Eval-Tab

Der Tab Eval bewertet ein Guardrail gegen mitgelieferte oder benutzerdefinierte JSONL-Korpora — nützlich, um zu bestätigen, dass eine block-Regel ein bekanntes Leck fängt, bevor Sie einen Key anhängen. Das Ausführen einer Eval benötigt nur Lesezugriff (viewer+).
Siehe Testing & Eval und Fehlalarme tunen für mehr Tiefe.

​
7. Wie es weitergeht

Stream-sichere Regeln

Wie der Scanner einen SSE-Stream mittendrin unterbricht und wie man eine Policy verfasst, die auf streamendem Traffic hält.

Output-Stage

Prüfung der Antwort des Modells — block vs. mask, die Kontingent-Erstattung und Grounding.

Input-Stage

Prüfung des Requests vor dem Modell — Maskierung inklusive, streamend oder nicht.

Actions

block, mask, flag, annotate und spotlight im Detail — wann welches die richtige Wahl ist.
Guardrails — jeder Regeltyp, jedes Feld und jede Route, inklusive Grounding und LLM-Judge.