Zum Hauptinhalt springen
Ein Input-Stage-Guardrail prüft die Anfrage des Aufrufers, bevor sie das Modell erreicht. Es ist der günstigste Ort, eine Content-Policy durchzusetzen: das Gateway inspiziert den Prompt auf seinem Weg hinein, und wenn eine Regel blockiert, wird die Anfrage vor der Messung abgelehnt — Sie zahlen nichts für den Aufruf. Hier stoppen Sie ein geleaktes Secret, ein PII-Feld oder einen Injection-Versuch, bevor er je das Upstream-Modell trifft. Für die vollständige Engine — jeder Regeltyp, jedes Feld, jede Route — siehe die Guardrails-Referenz. Diese Seite ist der fokussierte Blick auf die Input-Stage: was vor dem Modell läuft und warum ein Block hier kein Kontingent kostet.

​
1. Input-Guardrails für LLM-Apps, vor dem Modell

Jede Guardrail-Regel trägt eine Stage — input, output oder both. Eine input-Regel läuft gegen den Request-Text in dem Moment, in dem er ankommt, auf dem Weg zum Upstream-Modell: 
caller → [ input guardrail ] → metering → model → [ output guardrail ] → caller
Diese Reihenfolge ist der Punkt. Eine Input-Regel sieht den Prompt, bevor das Gateway irgendein Kontingent vorab verbraucht, sodass ein Block an dieser Stage kostenlos ist — die Anfrage erreicht das Modell nie und rechnet nie ab. Vergleichen Sie die Output-Stage, die die Antwort des Modells nachdem sie zurückkommt prüft (ein Output-Block erstattet stattdessen das vorab verbrauchte Kontingent zurück).
Input-Regeln prüfen die Anfrage des Aufrufers. Wenn Sie auch Registry-Prompts verwenden, wird die injizierte System-Message später im Routing hinzugefügt — daher sehen Input-Regeln die Messages, die Ihre App gesendet hat, nicht den injizierten Prompt. Output-Regeln prüfen die Antwort in jedem Fall.

​
2. Was Sie an der Input-Stage ausführen können

Jeder Regeltyp kann an input laufen. Die häufigsten Gründe, die Anfrage vor dem Modell zu gaten:

PII im Prompt maskieren

Eine pii-Regel mit der mask-Action schreibt Entities zu typisierten Tags um (jane@acme.com → [EMAIL]), sodass das Upstream-Modell den Rohwert nie sieht. Siehe PII Shield.

Secrets blockieren, bevor sie leaken

Eine Anfrage, die einen API-Key oder ein Cloud-Credential trägt, wird an der Tür abgelehnt — vor der Messung, kein Upstream-Aufruf. Siehe Secrets blockieren.

Injection-Versuche stoppen

Das Prompt-Injection-Grundlagen-Preset paart Keyword-/Regex-Detektoren mit einer llm_judge-Regel für Injection-Absicht. Siehe Prompt-Injection.

Prompt-Größe begrenzen

Eine max_chars-Regel lehnt einen übergroßen Prompt ab, bevor er irgendwelche Tokens abrechnet. Siehe Cost-Guardrails.
Die sieben Regeltypen — keyword, regex, pii, max_chars, external, llm_judge, grounding — und die fünf Actions block, mask, flag, annotate und spotlight gelten hier alle. (spotlight fasst gematchten nicht vertrauenswürdigen Text in Delimiter ein, sodass das Modell ihn als Daten behandelt, nicht als Anweisungen — eine Input-Stage-Prompt-Injection-Verteidigung; annotate hängt eine Notiz an, ohne den Traffic zu ändern.) Eine erwähnenswerte Ausnahme: grounding misst die Antwort gegen abgerufene Quellen, ist also inhärent eine Output-Stage-Prüfung. Alles andere passt natürlich zur Input-Stage.
Input-Stage-Masking ist heute live — streamend oder nicht. Das Gateway schreibt die Anfrage auf jedem Pfad um, bevor das Modell sie sieht. Output-mask redigiert nur nicht-streamende Responses; In-Stream-Output- Rewriting ist auf der Roadmap, daher redigiert eine Mask-Regel eine streamende Antwort noch nicht. Output-block hingegen wird in beiden Wegen durchgesetzt — streamend und nicht-streamend (siehe Streaming-Abdeckung).

​
3. Ein konkretes Beispiel

