Stream-sichere Output-Filterung

Die meisten Produktions-Chat-Apps streamen. Tokens werden zum Browser geflusht, sobald das Modell sie ausgibt, sodass Ihr Benutzer bis zu dem Zeitpunkt, an dem eine Completion „fertig” ist, bereits das meiste davon gelesen hat. Das bricht das naive Mentalmodell eines Content-Filters, der eine ganze Antwort prüft und dann entscheidet — es gibt keine ganze Antwort zu prüfen, bis es zu spät ist. Ein Streaming-LLM-Content-Filter muss seine Entscheidung auf den Deltas treffen, während sie fließen. Diese Seite behandelt genau diesen Fall: wie sich jede Output-Stage-Action stream-sicher auf dem OrcaRouter-Gateway verhält und wie man eine Policy verfasst, die auf SSE-Traffic hält. Für die vollständige Engine — jeder Regeltyp, jedes Feld und jede Route — siehe Guardrails.

1. Das Streaming-LLM-Content-Filter-Problem

Ein Output-Stage-Guardrail prüft die Antwort des Modells. Bei einem nicht-streamenden Request ist das unkompliziert: Das Gateway hat die vollständige Completion, bevor ein einziges Byte zurückkehrt, sodass es sie sauber blockieren, maskieren oder durchlassen kann. Streaming kehrt das um. Die Antwort kommt als Folge von SSE-Deltas an, jedes an Ihren Client weitergeleitet, sobald es landet, sodass ein Filter, der auf das Ende wartet, nichts filtert. OrcaRouters Antwort ist ein Stream-Scanner: Während Output-Deltas fließen, führt der Scanner Ihre Output-Stage-Regeln gegen den sich anhäufenden Text aus und handelt in dem Moment, in dem eine Regel feuert — nicht erst, nachdem der Stream abgeschlossen ist. Die Action, die Sie verfassen, entscheidet, was „handeln” bedeutet: Ein block unterbricht den Stream und ein flag lässt ihn durch. Ein mask redigiert auf nicht-streamendem Output, aber das In-Band-Stream-Umschreiben ist auf der Roadmap — auf einem Stream berechnet der Scanner heute die Maske, handelt aber nur auf der Block-Entscheidung, sodass eine mask-Regel eine gestreamte Antwort noch nicht redigiert.

Dieser Vorbehalt ist nur für Output-Stage-Regeln auf streamenden Requests relevant. Input-Stage-Regeln prüfen den Request, bevor das Modell läuft, sodass sie vollständig live sind, inklusive Maskierung — und jede Output-Regel auf einem nicht-streamenden Request sieht die ganze Antwort und verhält sich normal, inklusive mask.

2. Was heute stream-sicher ist

block — stream-sicher (unterbricht den Stream mittendrin)

Eine block-Regel wird auf streamendem und nicht-streamendem Output durchgesetzt. Auf einem Stream beobachtet der Scanner die Deltas; wenn eine block-Regel feuert, unterbricht er den Stream — versiegelt den Scanner, gibt einen kurzen Ersatzhinweis aus ([response truncated by guardrail: … policy violation]) als finales Delta und schließt den SSE-Kanal, bevor weiterer blockierter Inhalt den Client erreicht. Da der HTTP-Response-Status zu dem Zeitpunkt, an dem das erste Delta geflusht wurde, bereits auf 200 festgelegt ist, kann ein Block mitten im Stream keinen Status erneut ausstellen — er beendet den offenen Stream geordnet. Der HTTP-400- guardrail_blocked-Body ist die Form des nicht-streamenden Output-Blocks.Bereits an den Client geflushte Bytes können nicht zurückgezogen werden, sodass ein streamender Block bezüglich dessen, was bereits gestreamt wurde, Best-Effort ist, aber zuverlässig alles nach dem Treffer stoppt. Für eine harte Garantie, dass nie ein anstößiges Byte gesendet wird — und für den 400-guardrail_blocked-Body — senden Sie den Request nicht-streamend.

mask — nur nicht-streamender Output (In-Band-Stream-Umschreiben ist auf der Roadmap)