Verfassen Sie die Regel in der Konsole (unter Ihrer eigenen Session — Guardrail-Config braucht Developer+), nicht mit einem Relay-Key. Fügen Sie einem Guardrail namens secrets-shield eine einzelne input-Regel hinzu: 
{
  "type": "regex",
  "stage": "input",
  "action": "block",
  "pattern": "sk-[A-Za-z0-9]{20,}"
}
Hängen Sie das Guardrail an einen Key an (setzen Sie guardrail_id oder markieren Sie es als Workspace-Default — siehe An einen Key anhängen), rufen Sie dann das Gateway mit diesem sk-orca-...-Relay-Key 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",
    "messages": [
      {"role": "user", "content": "Debug this: OPENAI_API_KEY=sk-abcdefghij1234567890"}
    ]
  }'
Die Anfrage matcht an der Input-Stage und wird mit HTTP 400 guardrail_blocked abgelehnt, bevor das Gateway irgendetwas nach Upstream weiterleitet: 
{
  "error": {
    "type": "guardrail_blocked",
    "message": "request blocked by guardrail \"secrets-shield\": regex(...)"
  }
}
Siehe den guardrail_blocked-Fehler für die vollständige Response-Form.

​
4. Warum ein Input-Block kein Kontingent kostet

Das ist der strukturelle Vorteil, Dinge auf dem Weg hinein abzufangen. Ein Block der Input-Stage sitzt vor dem Vorabverbrauch, also:
EigenschaftBlock der Input-Stage
HTTP-Status400 guardrail_blocked
Berechnetes KontingentKeines — feuert vor der Messung
Upstream-AufrufNie getätigt
RetryAls skip-retry markiert — erneutes Ausführen blockiert wieder
Weil die Anfrage nie einen Channel erreicht, wird ein Input-Block als skip-retry markiert: das erneute Ausführen desselben Prompts gegen einen anderen Channel würde einfach wieder blockieren und Aufwand verschwenden. Die Output-Stage unterscheidet sich — ein Block dort erstattet das Kontingent zurück, das das Gateway bereits vorab verbraucht hat. Gleicher 400, andere Verbuchung.

​
5. Auflösung und Fallback

Eine Input-Stage-Regel läuft nur, wenn auf der Anfrage tatsächlich ein Guardrail auflöst. Die Auflösung ist explizit:
  1. Die explizite guardrail_id des Keys, sofern sie existiert und aktiviert ist.
  2. Andernfalls das Default-Guardrail des Workspaces.
  3. Andernfalls keines — die Anfrage ist byte-identisch zu einem Workspace ohne Policy.
Eine explizite Bindung fällt nie stillschweigend zurück. Das Deaktivieren eines angehängten Guardrails ist der Aus-Schalter — es fällt nicht auf den Workspace-Default durch. (Firewall-Policies verhalten sich hier anders; siehe Guardrails vs. Firewall.)

​
6. Beweisen Sie es, bevor Sie ausliefern

Hängen Sie eine blockierende Input-Regel nicht auf gut Glück an Live-Traffic. Zwei Wege, zuerst zu validieren:
Öffnen Sie den Tab Test im Guardrail-Editor, fügen Sie ein Sample ein, wählen Sie die input-Stage und führen Sie aus. Die Sandbox evaluiert die aktuelle Policy lokal — kein Upstream-Aufruf, kein Kontingent — und gibt das Verdikt plus (bei Mask-Regeln) den gerenderten Text zurück. Siehe Testing & Eval.
Setzen Sie die Action zuerst auf flag. Ein Flag ändert nichts am Traffic — es zeichnet nur einen Match auf — sodass Sie messen können, wie oft eine Regel auf echtem Input feuern würde, bevor Sie sie auf block kippen. Siehe Fehlalarme tunen.
Jede Regel, die feuert, zeichnet einen Match auf — Type, Action, Stage und einen Detail-String. Der gematchte Teilstring wird nur aufgezeichnet, wenn Log raw content an ist (standardmäßig aus). Siehe den Matches-Feed und Logging & Datenschutz.

​
7. Wohin als Nächstes

Die Input-Stage stoppt schlechten Input, bevor er das Modell erreicht. Um die Antwort des Modells zu gaten, paaren Sie sie mit der Output-Stage; um die Tool-Calls eines Agenten zu steuern, verwenden Sie die Firewall. Lesen Sie die Guardrails-Referenz für die vollständige Engine oder den Security-Quickstart, um Input-Guardrails und die Firewall für eine Agent-Baseline zu verdrahten.