Eine mask-Regel schreibt den Treffer um — z. B. wird eine E-Mail in der Antwort zu [EMAIL] — auf nicht-streamendem Output, wo das Gateway die ganze Completion hält und die redigierte Form an Ihren Client weiterleitet.Auf einem streamenden Output berechnet der Scanner heute die Maske, leitet den maskierten Text aber nicht weiter — er handelt nur auf der Block-Entscheidung — sodass eine mask-Regel eine gestreamte Antwort nicht redigiert. Das In-Band-Umschreiben des streamenden Outputs ist auf der Roadmap. Bis es ausgeliefert wird, verfassen Sie die Regel als block (sie beendet die Antwort bei einem Treffer) oder senden Sie den Request nicht-streamend, sodass die Maske die ganze Antwort umschreibt, wenn Sie wollen, dass eine gestreamte Antwort den gematchten Text nie offenlegt.

flag — nur-beobachtend, verändert nie den Traffic

Eine flag-Regel verändert nie den Traffic — sie lässt die Bytes durch. Auf nicht-streamendem Output zeichnet sie einen Match im Matches-Feed auf, sodass Sie die Trefferquote einer Regel messen können, bevor Sie sie zu block promoten. Auf einer streamenden Response bleibt sie nur-beobachtend und reicht die Deltas unangetastet durch; der strukturierte Match-Eintrag wird auf dem nicht-streamenden Output-Pfad geschrieben. In jedem Fall blockiert oder schreibt sie nie um, sodass es immer sicher ist, sie eingeschaltet zu lassen.

Action auf `output`	Nicht-streamend	Streamend
`block`	lehnt die Antwort ab	unterbricht den Stream
`mask`	redigiert die Antwort	noch nicht — stattdessen block (Roadmap)
`flag`	zeichnet einen Match auf	lässt durch (nur-beobachtend)

Die eine Regel, die man sich merken muss: block ist auf dem Output stream-sicher; mask redigiert nur auf nicht-streamendem Output (das In-Band-Stream-Umschreiben ist auf der Roadmap). Um eine gestreamte Antwort heute zu redigieren, verfassen Sie die Regel als block oder senden Sie den Request nicht-streamend, sodass die ganze Antwort gehalten wird, bevor sie zurückkehrt.

3. Ein konkretes Beispiel — ein stream-sicherer Secret-Filter

Angenommen, Ihr Modell kann ein Credential aus dem RAG-Kontext an die Oberfläche bringen, und Ihre App streamt. Sie wollen, dass das Gateway den Stream in dem Moment beendet, in dem ein secret-förmiger Treffer auftaucht, statt ihn zu maskieren — ein geleaktes Secret sollte die Antwort beenden, nicht teilweise redigiert werden. Verfassen Sie es in der Konsole — das Bearbeiten von Policies ist eine Management-Aktion auf Ihrer Session, gegated auf Developer+; der Relay-Key sendet nur /v1/*-Traffic:

Öffnen Sie /console/guardrails, New guardrail, benennen Sie es stream-safe-out.
Fügen Sie eine Regel hinzu:
- Type: regex (oder eine pii-Regel mit Secret-Entities wie aws_access_key / api_key_openai / jwt)
- Stage: output
- Action: block ← beendet die Antwort bei einem Secret-Treffer; mask würde es stattdessen redigieren und den Rest der Antwort fortfahren lassen
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": "Print the AWS key from the context above"}
    ]
  }'

Wenn ein Delta matcht, unterbricht der Scanner den Stream mittendrin, gibt einen Ersatzhinweis aus und schließt den Kanal — Ihr 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 auf einem Stream

Das PII Shield-Preset ist eine einzelne pii-Regel, Action mask, Stage both. An der Input-Stage ist es vollständig live — es schreibt den Request um, bevor das Modell ihn sieht, streamend oder nicht. An der Output-Stage redigiert die Maskierung auf nicht-streamenden Antworten, wo das Gateway die ganze Completion hält, bevor sie zurückkehrt. Auf einem streamenden Output redigiert die Maske noch nicht — der Scanner berechnet die Maske, handelt aber nur auf der Block-Entscheidung, sodass eine gestreamte Antwort durchgereicht und nicht umgeschrieben wird. Das In-Band-Umschreiben des streamenden Outputs ist auf der Roadmap. Wenn Ihr Ziel also ist, dass PII in einer gestreamten Antwort nie beobachtbar ist, entweder:

verfassen Sie die Output-Regel als block und akzeptieren, dass ein Treffer die Antwort beendet, statt sie zu redigieren, oder
senden Sie den Request nicht-streamend, sodass die Maske die ganze Antwort mit der vollständigen Completion in der Hand umschreibt.

Siehe PII-Shield und Maskierungsformate für die Redaktions-Tags selbst.

5. Beweisen Sie es, bevor Sie ausliefern

Raten Sie nicht, welche Stage-/Action-Kombination hält — verifizieren Sie es.

Test-Tab

Jeder Guardrail-Editor hat einen Tab Test: Fügen Sie ein Sample ein, wählen Sie die output-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. Das Ausführen der Sandbox ist eine Developer+-Aktion (sie kann kostenpflichtige judge- / external-Regeln 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 über einen Korpus fängt, bevor Sie einen Key anhängen.

Beide laufen auf Ihrer Session über die Management-API. Für mehr Tiefe siehe Testing & Eval und Fehlalarme tunen.

6. Was ein streamender Block kostet

Ein streamender Block trägt dieselbe Abrechnung wie jeder Output-Block — das Upstream-Modell ist bereits gelaufen, sodass das Gateway die Erstattung für Sie übernimmt:

Der Stream wird mit einem geordneten Kürzungs-Delta beendet (der Status ist bereits 200); der nicht-streamende Output-Block gibt den HTTP 400 guardrail_blocked-Body zurück, der das Guardrail und die ausgelöste Regel benennt.
Es wird kein Kontingent berechnet. Wenn der Output-Block die Response ablehnt, erstattet das Gateway das vorab verbrauchte Kontingent zurück, sodass ein blockierter Aufruf für Sie kostenlos ist, obwohl das Modell Tokens produziert hat.
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.

Der nicht-streamende Output-Pfad zeichnet jede gefeuerte Output-Regel als 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.

7. Wie es weitergeht

Output-Stage

Die vollständige Output-Stage — Prüfung der Antwort des Modells, block vs. mask und Grounding.

Streaming-Abdeckung

Die vollständige Matrix dessen, was auf streamendem vs. nicht-streamendem Traffic über jede Stage und Action durchgesetzt wird.

Actions

block, mask und flag im Detail — wann welches die richtige Wahl ist.

Input-Stage

Das Spiegelbild — Maskierung ist hier vollständig live, auch beim Streaming.

Verwandte Konzepte

Wie OrcaRouter Traffic prüft · Durchsetzungsmodi · Durchsetzungspfad & Latenz.

Bedrohungen, die dies adressiert

Datenexfiltration · Prompt-Injection · Jailbreaks.

Vollständige Engine-Referenz

Guardrails — jeder Regeltyp, jedes Feld und jede Route, inklusive Grounding und LLM-Judge.

​1. Das Streaming-LLM-Content-Filter-Problem

​2. Was heute stream-sicher ist

​3. Ein konkretes Beispiel — ein stream-sicherer Secret-Filter

​4. PII-Shield auf einem Stream

​5. Beweisen Sie es, bevor Sie ausliefern

Test-Tab

Eval-Tab

​6. Was ein streamender Block kostet

​7. Wie es weitergeht

Output-Stage

Streaming-Abdeckung

Actions

Input-Stage

1. Das Streaming-LLM-Content-Filter-Problem

2. Was heute stream-sicher ist

3. Ein konkretes Beispiel — ein stream-sicherer Secret-Filter

4. PII-Shield auf einem Stream

5. Beweisen Sie es, bevor Sie ausliefern

6. Was ein streamender Block kostet

7. Wie es weitergeht